kernel.bbclass: Complete fix for modules symlink

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

(From OE-Core rev: f07a4e0d80f5e0dd94514f6aae11a7bd56034f30)

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

README.hardware

@@ -1,28 +1,34 @@
                           Poky Hardware README
                           ====================
 
-This file gives details about using Poky with different hardware reference
-boards and consumer devices. A full list of target machines can be found by
-looking in the meta/conf/machine/ directory. If in doubt about using Poky with
-your hardware, consult the documentation for your board/device.
+This file gives details about using Poky with the reference machines
+supported out of the box. A full list of supported reference target machines
+can be found by looking in the following directories:
+
+   meta/conf/machine/
+   meta-yocto-bsp/conf/machine/
+
+If you are in doubt about using Poky/OpenEmbedded with your hardware, consult
+the documentation for your board/device.
 
 Support for additional devices is normally added by creating BSP layers - for
 more information please see the Yocto Board Support Package (BSP) Developer's
 Guide - documentation source is in documentation/bspguide or download the PDF
 from:
 
-   http://yoctoproject.org/community/documentation
+   http://yoctoproject.org/documentation
 
-Support for machines other than QEMU may be moved out to separate BSP layers in
-future versions.
+Support for physical reference hardware has now been split out into a
+meta-yocto-bsp layer which can be removed separately from other layers if not
+needed.
 
 
 QEMU Emulation Targets
 ======================
 
-To simplify development Poky supports building images to work with the QEMU
-emulator in system emulation mode. Several architectures are currently
-supported:
+To simplify development, the build system supports building images to
+work with the QEMU emulator in system emulation mode. Several architectures
+are currently supported:
 
   * ARM (qemuarm)
   * x86 (qemux86)
@@ -30,32 +36,33 @@ supported:
   * PowerPC (qemuppc)
   * MIPS (qemumips)
 
-Use of the QEMU images is covered in the Poky Reference Manual. The Poky
-MACHINE setting corresponding to the target is given in brackets.
+Use of the QEMU images is covered in the Yocto Project Reference Manual.
+The appropriate MACHINE variable value corresponding to the target is given
+in brackets.
 
 
 Hardware Reference Boards
 =========================
 
-The following boards are supported by Poky's core layer:
+The following boards are supported by the meta-yocto-bsp layer:
 
   * Texas Instruments Beagleboard (beagleboard)
   * Freescale MPC8315E-RDB (mpc8315e-rdb)
   * Ubiquiti Networks RouterStation Pro (routerstationpro)
 
-For more information see the board's section below. The Poky MACHINE setting
-corresponding to the board is given in brackets.
+For more information see the board's section below. The appropriate MACHINE
+variable value corresponding to the board is given in brackets.
 
 
 Consumer Devices
 ================
 
-The following consumer devices are supported by Poky's core layer:
+The following consumer devices are supported by the meta-yocto-bsp layer:
 
   * Intel Atom based PCs and devices (atom-pc)
 
-For more information see the device's section below. The Poky MACHINE setting
-corresponding to the device is given in brackets.
+For more information see the device's section below. The appropriate MACHINE
+variable value corresponding to the device is given in brackets.
 
 
 
@@ -78,7 +85,7 @@ supports ethernet, wifi, sound, and i915 graphics by default in addition to
 common PC input devices, busses, and so on.
 
 Depending on the device, it can boot from a traditional hard-disk, a USB device,
-or over the network. Writing poky generated images to physical media is
+or over the network. Writing generated images to physical media is
 straightforward with a caveat for USB devices. The following examples assume the
 target boot device is /dev/sdb, be sure to verify this and use the correct
 device as the following commands are run as root and are not reversable.
@@ -131,7 +138,7 @@ USB Device:
      device stops flashing, remove and reinsert the device to allow the
      kernel to detect the new partition layout.
 
-     c. Copy the contents of the poky image to the USB-ZIP mode device:
+     c. Copy the contents of the image to the USB-ZIP mode device:
 
      # mkdir /tmp/image
      # mkdir /tmp/usbkey
@@ -281,8 +288,8 @@ anything here.
 Load the kernel and dtb (device tree blob), and boot the system as follows:
 
  1. Get the kernel (uImage-mpc8315e-rdb.bin) and dtb (uImage-mpc8315e-rdb.dtb)
-    files from the Poky build tmp/deploy directory, and make them available on
-    your TFTP server.
+    files from the tmp/deploy directory, and make them available on your TFTP
+    server.
 
  2. Connect the board's first serial port to your workstation and then start up
     your favourite serial terminal so that you will be able to interact with
@@ -301,9 +308,9 @@ Load the kernel and dtb (device tree blob), and boot the system as follows:
 
  5. Download the kernel and dtb, and boot:
 
- => tftp 800000 uImage-mpc8315e-rdb.bin
- => tftp 780000 uImage-mpc8315e-rdb.dtb
- => bootm 800000 - 780000
+ => tftp 1000000 uImage-mpc8315e-rdb.bin
+ => tftp 2000000 uImage-mpc8315e-rdb.dtb
+ => bootm 1000000 - 2000000
 
 
 Ubiquiti Networks RouterStation Pro (routerstationpro)

bitbake/bin/bitbake

@@ -40,7 +40,7 @@ from bb import cooker
 from bb import ui
 from bb import server
 
-__version__ = "1.17.1"
+__version__ = "1.18.0"
 logger = logging.getLogger("BitBake")
 
 # Unbuffer stdout to avoid log truncation in the event

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.17.1"
+__version__ = "1.18.0"
 
 import sys
 if sys.version_info < (2, 6, 0):

bitbake/lib/bb/cache.py

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

bitbake/lib/bb/cooker.py

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

bitbake/lib/bb/data.py

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

bitbake/lib/bb/data_smart.py

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

bitbake/lib/bb/fetch2/__init__.py

@@ -74,6 +74,9 @@ class FetchError(BBFetchException):
 
 class ChecksumError(FetchError):
     """Exception when mismatched checksum encountered"""
+    def __init__(self, message, url = None, checksum = None):
+        self.checksum = checksum
+        FetchError.__init__(self, message, url)
 
 class NoChecksumError(FetchError):
     """Exception when no checksum is specified, but BB_STRICT_CHECKSUM is set"""
@@ -322,7 +325,7 @@ def decodeurl(url):
     user, password, parameters).
     """
 
-    m = re.compile('(?P<type>[^:]*)://((?P<user>.+)@)?(?P<location>[^;]+)(;(?P<parm>.*))?').match(url)
+    m = re.compile('(?P<type>[^:]*)://((?P<user>[^/]+)@)?(?P<location>[^;]+)(;(?P<parm>.*))?').match(url)
     if not m:
         raise MalformedUrl(url)
 
@@ -561,7 +564,7 @@ def verify_checksum(u, ud, d):
         msg = msg + '\nIf this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:\nSRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"\nOtherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.\n' % (ud.md5_name, md5data, ud.sha256_name, sha256data)
 
     if len(msg):
-        raise ChecksumError('Checksum mismatch!%s' % msg, u)
+        raise ChecksumError('Checksum mismatch!%s' % msg, u, md5data)
 
 
 def update_stamp(u, ud, d):
@@ -753,6 +756,19 @@ def build_mirroruris(origud, mirrors, ld):
 
     return uris, uds
 
+def rename_bad_checksum(ud, suffix):
+    """
+    Renames files to have suffix from parameter
+    """
+
+    if ud.localpath is None:
+        return
+
+    new_localpath = "%s_bad-checksum_%s" % (ud.localpath, suffix)
+    bb.warn("Renaming %s to %s" % (ud.localpath, new_localpath))
+    bb.utils.movefile(ud.localpath, new_localpath)
+
+
 def try_mirror_url(newuri, origud, ud, ld, check = False):
     # Return of None or a value means we're finished
     # False means try another url
@@ -804,6 +820,7 @@ def try_mirror_url(newuri, origud, ud, ld, check = False):
         if isinstance(e, ChecksumError):
             logger.warn("Mirror checksum failure for url %s (original url: %s)\nCleaning and trying again." % (newuri, origud.url))
             logger.warn(str(e))
+            rename_bad_checksum(ud, e.checksum)
         elif isinstance(e, NoChecksumError):
             raise
         else:
@@ -972,13 +989,13 @@ class FetchData(object):
             self.sha256_name = "sha256sum"
         if self.md5_name in self.parm:
             self.md5_expected = self.parm[self.md5_name]
-        elif self.type not in ["http", "https", "ftp", "ftps"]:
+        elif self.type not in ["http", "https", "ftp", "ftps", "sftp"]:
             self.md5_expected = None
         else:
             self.md5_expected = d.getVarFlag("SRC_URI", self.md5_name)
         if self.sha256_name in self.parm:
             self.sha256_expected = self.parm[self.sha256_name]
-        elif self.type not in ["http", "https", "ftp", "ftps"]:
+        elif self.type not in ["http", "https", "ftp", "ftps", "sftp"]:
             self.sha256_expected = None
         else:
             self.sha256_expected = d.getVarFlag("SRC_URI", self.sha256_name)
@@ -1388,6 +1405,7 @@ class Fetch(object):
                         if isinstance(e, ChecksumError):
                             logger.warn("Checksum failure encountered with download of %s - will attempt other sources if available" % u)
                             logger.debug(1, str(e))
+                            rename_bad_checksum(ud, e.checksum)
                         elif isinstance(e, NoChecksumError):
                             raise
                         else:

bitbake/lib/bb/fetch2/git.py

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

bitbake/lib/bb/fetch2/hg.py

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

bitbake/lib/bb/fetch2/perforce.py

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

bitbake/lib/bb/fetch2/svn.py

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

bitbake/lib/bb/methodpool.py

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

bitbake/lib/bb/monitordisk.py

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

bitbake/lib/bb/parse/ast.py

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

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

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

bitbake/lib/bb/tests/fetch.py

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

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

@@ -56,7 +56,7 @@ class Configuration:
 
     @classmethod
     def parse_proxy_string(cls, proxy):
-        pattern = "^\s*((http|https|ftp|git|cvs)://)?((\S+):(\S+)@)?([^\s:]+)(:(\d+))?/?"
+        pattern = "^\s*((http|https|ftp|socks|cvs)://)?((\S+):(\S+)@)?([^\s:]+)(:(\d+))?/?"
         match = re.search(pattern, proxy)
         if match:
             return match.group(2), match.group(4), match.group(5), match.group(6), match.group(8)
@@ -124,7 +124,7 @@ class Configuration:
             "http"  : [None, None, None, "", ""],  # protocol : [prot, user, passwd, host, port]
             "https" : [None, None, None, "", ""],
             "ftp"   : [None, None, None, "", ""],
-            "git"   : [None, None, None, "", ""],
+            "socks" : [None, None, None, "", ""],
             "cvs"   : [None, None, None, "", ""],
         }
 
@@ -181,13 +181,13 @@ class Configuration:
         self.default_task = params["default_task"]
 
         # proxy settings
-        self.enable_proxy = params["http_proxy"] != "" or params["https_proxy"] != "" or params["ftp_proxy"] != "" \
-            or params["git_proxy_host"] != "" or params["git_proxy_port"] != ""                                    \
+        self.enable_proxy = params["http_proxy"] != "" or params["https_proxy"] != "" \
+            or params["ftp_proxy"] != "" or params["socks_proxy"] != "" \
             or params["cvs_proxy_host"] != "" or params["cvs_proxy_port"] != ""
         self.split_proxy("http", params["http_proxy"])
         self.split_proxy("https", params["https_proxy"])
         self.split_proxy("ftp", params["ftp_proxy"])
-        self.split_proxy("git", params["git_proxy_host"] + ":" + params["git_proxy_port"])
+        self.split_proxy("socks", params["socks_proxy"])
         self.split_proxy("cvs", params["cvs_proxy_host"] + ":" + params["cvs_proxy_port"])
 
     def load(self, template):
@@ -215,7 +215,7 @@ class Configuration:
         self.split_proxy("http", template.getVar("http_proxy"))
         self.split_proxy("https", template.getVar("https_proxy"))
         self.split_proxy("ftp", template.getVar("ftp_proxy"))
-        self.split_proxy("git", template.getVar("GIT_PROXY_HOST") + ":" + template.getVar("GIT_PROXY_PORT"))
+        self.split_proxy("socks", template.getVar("all_proxy"))
         self.split_proxy("cvs", template.getVar("CVS_PROXY_HOST") + ":" + template.getVar("CVS_PROXY_PORT"))
 
     def save(self, handler, template, defaults=False):
@@ -258,8 +258,7 @@ class Configuration:
         template.setVar("http_proxy", self.combine_proxy("http"))
         template.setVar("https_proxy", self.combine_proxy("https"))
         template.setVar("ftp_proxy", self.combine_proxy("ftp"))
-        template.setVar("GIT_PROXY_HOST", self.combine_host_only("git"))
-        template.setVar("GIT_PROXY_PORT", self.combine_port_only("git"))
+        template.setVar("all_proxy", self.combine_proxy("socks"))
         template.setVar("CVS_PROXY_HOST", self.combine_host_only("cvs"))
         template.setVar("CVS_PROXY_PORT", self.combine_port_only("cvs"))
 
@@ -274,8 +273,8 @@ class Configuration:
             (self.lconf_version, self.extra_setting, self.toolchain_build, self.image_fstypes, self.selected_image)
         s += "DEPENDS: '%s', IMAGE_INSTALL: '%s', enable_proxy: '%s', use_same_proxy: '%s', http_proxy: '%s', " % \
             (self.selected_recipes, self.user_selected_packages, self.enable_proxy, self.same_proxy, self.combine_proxy("http"))
-        s += "https_proxy: '%s', ftp_proxy: '%s', GIT_PROXY_HOST: '%s', GIT_PROXY_PORT: '%s', CVS_PROXY_HOST: '%s', CVS_PROXY_PORT: '%s'" % \
-            (self.combine_proxy("https"), self.combine_proxy("ftp"),self.combine_host_only("git"), self.combine_port_only("git"),
+        s += "https_proxy: '%s', ftp_proxy: '%s', all_proxy: '%s', CVS_PROXY_HOST: '%s', CVS_PROXY_PORT: '%s'" % \
+            (self.combine_proxy("https"), self.combine_proxy("ftp"), self.combine_proxy("socks"),
              self.combine_host_only("cvs"), self.combine_port_only("cvs"))
         return s
 
@@ -755,13 +754,13 @@ class Builder(gtk.Window):
             self.handler.set_http_proxy(self.configuration.combine_proxy("http"))
             self.handler.set_https_proxy(self.configuration.combine_proxy("https"))
             self.handler.set_ftp_proxy(self.configuration.combine_proxy("ftp"))
-            self.handler.set_git_proxy(self.configuration.combine_host_only("git"), self.configuration.combine_port_only("git"))
+            self.handler.set_socks_proxy(self.configuration.combine_proxy("socks"))
             self.handler.set_cvs_proxy(self.configuration.combine_host_only("cvs"), self.configuration.combine_port_only("cvs"))
         elif self.configuration.enable_proxy == False:
             self.handler.set_http_proxy("")
             self.handler.set_https_proxy("")
             self.handler.set_ftp_proxy("")
-            self.handler.set_git_proxy("", "")
+            self.handler.set_socks_proxy("")
             self.handler.set_cvs_proxy("", "")
 
     def set_user_config_extra(self):

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

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

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

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

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

@@ -198,7 +198,7 @@ class PropertyDialog(CrumbsDialog):
                         col1.set_cell_data_func(self.cell1, self.regex_field)
                         self.sstatemirrors_tv.append_column(col1)
 
-                        for items in file_list.split(']]'):
+                        for items in file_list.split(']'):
                             if len(items) > 1:
                                 paths_temp = items.split(":")[0]
                                 paths_binb.append(paths_temp.strip(" ,'"))

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

@@ -161,13 +161,13 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
         self.ftp_proxy_port.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
         self.ftp_proxy_details.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
 
-        self.git_proxy.set_text(self.configuration.combine_host_only("git"))
-        self.git_proxy.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
-        self.git_proxy.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
-        self.git_proxy_port.set_text(self.configuration.combine_port_only("git"))
-        self.git_proxy_port.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
-        self.git_proxy_port.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
-        self.git_proxy_details.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.socks_proxy.set_text(self.configuration.combine_host_only("socks"))
+        self.socks_proxy.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.socks_proxy.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.socks_proxy_port.set_text(self.configuration.combine_port_only("socks"))
+        self.socks_proxy_port.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.socks_proxy_port.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.socks_proxy_details.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
 
         self.cvs_proxy.set_text(self.configuration.combine_host_only("cvs"))
         self.cvs_proxy.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
@@ -201,12 +201,12 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
         if self.configuration.same_proxy:
             self.configuration.split_proxy("https", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
             self.configuration.split_proxy("ftp", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
-            self.configuration.split_proxy("git", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
+            self.configuration.split_proxy("socks", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
             self.configuration.split_proxy("cvs", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
         else:
             self.configuration.split_proxy("https", self.https_proxy.get_text() + ":" + self.https_proxy_port.get_text())
             self.configuration.split_proxy("ftp", self.ftp_proxy.get_text() + ":" + self.ftp_proxy_port.get_text())
-            self.configuration.split_proxy("git", self.git_proxy.get_text() + ":" + self.git_proxy_port.get_text())
+            self.configuration.split_proxy("socks", self.socks_proxy.get_text() + ":" + self.socks_proxy_port.get_text())
             self.configuration.split_proxy("cvs", self.cvs_proxy.get_text() + ":" + self.cvs_proxy_port.get_text())       
 
     def response_cb(self, dialog, response_id):
@@ -555,13 +555,13 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
             self.handler.set_http_proxy(self.configuration.combine_proxy("http"))
             self.handler.set_https_proxy(self.configuration.combine_proxy("https"))
             self.handler.set_ftp_proxy(self.configuration.combine_proxy("ftp"))
-            self.handler.set_git_proxy(self.configuration.combine_host_only("git"), self.configuration.combine_port_only("git"))
+            self.handler.set_socks_proxy(self.configuration.combine_proxy("socks"))
             self.handler.set_cvs_proxy(self.configuration.combine_host_only("cvs"), self.configuration.combine_port_only("cvs"))
         elif self.configuration.enable_proxy == False:
             self.handler.set_http_proxy("")
             self.handler.set_https_proxy("")
             self.handler.set_ftp_proxy("")
-            self.handler.set_git_proxy("", "")
+            self.handler.set_socks_proxy("")
             self.handler.set_cvs_proxy("", "")
         self.proxy_test_ran = True
         self.proxy_test_running = True
@@ -673,11 +673,11 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
         self.same_proxy_addresses.append(self.ftp_proxy)
         self.same_proxy_ports.append(self.ftp_proxy_port)
 
-        self.git_proxy, self.git_proxy_port, self.git_proxy_details = self.gen_proxy_entry_widget(
-            "git", self, True, 3)
-        proxy_test_focus += [self.git_proxy, self.git_proxy_port]
-        self.same_proxy_addresses.append(self.git_proxy)
-        self.same_proxy_ports.append(self.git_proxy_port)
+        self.socks_proxy, self.socks_proxy_port, self.socks_proxy_details = self.gen_proxy_entry_widget(
+            "socks", self, True, 3)
+        proxy_test_focus += [self.socks_proxy, self.socks_proxy_port]
+        self.same_proxy_addresses.append(self.socks_proxy)
+        self.same_proxy_ports.append(self.socks_proxy_port)
 
         self.cvs_proxy, self.cvs_proxy_port, self.cvs_proxy_details = self.gen_proxy_entry_widget(
             "cvs", self, True, 4)

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

@@ -367,9 +367,8 @@ class HobHandler(gobject.GObject):
     def set_ftp_proxy(self, ftp_proxy):
         self.runCommand(["setVariable", "ftp_proxy", ftp_proxy])
 
-    def set_git_proxy(self, host, port):
-        self.runCommand(["setVariable", "GIT_PROXY_HOST", host])
-        self.runCommand(["setVariable", "GIT_PROXY_PORT", port])
+    def set_socks_proxy(self, socks_proxy):
+        self.runCommand(["setVariable", "all_proxy", socks_proxy])
 
     def set_cvs_proxy(self, host, port):
         self.runCommand(["setVariable", "CVS_PROXY_HOST", host])
@@ -565,9 +564,7 @@ class HobHandler(gobject.GObject):
 
         params["default_task"] = self.runCommand(["getVariable", "BB_DEFAULT_TASK"]) or "build"
 
-        params["git_proxy_host"] = self.runCommand(["getVariable", "GIT_PROXY_HOST"]) or ""
-        params["git_proxy_port"] = self.runCommand(["getVariable", "GIT_PROXY_PORT"]) or ""
-
+        params["socks_proxy"] = self.runCommand(["getVariable", "all_proxy"]) or ""
         params["http_proxy"] = self.runCommand(["getVariable", "http_proxy"]) or ""
         params["ftp_proxy"] = self.runCommand(["getVariable", "ftp_proxy"]) or ""
         params["https_proxy"] = self.runCommand(["getVariable", "https_proxy"]) or ""

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

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

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

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

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

@@ -142,17 +142,18 @@ class PackageSelectionPage (HobPage):
         # append the tab
         for page in self.pages:
             columns = page['columns']
-            tab = HobViewTable(columns)
+            name = page['name']
+            tab = HobViewTable(columns, name)
             search_names.append(page['search'])
             search_tips.append(page['searchtip'])
             filter = page['filter']
-            sort_model = self.package_model.tree_model(filter)
+            sort_model = self.package_model.tree_model(filter, initial=True)
             tab.set_model(sort_model)
-            tab.connect("toggled", self.table_toggled_cb, page['name'])
-            if page['name'] == "Included packages":
+            tab.connect("toggled", self.table_toggled_cb, name)
+            if name == "Included packages":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            if page['name'] == "All packages":
+            if name == "All packages":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
             self.ins.append_page(tab, page['name'], page['tooltip'])
@@ -287,6 +288,7 @@ class PackageSelectionPage (HobPage):
         self.refresh_selection()
         if not self.builder.customized:
             self.builder.customized = True
+            self.builder.configuration.initial_selected_image = self.builder.configuration.selected_image
             self.builder.configuration.selected_image = self.recipe_model.__custom_image__
             self.builder.rcppkglist_populated()
 

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

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

bitbake/lib/bb/ui/goggle.py

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

bitbake/lib/prserv/serv.py

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

documentation/adt-manual/adt-command.xml

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

documentation/adt-manual/adt-intro.xml

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

documentation/adt-manual/adt-manual.xml

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

documentation/adt-manual/adt-package.xml

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

documentation/adt-manual/adt-prepare.xml

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

documentation/bsp-guide/bsp-guide.xml

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

documentation/bsp-guide/bsp.xml

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

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

@@ -10,18 +10,20 @@
 
         <para>
             Welcome to the Yocto Project Development Manual!
-            This manual gives you an idea of how to use the Yocto Project to
-            develop embedded Linux images and user-space applications to run on
-            targeted devices.
-            Reading this manual gives you an overview of image, kernel, and
+            This manual provides information on how to use the Yocto Project to
+            develop embedded Linux images and user-space applications that
+            run on targeted devices.
+            The manual provides an overview of image, kernel, and
             user-space application development using the Yocto Project.
             Because much of the information in this manual is general, it
             contains many references to other sources where you can find more
             detail.
-            For example, detailed information on Git, repositories and open
-            source in general can be found in many places.
-            Another example is how to get set up to use the Yocto Project,
-            which our Yocto Project Quick Start covers.
+            For example, you can find detailed information on Git, repositories,
+            and open source in general in many places on the Internet.
+            Another example specific to the Yocto Project is how to quickly
+            set up your host development system and build an image, which you
+            find in the
+            <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
             <note>
                 By default, using the Yocto Project creates a Poky distribution.
                 However, you can create your own distribution by providing key
@@ -36,30 +38,33 @@
         </para>
 
         <para>
-            The Yocto Project Development Manual, however, does provide detailed examples
-            on how to change the kernel source code, reconfigure the kernel, and develop
-            an application using the popular <trademark class='trade'>Eclipse</trademark> IDE.
+            The Yocto Project Development Manual does, however, provide
+            guidance and examples on how to change the kernel source code,
+            reconfigure the kernel, and develop an application using the
+            popular <trademark class='trade'>Eclipse</trademark> IDE.
         </para>
     </section>
 
     <section id='what-this-manual-provides'>
-        <title>What this Manual Provides</title>
+        <title>What This Manual Provides</title>
 
         <para>
             The following list describes what you can get from this guide:
             <itemizedlist>
                 <listitem><para>Information that lets you get set
                     up to develop using the Yocto Project.</para></listitem>
-                <listitem><para>Information to help developers who are new to the open source environment
-                    and to the distributed revision control system Git, which the Yocto Project
-                    uses.</para></listitem>
-                <listitem><para>An understanding of common end-to-end development models and tasks.</para></listitem>
-                <listitem><para>Development case overviews for both system development and user-space
-                    applications.</para></listitem>
-                <listitem><para>An overview and understanding of the emulation environment used with
-                    the Yocto Project - the Quick EMUlator (QEMU).</para></listitem>
-                <listitem><para>An understanding of basic kernel architecture and concepts.</para></listitem>
-                <listitem><para>Many references to other sources of related information.</para></listitem>
+                <listitem><para>Information to help developers who are new to
+                    the open source environment and to the distributed revision
+                    control system Git, which the Yocto Project uses.
+                    </para></listitem>
+                <listitem><para>An understanding of common end-to-end
+                    development models and tasks.</para></listitem>
+                <listitem><para>Information about common development tasks
+                    generally used during image development for
+                    embedded devices.
+                    </para></listitem>
+                <listitem><para>Many references to other sources of related
+                    information.</para></listitem>
             </itemizedlist>
         </para>
     </section>
@@ -95,7 +100,7 @@
             need to supplement it with other information.
             The following list presents other sources of information you might find helpful:
             <itemizedlist>
-                <listitem><para><emphasis>The <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:
+                <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:
                     </emphasis> The home page for the Yocto Project provides lots of information on the project
                     as well as links to software and documentation.</para></listitem>
                 <listitem><para><emphasis>
@@ -104,8 +109,7 @@
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference
                     guide to the OpenEmbedded build system known as "Poky."
-                    The manual also contains a reference chapter on Board Support Package (BSP)
-                    layout.</para></listitem>
+                    </para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>:</emphasis>
                     This guide provides information that lets you get going with the Application
@@ -117,13 +121,13 @@
                     Having a commonly understood structure encourages standardization.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>:</emphasis>
-                    This manual describes how to work with Linux Yocto kernels as well as providing a bit
+                    This manual describes how to work with Linux Yocto kernels as well as provides a bit
                     of conceptual information on the construction of the Yocto Linux kernel tree.
                     </para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>:</emphasis>
                     This manual presents a set of common and generally useful tracing and
-                    profiling schemes along with their application (as appropriate) to each tool.
+                    profiling schemes along with their applications (as appropriate) to each tool.
                     </para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://www.youtube.com/watch?v=3ZlOu-gLsh0'>
@@ -134,7 +138,8 @@
                     <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:</emphasis>
                     A list of commonly asked questions and their answers.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-&DISTRO;-release-notes-poky-&POKYVERSION;'>Release Notes</ulink>:</emphasis> Features, updates and known issues for the current
+                    <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>:</emphasis>
+                    Features, updates and known issues for the current
                     release of the Yocto Project.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>
@@ -142,11 +147,13 @@
                     Hob's primary goal is to enable a user to perform common tasks more easily.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_HOME_URL;/download/build-appliance-0'>
-                    Build Appliance</ulink>:</emphasis> A bootable custom embedded Linux image you can
-                    either build using a non-Linux development system (VMware applications) or download
-                    from the Yocto Project website.
-                    See the <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance-manual'>Build Appliance</ulink>
-                    page for more information.</para></listitem>
+                    Build Appliance</ulink>:</emphasis> A virtual machine that
+                    enables you to build and boot a custom embedded Linux image
+                    with the Yocto Project using a non-Linux development system.
+                    For more information, see the
+                    <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance-manual'>Build Appliance</ulink>
+                    page.
+                    </para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>:</emphasis>
                     The bug tracking application the Yocto Project uses.
@@ -159,7 +166,9 @@
                         <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> for a
                             Yocto Project Discussions mailing list.</para></listitem>
                         <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> for a
-                            Yocto Project Discussions mailing list about the Poky build system.</para></listitem>
+                            Yocto Project Discussions mailing list about the
+                            OpenEmbedded build system (Poky).
+                            </para></listitem>
                         <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink>
                             for a mailing list to receive official Yocto Project announcements for developments and
                             as well as Yocto Project milestones.</para></listitem>
@@ -171,16 +180,6 @@
                     Two IRC channels on freenode are available
                     for Yocto Project and Poky discussions: <filename>#yocto</filename> and
                     <filename>#poky</filename>, respectively.</para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
-                    The company that initially developed the Poky project, which is the basis
-                    for the OpenEmbedded build system used by the Yocto Project.
-                    OpenedHand was acquired by Intel Corporation in 2008.</para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
-                    A multinational semiconductor chip manufacturer company whose Software and
-                    Services Group created and supports the Yocto Project.
-                    Intel acquired OpenedHand in 2008.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
                     The build system used by the Yocto Project.
@@ -193,7 +192,7 @@
                 <listitem><para><emphasis>
                     BitBake User Manual:</emphasis>
                     A comprehensive guide to the BitBake tool.
-                    If you want information on BitBake, see the user manual inculded in the
+                    If you want information on BitBake, see the user manual included in the
                     <filename>bitbake/doc/manual</filename> directory of the
                     <link linkend='source-directory'>Source Directory</link>.</para></listitem>
                 <listitem><para><emphasis>

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

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

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

@@ -12,8 +12,10 @@
     closed, proprietary environment.
     Additionally, the Yocto Project uses specific tools and constructs as part of its development
     environment.
-    This chapter specifically addresses open source philosophy, licensing issues, code repositories,
-    the open source distributed version control system Git, and best practices using the Yocto Project.
+    This chapter specifically addresses open source philosophy, using the 
+    Yocto Project in a team environment, source repositories, Yocto Project
+    terms, licensing, the open source distributed version control system Git, 
+    workflows, bug tracking, and how to submit changes.
 </para>
 
 <section id='open-source-philosophy'>
@@ -66,6 +68,9 @@
         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 with these types of situations, this section presents
         some of the project's most successful experiences,
         practices, solutions, and available technologies that work well.
@@ -110,7 +115,7 @@
                         </para></listitem>
                     <listitem><para>Keep your cross-development toolchains
                         updated.
-                        You can do this by provisioning either as new
+                        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.
@@ -215,7 +220,7 @@
             <link linkend='git'>Git</link>.
             Git is a distributed system that is easy to backup
             (each checkout is a backup in itself), allows you to work
-            remotely, and then connect back to the infrastructure.
+            remotely, and then connects back to the infrastructure.
             <note>
                 For information about BitBake and SCMs, see the
                 BitBake manual located in the
@@ -283,23 +288,23 @@
         <para>
             The features of this system are:
             <itemizedlist>
-                <listitem><para>Highlights when commits break the build
+                <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>
+                    builds.</para></listitem>
                 <listitem><para>Allows commit hook triggers,
-                    which trigger builds when commits are made
+                    which trigger builds when commits are made.
                     </para></listitem>
                 <listitem><para>Allows triggering of automated image booting
-                    and testing under the QuickEMUlator (QEMU)
+                    and testing under the QuickEMUlator (QEMU).
                     </para></listitem>
                 <listitem><para>Supports incremental build testing and from
-                    scratch builds</para></listitem>
-                <listitem><para>Shared output that allows developer
-                    testing and historical regression investigation
+                    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
+                <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>
@@ -311,14 +316,14 @@
         <title>Policies and Change Flow</title>
 
         <para>
-            The Yocto Project itself uses a hierarchy structure and a
+            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.
+            and a single maintainer handles the final "top-of-tree" merges.
         </para>
 
         <note>
@@ -356,12 +361,12 @@
             <itemizedlist>
                 <listitem><para>Use <link linkend='git'>Git</link>
                     as the source control system.</para></listitem>
-                <listitem><para>Maintain your metadata in layers that make sense
+                <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
+                <listitem><para>Separate the project's Metadata and code by using
                     separate Git repositories.
                     See the "<link linkend='yocto-project-repositories'>Yocto Project
                     Source Repositories</link>" section for information on these
@@ -376,7 +381,7 @@
                     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
+                <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.
@@ -407,7 +412,7 @@
         This web-based source code browser is organized into categories by function such as
         IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth.
         From the interface, you can click on any particular item in the "Name" column and
-        see the URL at the bottom of the page that you need to set up a Git repository for
+        see the URL at the bottom of the page that you need to clone a Git repository for
         that particular item.
         Having a local Git repository of the Source Directory (poky) allows you to
         make changes, contribute to the history, and ultimately enhance the Yocto Project's
@@ -423,9 +428,9 @@
     </para>
 
     <para>
-        For any supported release of Yocto Project, you can go to the Yocto Project website’s
-        <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink> and get a
-        tarball of the release.
+        For any supported release of Yocto Project, you can go to the 
+        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and 
+        select the "Downloads" tab and get a tarball of the release.
         You can also go to this site to download any supported BSP tarballs.
         Unpacking the tarball gives you a hierarchical Source Directory that lets you develop
         using the Yocto Project.
@@ -439,14 +444,14 @@
     <para>
         In summary, here is where you can get the project files needed for development:
         <itemizedlist>
-            <listitem><para id='source-repositories'><emphasis><ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
+            <listitem><para id='source-repositories'>:S<emphasis><ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
                 This area contains IDE Plugins, Matchbox, Poky, Poky Support, Tools, Yocto Linux Kernel, and Yocto
                 Metadata Layers.
                 You can create local copies of Git repositories for each of these areas.</para>
                 <para>
                 <imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
-            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink></emphasis>
+            <listitem><para><anchor id='index-downloads' />:<emphasis><ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink></emphasis>
                 This area contains index releases such as
                 the <trademark class='trade'>Eclipse</trademark>
                 Yocto Plug-in, miscellaneous support, poky, pseudo, installers for cross-development toolchains,
@@ -454,10 +459,13 @@
                 Downloading and extracting these files does not produce a local copy of the
                 Git repository but rather a snapshot of a particular release or image.</para>
                 <para>
-                <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="4in" />
+                <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="3.5in" />
                 </para></listitem>
-            <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;/download'>Yocto Project Download Page</ulink></emphasis>
-                This page on the Yocto Project website allows you to download any Yocto Project
+            <listitem><para><emphasis>"Downloads" page for the 
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:</emphasis>
+                Access this page by going to the website and then selecting
+                the "Downloads" tab.
+                This page allows you to download any Yocto Project
                 release or Board Support Package (BSP) in tarball form.
                 The tarballs are similar to those found in the
                 <ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink> area.</para>
@@ -479,9 +487,10 @@
             <listitem><para><emphasis>Append Files:</emphasis> Files that append build information to
                 a recipe file.
                 Append files are known as BitBake append files and <filename>.bbappend</filename> files.
-                The OpenEmbedded build system expects every append file to have a corresponding and
-                underlying recipe (<filename>.bb</filename>) file.
-                Furthermore, the append file and the underlying recipe must have the same root filename.
+                The OpenEmbedded build system expects every append file to have a corresponding
+                recipe (<filename>.bb</filename>) file.
+                Furthermore, the append file and corresponding recipe file 
+                must use the same root filename.
                 The filenames can differ only in the file type suffix used (e.g.
                 <filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>).
                 </para>
@@ -500,7 +509,7 @@
                 This term refers to the area used by the OpenEmbedded build system for builds.
                 The area is created when you <filename>source</filename> the setup
                 environment script that is found in the Source Directory
-                (i.e. <filename>&OE_INIT_FILE;</filename>).
+                (i.e. <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>).
                 The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
                 variable points to the Build Directory.</para>
 
@@ -521,22 +530,21 @@
                             <literallayout class='monospaced'>
      $ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION;
                             </literallayout></para></listitem>
-                        <listitem><para>Provide an existing directory to use as the Build Directory.
-                            This example uses the existing <filename>mybuilds</filename> directory
-                            as the Build Directory.
+                        <listitem><para>Provide an existing directory to use as the Build Directory
+                            and use the default <filename>build</filename> name.
                             <literallayout class='monospaced'>
      $ source &OE_INIT_PATH; $HOME/mybuilds/
                             </literallayout></para></listitem>
                     </itemizedlist>
                 </para></listitem>
-            <listitem><para><emphasis>Build System:</emphasis> In the context of the Yocto Project
+            <listitem><para><emphasis>Build System:</emphasis> In the context of the Yocto Project,
                 this term refers to the OpenEmbedded build system used by the project.
                 This build system is based on the project known as "Poky."
                 For some historical information about Poky, see the
-                <link linkend='poky'>Poky</link> term further along in this section.
+                <link linkend='poky'>Poky</link> term.
                 </para></listitem>
             <listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
-                and inheritance allowing commonly used patterns to be defined once and easily used
+                and inheritance so that commonly used patterns can be defined once and then easily used
                 in multiple recipes.
                 Class files end with the <filename>.bbclass</filename> filename extension.
                 </para></listitem>
@@ -546,7 +554,7 @@
                 <link linkend='build-directory'>Build Directory</link>
                 contains user-defined variables that affect each build.
                 The <filename>meta-yocto/conf/distro/poky.conf</filename> configuration file
-                defines Yocto ‘distro’ configuration
+                defines Yocto "distro" configuration
                 variables used only when building with this policy.
                 Machine configuration files, which
                 are located throughout the
@@ -578,18 +586,18 @@
                         The initial compiler needed to bootstrap the toolchain
                         that runs on the host and is used to build software
                         for the target.
-                        This tool is a 'native' package.</para></listitem>
+                        This tool is a "native" package.</para></listitem>
                     <listitem><para><filename>gcc-cross-intermediate</filename>:
                         The second stage of the bootstrap process that runs
                         on the host and builds software for the target.
-                        This tool is a 'native' package.</para></listitem>
+                        This tool is a "native" package.</para></listitem>
                     <listitem><para><filename>gcc-cross</filename>:
                         The the final stage of the bootstrap process that
                         results in the cross compiler that runs on the host
                         and builds software for the target.
                         If you are replacing the cross compiler toolchain
                         with a custom version, this is what you must replace.
-                        This tool is a 'native' package.</para></listitem>
+                        This tool is a "native" package.</para></listitem>
                     <listitem><para><filename>gcc-runtime</filename>:
                         Runtime libraries from the toolchain bootstrapping
                         process.
@@ -599,20 +607,20 @@
                         Stage 1 and 2 of the a cross compiler that runs on the
                         host and builds for the SDK.
                         Often the SDK is not the same target as the host.
-                        This tool is a 'native' binary.</para></listitem>
+                        This tool is a "native" binary.</para></listitem>
                     <listitem><para><filename>gcc-crosssdk</filename>:
                         The final stage of the SDK compiler.
-                        This tool is a 'native' binary.
+                        This tool is a "native" binary.
                         The tool runs on the host and builds for the SDK.
                         </para></listitem>
                     <listitem><para><filename>gcc-cross-canadian</filename>:
                         The compiler that runs on the SDK machine and is
                         included with the SDK that builds software for the
                         target.
-                        This tool is a 'nativesdk' package.</para></listitem>
+                        This tool is a "nativesdk" package.</para></listitem>
                 </itemizedlist></para></listitem>
             <listitem><para><emphasis>Image:</emphasis> An image is the result produced when
-                BitBake processes a given collection of recipes and related metadata.
+                BitBake processes a given collection of recipes and related Metadata.
                 Images are the binary output that run on specific hardware or QEMU
                 and for specific use cases.
                 For a list of the supported image types that the Yocto Project provides, see the
@@ -628,17 +636,17 @@
                 In general, Metadata includes recipes, classes, and
                 configuration files.
                 In the context of the kernel ("kernel Metadata"),
-                it refers to metadata in the <filename>meta</filename>
+                it refers to Metadata in the <filename>meta</filename>
                 branches of the kernel source Git repositories.
                 </para></listitem>
-            <listitem><para id='oe-core'><emphasis>OE-Core:</emphasis> A core set of metadata originating
+            <listitem><para id='oe-core'><emphasis>OE-Core:</emphasis> A core set of Metadata originating
                 with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
-                This metadata is found in the <filename>meta</filename> directory of the source
-                directory.</para></listitem>
+                This Metadata is found in the <filename>meta</filename> directory of the 
+                <link linkend='source-directory'>Source Directory</link>.</para></listitem>
             <listitem><para><emphasis>Package:</emphasis> In the context of the Yocto Project,
                 this term refers to the packaged output from a baked recipe.
                 A package is generally the compiled binaries produced from the recipe's sources.
-                You ‘bake’ something by running it through BitBake.</para>
+                You "bake" something by running it through BitBake.</para>
                 <para>It is worth noting that the term "package" can, in general, have subtle
                 meanings.  For example, the packages referred to in the
                 "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" section are
@@ -658,7 +666,8 @@
                 build system becoming a build system for embedded images.
                 After Intel Corporation acquired OpenedHand, the project poky became the basis for
                 the Yocto Project's build system.
-                Within the Yocto Project source repositories, poky exists as a separate Git repository
+                Within the Yocto Project source repositories, <filename>poky</filename>
+                exists as a separate Git repository
                 that can be cloned to yield a local copy on the host system.
                 Thus, "poky" can refer to the local copy of the Source Directory used to develop within
                 the Yocto Project.</para></listitem>
@@ -682,7 +691,7 @@
                     Be sure that the Source Directory you use does not contain these types
                     of names.
                 </note></para>
-                <para>The Source Directory contains BitBake, Documentation, metadata and
+                <para>The Source Directory contains BitBake, Documentation, Metadata and
                 other files that all support the Yocto Project.
                 Consequently, you must have the Source Directory in place on your development
                 system in order to do any development using the Yocto Project.</para>
@@ -721,7 +730,7 @@
                 "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>"
                 section.</para></listitem>
             <listitem><para><emphasis>Tasks:</emphasis> Arbitrary groups of software Recipes.
-                You simply use Tasks to hold recipes that, when built, usually accomplish a single task.
+                You use tasks to hold recipes that, when built, usually accomplish a single task.
                 For example, a task could contain the recipes for a company’s proprietary or value-add software.
                 Or, the task could contain the recipes that enable graphics.
                 A task is really just another recipe.
@@ -767,12 +776,13 @@
     <para>
         When you build an image using the Yocto Project, the build process uses a
         known list of licenses to ensure compliance.
-        You can find this list in the Yocto Project files directory at
+        You can find this list in the 
+        <link linkend='source-directory'>Source Directory</link> at
         <filename>meta/files/common-licenses</filename>.
         Once the build completes, the list of all licenses found and used during that build are
         kept in the
         <link linkend='build-directory'>Build Directory</link> at
-        <filename>tmp/deploy/images/licenses</filename>.
+        <filename>tmp/deploy/licenses</filename>.
     </para>
 
     <para>
@@ -797,7 +807,6 @@
     <para>
         You can find a list of the combined SPDX and OSI licenses that the Yocto Project uses
         <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
-        This wiki page discusses the license infrastructure used by the Yocto Project.
     </para>
 
     <para>
@@ -814,7 +823,7 @@
         The Yocto Project uses Git, which is a free, open source distributed version control system.
         Git supports distributed development, non-linear development, and can handle large projects.
         It is best that you have some fundamental understanding of how Git tracks projects and
-        how to work with Git if you are going to use Yocto Project for development.
+        how to work with Git if you are going to use the Yocto Project for development.
         This section provides a quick overview of how Git works and provides you with a summary
         of some essential Git commands.
     </para>
@@ -829,7 +838,7 @@
         <title>Repositories, Tags, and Branches</title>
 
         <para>
-            As mentioned earlier in section
+            As mentioned earlier in the section
             "<link linkend='yocto-project-repositories'>Yocto Project Source Repositories</link>",
             the Yocto Project maintains source repositories at
             <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
@@ -842,8 +851,8 @@
             within a project (e.g. a new feature or updated documentation).
             Creating a tree-like structure based on project divergence allows for excellent historical
             information over the life of a project.
-            This methodology also allows for an environment in which you can do lots of
-            local experimentation on a project as you develop changes or new features.
+            This methodology also allows for an environment from which you can do lots of
+            local experimentation on projects as you develop changes or new features.
         </para>
 
         <para>
@@ -860,8 +869,8 @@
             When you clone a Git repository, you end up with an identical copy of the
             repository on your development system.
             Once you have a local copy of a repository, you can take steps to develop locally.
-            For examples on how to clone Git repositories, see the section
-            "<link linkend='getting-setup'>Getting Set Up</link>" earlier in this manual.
+            For examples on how to clone Git repositories, see the 
+            "<link linkend='getting-setup'>Getting Set Up</link>" section.
         </para>
 
         <para>
@@ -902,13 +911,15 @@
      $ cd poky
      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
             </literallayout>
-            In this example, the name of the top-level directory of your local Yocto Project
-            Files Git repository is <filename>poky</filename>,
-            and the name of the local working area (or local branch) you have created and checked
-            out is <filename>&DISTRO_NAME;</filename>.
-            The files in your repository now reflect the same files that are in the
-            <filename>&DISTRO_NAME;</filename> development branch of the Yocto Project's
-            <filename>poky</filename> repository.
+            In this example, the name of the top-level directory of your local 
+            <link linkend='source-directory'>Source Directory</link> 
+            is <filename>poky</filename>,
+            and the name of that local working area (local branch) you just 
+            created and checked out is <filename>&DISTRO_NAME;</filename>.
+            The files in your local repository now reflect the same files that 
+            are in the <filename>&DISTRO_NAME;</filename> development 
+            branch of the Yocto Project's <filename>poky</filename> 
+            upstream repository.
             It is important to understand that when you create and checkout a
             local working branch based on a branch name,
             your local environment matches the "tip" of that development branch
@@ -961,7 +972,7 @@
             Release tag (<filename>&DISTRO_NAME;-&POKYVERSION;</filename>).
             It is important to understand that when you create and checkout a local
             working branch based on a tag, your environment matches a specific point
-            in time and not a development branch.
+            in time and not the entire development branch.
         </para>
     </section>
 
@@ -981,7 +992,7 @@
         </para>
 
         <para>
-            If you don’t know much about Git, we suggest you educate
+            If you don’t know much about Git, you should educate
             yourself by visiting the links previously mentioned.
         </para>
 
@@ -996,24 +1007,24 @@
                 <listitem><para><emphasis><filename>git clone</filename>:</emphasis> Creates a clone of a repository.
                     During collaboration, this command allows you to create a local repository that is on
                     equal footing with a fellow developer’s repository.</para></listitem>
-                <listitem><para><emphasis><filename>git add</filename>:</emphasis> Adds updated file contents
+                <listitem><para><emphasis><filename>git add</filename>:</emphasis> Stages updated file contents
                     to the index that
                     Git uses to track changes.
-                    You must add all files that have changed before you can commit them.</para></listitem>
-                <listitem><para><emphasis><filename>git commit</filename>:</emphasis> Creates a “commit” that documents
+                    You must stage all files that have changed before you can commit them.</para></listitem>
+                <listitem><para><emphasis><filename>git commit</filename>:</emphasis> Creates a "commit" that documents
                     the changes you made.
                     Commits are used for historical purposes, for determining if a maintainer of a project
                     will allow the change, and for ultimately pushing the change from your local Git repository
                     into the project’s upstream (or master) repository.</para></listitem>
                 <listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that
-                    possibly need to be added and committed.</para></listitem>
+                    possibly need staged and committed.</para></listitem>
                 <listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes
                     your working branch.
-                    This command is analogous to “cd”.</para></listitem>
+                    This command is analogous to "cd".</para></listitem>
                 <listitem><para><emphasis><filename>git checkout –b &lt;working-branch&gt;</filename>:</emphasis> Creates
                     a working branch on your local machine where you can isolate work.
                     It is a good idea to use local branches when adding specific features or changes.
-                    This way if you don’t like what you have done you can easily get rid of the work.</para></listitem>
+                    This way if you do not like what you have done you can easily get rid of the work.</para></listitem>
                 <listitem><para><emphasis><filename>git branch</filename>:</emphasis> Reports
                     existing local branches and
                     tells you the branch in which you are currently working.</para></listitem>
@@ -1026,13 +1037,16 @@
                     repository and places it in your local Git repository.
                     You use this command to make sure you are synchronized with the repository
                     from which you are basing changes (.e.g. the master branch).</para></listitem>
-                <listitem><para><emphasis><filename>git push</filename>:</emphasis> Sends all your local changes you
-                    have committed to an upstream Git repository (e.g. a contribution repository).
-                    The maintainer of the project draws from these repositories when adding your changes to the
-                    project’s master repository.</para></listitem>
+                <listitem><para><emphasis><filename>git push</filename>:</emphasis> 
+                    Sends all your committed local changes to an upstream Git 
+                    repository (e.g. a contribution repository).
+                    The maintainer of the project draws from these repositories 
+                    when adding changes to the project’s master repository or
+                    other development branch.
+                    </para></listitem>
                 <listitem><para><emphasis><filename>git merge</filename>:</emphasis> Combines or adds changes from one
                     local branch of your repository with another branch.
-                    When you create a local Git repository, the default branch is named “master”.
+                    When you create a local Git repository, the default branch is named "master".
                     A typical workflow is to create a temporary branch for isolated work, make and commit your
                     changes, switch to your local master branch, merge the changes from the temporary branch into the
                     local master branch, and then delete the temporary branch.</para></listitem>
@@ -1070,17 +1084,19 @@
         tracks every change and whose structure provides branches for all diverging functionality.
         Although there is no need to use Git, many open source projects do so.
         For the Yocto Project, a key individual called the "maintainer" is responsible for the "master"
-        branch of the Git repository.
+        branch of a given Git repository.
         The "master" branch is the “upstream” repository where the final builds of the project occur.
         The maintainer is responsible for allowing changes in from other developers and for
         organizing the underlying branch structure to reflect release strategies and so forth.
-        <note>You can see who is the maintainer for Yocto Project files by examining the
-        <filename>maintainers.inc</filename> file in the Yocto Project
-        <filename>meta-yocto/conf/distro/include</filename> directory.</note>
+        <note>For information on finding out who is responsible (maintains) 
+            for a particular area of code, see the 
+            "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+            section.
+        </note>
     </para>
 
     <para>
-        The project also has contribution repositories known as “contrib” areas.
+        The project also has contribution repositories known as "contrib" areas.
         These areas temporarily hold changes to the project that have been submitted or committed
         by the Yocto Project development team and by community members that contribute to the project.
         The maintainer determines if the changes are qualified to be moved from the "contrib" areas
@@ -1091,7 +1107,7 @@
         Developers (including contributing community members) create and maintain cloned repositories
         of the upstream "master" branch.
         These repositories are local to their development platforms and are used to develop changes.
-        When a developer is satisfied with a particular feature or change, they “push” the changes
+        When a developer is satisfied with a particular feature or change, they "push" the changes
         to the appropriate "contrib" repository.
     </para>
 
@@ -1099,14 +1115,14 @@
         Developers are responsible for keeping their local repository up-to-date with "master".
         They are also responsible for straightening out any conflicts that might arise within files
         that are being worked on simultaneously by more than one person.
-        All this work is done locally on the developer’s machine before anything is pushed to a
+        All this work is done locally on the developer’s machines before anything is pushed to a
         "contrib" area and examined at the maintainer’s level.
     </para>
 
     <para>
         A somewhat formal method exists by which developers commit changes and push them into the
         "contrib" area and subsequently request that the maintainer include them into "master"
-        This process is called “submitting a patch” or “submitting a change.”
+        This process is called “submitting a patch” or "submitting a change."
         For information on submitting patches and changes, see the
         "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section.
     </para>
@@ -1136,7 +1152,7 @@
                 to more easily include or refuse changes.</para>
                 <para>It is also good practice to leave the repository in a state that allows you to
                 still successfully build your project.  In other words, do not commit half of a feature,
-                then add the other half in a separate, later commit.
+                then add the other half as a separate, later commit.
                 Each commit should take you from one buildable project state to another
                 buildable state.</para></listitem>
             <listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and
@@ -1144,25 +1160,27 @@
                 You can name these branches anything you like.
                 It is helpful to give them names associated with the particular feature or change
                 on which you are working.
-                Once you are done with a feature or change, simply discard the branch.</para></listitem>
+                Once you are done with a feature or change and have merged it 
+                into your local master branch, simply discard the temporary 
+                branch.</para></listitem>
             <listitem><para><emphasis>Merge Changes:</emphasis> The <filename>git merge</filename>
                 command allows you to take the
                 changes from one branch and fold them into another branch.
                 This process is especially helpful when more than a single developer might be working
                 on different parts of the same feature.
-                Merging changes also automatically identifies any collisions or “conflicts”
+                Merging changes also automatically identifies any collisions or "conflicts"
                 that might happen as a result of the same lines of code being altered by two different
                 developers.</para></listitem>
             <listitem><para><emphasis>Manage Branches:</emphasis> Because branches are easy to use, you should
                 use a system where branches indicate varying levels of code readiness.
-                For example, you can have a “work” branch to develop in, a “test” branch where the code or
-                change is tested, a “stage” branch where changes are ready to be committed, and so forth.
+                For example, you can have a "work" branch to develop in, a "test" branch where the code or
+                change is tested, a "stage" branch where changes are ready to be committed, and so forth.
                 As your project develops, you can merge code across the branches to reflect ever-increasing
                 stable states of the development.</para></listitem>
             <listitem><para><emphasis>Use Push and Pull:</emphasis> The push-pull workflow is based on the
-                concept of developers “pushing” local commits to a remote repository, which is
+                concept of developers "pushing" local commits to a remote repository, which is
                 usually a contribution repository.
-                This workflow is also based on developers “pulling” known states of the project down into their
+                This workflow is also based on developers "pulling" known states of the project down into their
                 local development repositories.
                 The workflow easily allows you to pull changes submitted by other developers from the
                 upstream repository into your work area ensuring that you have the most recent software
@@ -1170,19 +1188,21 @@
                 The Yocto Project has two scripts named <filename>create-pull-request</filename> and
                 <filename>send-pull-request</filename> that ship with the release to facilitate this
                 workflow.
-                You can find these scripts in the local Yocto Project files Git repository in
-                the <filename>scripts</filename> directory.</para>
-                <para>You can find more information on these scripts in the
-                "<link linkend='pushing-a-change-upstream'>Using
-                Scripts to Push a Change Upstream and Request a Pull</link>" section.
+                You can find these scripts in the <filename>scripts</filename>
+                folder of the 
+                <link linkend='source-directory'>Source Directory</link>.
+                For information on how to use these scripts, see the 
+                "<link linkend='pushing-a-change-upstream'>Using Scripts to Push a Change Upstream and Request a Pull</link>" section.
                 </para></listitem>
             <listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the
                 maintainer through an email that you have a change (or patch) you would like considered
                 for the "master" branch of the Git repository.
-                To send this type of change you format the patch and then send the email using the Git commands
+                To send this type of change, you format the patch and then send the email using the Git commands
                 <filename>git format-patch</filename> and <filename>git send-email</filename>.
-                You can find information on how to submit changes
-                later in this chapter.</para></listitem>
+                For information on how to use these scripts, see the 
+                "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                section.
+                </para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -1214,7 +1234,7 @@
                 a bug.</para></listitem>
             <listitem><para>When submitting a new bug, be sure to choose the appropriate
                 Classification, Product, and Component for which the issue was found.
-                Defects for Yocto Project fall into one of six classifications:  Yocto Project
+                Defects for the Yocto Project fall into one of six classifications:  Yocto Project
                 Components, Infrastructure, Build System &amp; Metadata, Documentation,
                 QA/Testing, and Runtime.
                 Each of these Classifications break down into multiple Products and, in some
@@ -1230,9 +1250,14 @@
                 essence of the issue.</para></listitem>
             <listitem><para>Provide a detailed description of the issue.
                 You should provide as much detail as you can about the context, behavior, output,
-                and so forth that surround the issue.
-                You can even attach supporting files for output or log by using the "Add an attachment"
-                button.</para></listitem>
+                and so forth that surrounds the issue.
+                You can even attach supporting files for output from logs by 
+                using the "Add an attachment" button.</para></listitem>
+            <listitem><para>Be sure to copy the appropriate people in the 
+                "CC List" for the bug.  
+                See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                section for information about finding out who is responsible
+                for code.</para></listitem>
             <listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
         </orderedlist>
     </para>
@@ -1247,15 +1272,56 @@
         will want to extend, configure or optimize it for their specific uses.
         You should send patches to the appropriate mailing list so that they
         can be reviewed and merged by the appropriate maintainer.
+    </para>
+
+    <para>
+        Before submitting any change, be sure to find out who you should be
+        notifying.
+        Several methods exist through which you find out who you should be copying
+        or notifying:
+        <itemizedlist>
+            <listitem><para><emphasis>Maintenance File:</emphasis>
+                Examine the <filename>maintainers.inc</filename> file, which is 
+                located in the 
+                <link linkend='source-directory'>Source Directory</link>
+                at <filename>meta-yocto/conf/distro/include</filename>, to 
+                see who is responsible for code.
+                </para></listitem>
+            <listitem><para><emphasis>Board Support Package (BSP) README Files:</emphasis>
+                For BSP maintainers of supported BSPs, you can examine 
+                individual BSP <filename>README</filename> files.
+                Alternatively, you can examine the 
+                <filename>MAINTAINERS</filename> file, which is found in the 
+                <filename>meta-intel</filename>, for a list of all supported
+                BSP maintainers.
+                </para></listitem>
+            <listitem><para><emphasis>Search by File:</emphasis>
+                Using <link linkend='git'>Git</link>, you can enter the 
+                following command to bring up a short list of all commits 
+                against a specific file:
+                <literallayout class='monospaced'>
+     git shortlog -- &lt;filename&gt;
+                </literallayout>
+                Just provide the name of the file for which you are interested.
+                The information returned is not ordered by history but does 
+                include a list of all committers grouped by name. 
+                From the list, you can see who is responsible for the bulk of
+                the changes against the file.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>                
         For a list of the Yocto Project and related mailing lists, see the
         "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in
         the Yocto Project Reference Manual.
     </para>
 
     <para>
-        The following is some guidance on which mailing list to use for what type of change:
+        Here is some guidance on which mailing list to use for what type of change:
         <itemizedlist>
-            <listitem><para>For changes to the core metadata, send your patch to the
+            <listitem><para>For changes to the core 
+                <link linkend='metadata'>Metadata</link>, send your patch to the
                 <ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'>openembedded-core</ulink> mailing list.
                 For example, a change to anything under the <filename>meta</filename> or
                 <filename>scripts</filename> directories
@@ -1270,7 +1336,7 @@
                 layer's documentation specifies otherwise), tools, and Yocto Project
                 documentation, use the
                 <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'>yocto</ulink> mailing list.</para></listitem>
-            <listitem><para>For additional recipes that do not fit into the core metadata,
+            <listitem><para>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. README) supplied
                 with the layer. If in doubt, please ask on the
@@ -1338,7 +1404,7 @@
                 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.
-                This should be prefixed by the recipe name (if changing a recipe), or
+                This short description should be prefixed by the recipe name (if changing a recipe), or
                 else the short form path to the file being changed.
                 </para></listitem>
             <listitem><para>For the body of the commit message, provide detailed information
@@ -1353,7 +1419,7 @@
                 references - any commit that addresses a specific bug should include the
                 bug ID in the description (typically at the beginning) as follows:
                 <literallayout class='monospaced'>
-     [YOCTO #&lt;bug-id&gt;]
+     Fixes YOCTO #&lt;bug-id&gt;
 
      &lt;detailed description of change&gt;
                 </literallayout></para></listitem>
@@ -1369,8 +1435,8 @@
     </para>
 
     <para>
-        Following are general instructions for both pushing changes upstream and for submitting
-        changes as patches.
+        The next two sections describe general instructions for both pushing 
+        changes upstream and for submitting changes as patches.
     </para>
 
     <section id='pushing-a-change-upstream'>
@@ -1420,16 +1486,16 @@
         <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.
-            Keep in mind, the preferred method is to use the scripts, however.
+            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 list in the
-            "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section
-            earlier in this manual.
-            For a description of the available mailing lists, see
+            "<link linkend='how-to-submit-a-change'>How to Submit a Change</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>
@@ -1446,7 +1512,7 @@
                     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
+                    <para>When you form a commit, you must follow certain standards established by the
                     Yocto Project development team.
                     See the earlier section
                     "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
@@ -1455,17 +1521,21 @@
                     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, these two commands each take the most recent single commit and
-                    format it as an email message in the current directory:
+                    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 numbered
-                    series of files in the current directory – one for each commit.
+                    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.
@@ -1501,7 +1571,9 @@
                     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,
-                    use the <filename>man git-send-email</filename> command.</para></listitem>
+                    see <filename>GIT-SEND-EMAIL(1)</filename> displayed using 
+                    the <filename>man git-send-email</filename> command.
+                    </para></listitem>
             </itemizedlist>
         </para>
     </section>

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

@@ -72,9 +72,12 @@
             <listitem><para><emphasis>Packages:</emphasis>  The OpenEmbedded build system
                 requires certain packages exist on your development system (e.g. Python 2.6 or 2.7).
                 See "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>"
-                section in the Yocto Project Quick Start for the exact package
-                requirements and the installation commands to install them
-                for the supported distributions.</para></listitem>
+                section in the Yocto Project Quick Start and the 
+                "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>"
+                section in the Yocto Project Reference Manual for the exact 
+                package requirements and the installation commands to install 
+                them for the supported distributions.
+                </para></listitem>
             <listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>
                 You need a release of the Yocto Project.
                 You set that up with a local <link linkend='source-directory'>Source Directory</link>
@@ -85,12 +88,15 @@
                     hierarchical set of files as the "Source Directory."
                 </note>
                 <itemizedlist>
-                    <listitem><para><emphasis>Tarball Extraction:</emphasis>  If you are not going to contribute
-                        back into the Yocto Project, you can simply download a Yocto Project release you want
-                        from the website’s <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink>.
-                        Once you have the tarball, just extract it into a directory of your choice.</para>
-                        <para>For example, the following command extracts the Yocto Project &DISTRO;
-                        release tarball
+                    <listitem><para><emphasis>Tarball Extraction:</emphasis>  
+                        If you are not going to contribute back into the Yocto 
+                        Project, you can simply go to the 
+                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>, 
+                        select the "Downloads" tab, and choose what you want.
+                        Once you have the tarball, just extract it into a 
+                        directory of your choice.</para>
+                        <para>For example, the following command extracts the 
+                        Yocto Project &DISTRO; release tarball
                         into the current working directory and sets up the local Source Directory
                         with a top-level folder named <filename>&YOCTO_POKY;</filename>:
                         <literallayout class='monospaced'>
@@ -104,23 +110,23 @@
                         Git repository of the upstream <filename>poky</filename> source repository.
                         Doing so creates a repository with a complete history of changes and allows
                         you to easily submit your changes upstream to the project.
-                        Because you cloned the repository, you have access to all the Yocto Project development
+                        Because you clone the repository, you have access to all the Yocto Project development
                         branches and tag names used in the upstream repository.</para>
-                        <para>The following transcript shows how to clone the <filename>poky</filename>
-                        Git repository into the current working directory.
                         <note>You can view the Yocto Project Source Repositories at
                         <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink></note>
+                        <para>The following transcript shows how to clone the <filename>poky</filename>
+                        Git repository into the current working directory.
                         The command creates the local repository in a directory named <filename>poky</filename>.
                         For information on Git used within the Yocto Project, see the
                         "<link linkend='git'>Git</link>" section.
                         <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
-     Initialized empty Git repository in /home/scottrif/poky/.git/
-     remote: Counting objects: 141863, done.
-     remote: Compressing objects: 100% (38624/38624), done.
-     remote: Total 141863 (delta 99661), reused 141816 (delta 99614)
-     Receiving objects: 100% (141863/141863), 76.64 MiB | 126 KiB/s, done.
-     Resolving deltas: 100% (99661/99661), done.
+     Cloning into 'poky'...
+     remote: Counting objects: 183981, done.
+     remote: Compressing objects: 100% (47428/47428), done.
+     remote: Total 183981 (delta 132271), reused 183703 (delta 132044)
+     Receiving objects: 100% (183981/183981), 89.71 MiB | 2.93 MiB/s, done.
+     Resolving deltas: 100% (132271/132271), done.   
                         </literallayout></para>
                         <para>For another example of how to set up your own local Git repositories, see this
                         <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
@@ -139,33 +145,32 @@
                 For simplicity, it is recommended that you create these structures outside of the
                 Source Directory (usually <filename>poky</filename>).</para>
                 <para>As an example, the following transcript shows how to create the bare clone
-                of the <filename>linux-yocto-3.4</filename> kernel and then create a copy of
+                of the <filename>linux-yocto-3.8</filename> kernel and then create a copy of
                 that clone.
                 <note>When you have a local Yocto Project kernel Git repository, you can
                 reference that repository rather than the upstream Git repository as
                 part of the <filename>clone</filename> command.
                 Doing so can speed up the process.</note></para>
                 <para>In the following example, the bare clone is named
-                <filename>linux-yocto-3.4.git</filename>, while the
-                copy is named <filename>my-linux-yocto-3.4-work</filename>:
+                <filename>linux-yocto-3.8.git</filename>, while the
+                copy is named <filename>my-linux-yocto-3.8-work</filename>:
                 <literallayout class='monospaced'>
-     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.4 linux-yocto-3.4.git
-     Initialized empty Git repository in /home/scottrif/linux-yocto-3.4.git/
-     remote: Counting objects: 2468027, done.
-     remote: Compressing objects: 100% (392255/392255), done.
-     remote: Total 2468027 (delta 2071693), reused 2448773 (delta 2052498)
-     Receiving objects: 100% (2468027/2468027), 530.46 MiB | 129 KiB/s, done.
-     Resolving deltas: 100% (2071693/2071693), done.
-                </literallayout></para>
+     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.8 linux-yocto-3.8.git
+     Cloning into bare repository 'linux-yocto-3.8.git'...
+     remote: Counting objects: 2847090, done.
+     remote: Compressing objects: 100% (454675/454675), done.
+     remote: Total 2847090 (delta 2386170), reused 2825793 (delta 2364886)
+     Receiving objects: 100% (2847090/2847090), 603.19 MiB | 3.54 MiB/s, done.
+     Resolving deltas: 100% (2386170/2386170), done.                </literallayout></para>
                 <para>Now create a clone of the bare clone just created:
                 <literallayout class='monospaced'>
-     $ git clone linux-yocto-3.4.git my-linux-yocto-3.4-work
-     Cloning into 'my-linux-yocto-3.4-work'...
+     $ git clone linux-yocto-3.8.git my-linux-yocto-3.8-work
+     Cloning into 'my-linux-yocto-3.8-work'...
      done.
                 </literallayout></para></listitem>
             <listitem id='poky-extras-repo'><para><emphasis>
                 The <filename>poky-extras</filename> Git Repository</emphasis>:
-                The <filename>poky-extras</filename> Git repository contains metadata needed
+                The <filename>poky-extras</filename> Git repository contains Metadata needed
                 only if you are modifying and building the kernel image.
                 In particular, it contains the kernel BitBake append (<filename>.bbappend</filename>)
                 files that you
@@ -183,13 +188,12 @@
                 <literallayout class='monospaced'>
      $ cd ~/poky
      $ git clone git://git.yoctoproject.org/poky-extras poky-extras
-     Initialized empty Git repository in /home/scottrif/poky/poky-extras/.git/
-     remote: Counting objects: 618, done.
-     remote: Compressing objects: 100% (558/558), done.
-     remote: Total 618 (delta 192), reused 307 (delta 39)
-     Receiving objects: 100% (618/618), 526.26 KiB | 111 KiB/s, done.
-     Resolving deltas: 100% (192/192), done.
-                </literallayout></para></listitem>
+     Cloning into 'poky-extras'...
+     remote: Counting objects: 690, done.
+     remote: Compressing objects: 100% (431/431), done.
+     remote: Total 690 (delta 238), reused 690 (delta 238)
+     Receiving objects: 100% (690/690), 532.60 KiB, done.
+     Resolving deltas: 100% (238/238), done.                </literallayout></para></listitem>
            <listitem><para id='supported-board-support-packages-(bsps)'><emphasis>Supported Board
                 Support Packages (BSPs):</emphasis>
                 The Yocto Project provides a layer called <filename>meta-intel</filename> and
@@ -219,10 +223,12 @@
                 information on BSP Layers.
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>  You can download any released
-                        BSP tarball from the same
-                        <ulink url='&YOCTO_HOME_URL;/download'>download site</ulink> used
+                        BSP tarball from the same "Downloads" page of the 
+                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
                         to get the Yocto Project release.
-                        Once you have the tarball, just extract it into a directory of your choice.
+                        Once on the "Download" page, look for "BSP" under the 
+                        "Type" heading.</para>
+                        <para>Once you have the tarball, just extract it into a directory of your choice.
                         Again, this method just produces a snapshot of the BSP layer in the form
                         of a hierarchical directory structure.</para></listitem>
                     <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are working
@@ -239,12 +245,12 @@
                         <literallayout class='monospaced'>
      $ cd ~/poky
      $ git clone git://git.yoctoproject.org/meta-intel.git
-     Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/
-     remote: Counting objects: 3380, done.
-     remote: Compressing objects: 100% (2750/2750), done.
-     remote: Total 3380 (delta 1689), reused 227 (delta 113)
-     Receiving objects: 100% (3380/3380), 1.77 MiB | 128 KiB/s, done.
-     Resolving deltas: 100% (1689/1689), done.
+     Cloning into 'meta-intel'...
+     remote: Counting objects: 6264, done.
+     remote: Compressing objects: 100% (2135/2135), done.
+     remote: Total 6264 (delta 3321), reused 6235 (delta 3293)
+     Receiving objects: 100% (6264/6264), 2.17 MiB | 2.63 MiB/s, done.
+     Resolving deltas: 100% (3321/3321), done.
                         </literallayout></para>
                         <para>The same
                         <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
@@ -291,7 +297,7 @@
                 a centralized tarball download directory through the
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'>DL_DIR</ulink></filename> variable.</para></listitem>
             <listitem><para>Build the image using the <filename>bitbake</filename> command.
-                If you want information on BitBake, see the user manual inculded in the
+                If you want information on BitBake, see the user manual included in the
                 <filename>bitbake/doc/manual</filename> directory of the
                 <link linkend='source-directory'>Source Directory</link>.</para></listitem>
             <listitem><para>Run the image either on the actual hardware or using the QEMU
@@ -327,7 +333,7 @@
         Regardless of the type of image you are using, you need to download the pre-built kernel
         that you will boot in the QEMU emulator and then download and extract the target root
         filesystem for your target machine’s architecture.
-        You can get architecture-specific binaries and filesystems from
+        You can get architecture-specific binaries and file systems from
         <ulink url='&YOCTO_MACHINES_DL_URL;'>machines</ulink>.
         You can get installation scripts for stand-alone toolchains from
         <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchains</ulink>.
@@ -360,7 +366,7 @@
         You can accomplish this by defining the cross-compiler variable
         (e.g. <filename>export CC="distcc"</filename>).
         Alternatively, if you are using a suitable SDK image or the appropriate
-        stand-alone toolchain is present in <filename>/opt/poky</filename>,
+        stand-alone toolchain is present,
         the toolchain is also automatically used.
     </para>
 
@@ -376,12 +382,12 @@
                 The connection uses standard IP networking.</para></listitem>
             <listitem><para>SSH servers exist in some QEMU images.
                 The <filename>core-image-sato</filename> QEMU image has a Dropbear secure
-                shell (ssh) server that runs with the root password disabled.
+                shell (SSH) server that runs with the root password disabled.
                 The <filename>core-image-basic</filename> and <filename>core-image-lsb</filename> QEMU images
                 have OpenSSH instead of Dropbear.
                 Including these SSH servers allow you to use standard <filename>ssh</filename> and
                 <filename>scp</filename> commands.
-                The <filename>core-image-minimal</filename> QEMU image, however, contains no ssh
+                The <filename>core-image-minimal</filename> QEMU image, however, contains no SSH
                 server.</para></listitem>
             <listitem><para>You can use a provided, user-space NFS server to boot the QEMU session
                 using a local copy of the root filesystem on the host.

documentation/dev-manual/dev-manual.xml

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

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

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

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

@@ -34,7 +34,7 @@
             <itemizedlist>
                 <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" for
                     general information on layers and how to create layers.</para></listitem>
-                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#get-your-layer-setup-for-the-build'>Get Your Layer Setup for the Build</ulink>" for
+                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" for
                     specific instructions on setting up a layer for kernel
                     development.</para></listitem>
             </itemizedlist>
@@ -69,7 +69,7 @@
             See the "<link linkend='creating-and-preparing-a-layer'>Creating and Preparing a Layer</link>"
             section for some general resources.
             You can also see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#get-your-layer-setup-for-the-build'>Get Your Layer Setup for the Build</ulink>" section
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" section
             of the Yocto Project Development Manual for a detailed
             example.
         </para>
@@ -92,10 +92,13 @@
                 <literallayout class='monospaced'>
      <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'>FILESEXTRAPATHS</ulink> := "${THISDIR}/${PN}"
                 </literallayout>
-                The path <filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename> expands
-                to "linux-yocto" in the current directory for this example.
-                If you add any new files that modify the kernel recipe,
-                you need to place them in your layer in the following area:
+                The path <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
+                expands to "linux-yocto" in the current directory for this
+                example.
+                If you add any new files that modify the kernel recipe and you
+                have extended <filename>FILESPATH</filename> as
+                described above, you must place the files in your layer in the
+                following area:
                 <literallayout class='monospaced'>
      &lt;your-layer&gt;/recipes-kernel/linux/linux-yocto/
                 </literallayout>
@@ -149,19 +152,31 @@
                 You can make wholesale or incremental changes to the Linux
                 kernel <filename>.config</filename> file by including a
                 <filename>defconfig</filename> or by specifying
-                configuration fragments in the <filename>SRC_URI</filename>.
+                configuration fragments in the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
             </para>
 
             <para>
                 If you have a complete Linux kernel <filename>.config</filename>
-                file you want to use, copy it to the
-                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink><filename>}</filename>
-                directory within your layer and name it "defconfig".
-                Then, add the following line to your linux-yocto
+                file you want to use, copy it to a directory named
+                <filename>files</filename>, which must be in
+                your layer's <filename>recipes-kernel/linux</filename>
+                directory, and name the file "defconfig".
+                Then, add the following lines to your linux-yocto
                 <filename>.bbappend</filename> file in your layer:
                 <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
      SRC_URI += "file://defconfig"
                 </literallayout>
+                The
+                <filename>SRC_URI</filename> tells the build system how to
+                search for the file, while the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                extends the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+                variable (search directories) to include the
+                <filename>files</filename> directory you created for the
+                configuration changes.
             </para>
 
             <para>
@@ -170,7 +185,7 @@
                 configuration fragment.
                 For example, if you want to add support for a basic serial
                 console, create a file named <filename>8250.cfg</filename> in the
-                <filename>${FILES}</filename> directory with the following
+                <filename>files</filename> directory with the following
                 content (without indentation):
                 <literallayout class='monospaced'>
      CONFIG_SERIAL_8250=y
@@ -181,10 +196,11 @@
      CONFIG_SERIAL_CORE=y
      CONFIG_SERIAL_CORE_CONSOLE=y
                 </literallayout>
-                Next, include this configuration fragment in a
-                <filename>SRC_URI</filename> statement in your
+                Next, include this configuration fragment and extend the
+                <filename>FILESPATH</filename> variable in your
                 <filename>.bbappend</filename> file:
                 <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
      SRC_URI += "file://8250.cfg"
                 </literallayout>
                 The next time you run BitBake to build the Linux kernel, BitBake
@@ -224,6 +240,7 @@
         <section id='tip-dirty-string'>
             <title>"-dirty" String</title>
 
+<!--
             <para>
                 <emphasis>AR - Darrren Hart:</emphasis>  This section
                 originated from the old Yocto Project Kernel Architecture
@@ -232,6 +249,7 @@
                 Darren needs to figure out where we want it and what part
                 of it we want (all, revision???)
             </para>
+-->
 
             <para>
                 If kernel images are being built with "-dirty" on the
@@ -369,7 +387,7 @@
 
      WARNING: There were 2 hardware options requested that do not
               have a corresponding value present in the final ".config" file.
-              This probably means you aren't getting the config you wanted.
+              This probably means you are not't getting the config you wanted.
               The full list can be found in your kernel src dir at:
               meta/cfg/standard/mybsp/mismatch.cfg
                 </literallayout>
@@ -723,7 +741,7 @@
             "What changes have been applied to this tree?"
             Rather than using "grep" across directories to see what has
             changed, you can use Git to inspect or search the kernel tree.
-            Using Git is an efficent way to see what has changed in the tree.
+            Using Git is an efficient way to see what has changed in the tree.
         </para>
 
         <section id='what-changed-in-a-kernel'>
@@ -764,7 +782,7 @@
             </para>
 
             <para>
-                To see short, oneline summaries of changes use the
+                To see short, one line summaries of changes use the
                 <filename>git log</filename> command:
                 <literallayout class='monospaced'>
      $ git log --oneline origin/standard/base..origin/standard/emenlow

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

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

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

@@ -5,6 +5,7 @@
 <chapter id='kernel-dev-intro'>
 <title>Introduction</title>
 
+<!--
 <para>
     <emphasis>AR - Darrren Hart:</emphasis>  See if the concepts in these
     three bullets are adequately covered in somewhere in this manual:
@@ -25,6 +26,7 @@
             ends with their BSP-specific commits.</para></listitem>
     </itemizedlist>
 </para>
+-->
 
     <section id='kernel-dev-overview'>
         <title>Overview</title>

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

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

documentation/kernel-dev/kernel-dev.xml

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

documentation/poky.ent

@@ -1,9 +1,11 @@
-<!ENTITY DISTRO "1.4">
+<!ENTITY DISTRO "1.4.5">
+<!ENTITY DISTRO_COMPRESSED "145">
 <!ENTITY DISTRO_NAME "dylan">
-<!ENTITY YOCTO_DOC_VERSION "1.4">
-<!ENTITY POKYVERSION "9.0">
+<!ENTITY YOCTO_DOC_VERSION "1.4.5">
+<!ENTITY POKYVERSION "9.0.5">
+<!ENTITY POKYVERSION_COMPRESSED "905">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2013">
+<!ENTITY COPYRIGHT_YEAR "2010-2014">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
 <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
 <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
@@ -12,8 +14,9 @@
 <!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
 <!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
 <!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
+<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/download/yocto-project-&DISTRO_COMPRESSED;-poky-&POKYVERSION_COMPRESSED;">
 <!ENTITY OE_HOME_URL "http://www.openembedded.org">
-<!ENTITY OE_LISTS_URL "http://lists.linuxtogo.org/cgi-bin/mailman">
+<!ENTITY OE_LISTS_URL "http://lists.openembedded.org/mailman">
 <!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
 <!ENTITY OH_HOME_URL "http://o-hand.com">
 <!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
@@ -32,7 +35,7 @@
 <!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;">
 <!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/">
 <!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/indigo;">
-<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer">
+<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt-installer">
 <!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2">
 <!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines">
 <!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu">
@@ -56,6 +59,6 @@
      diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \
      ccache">
 <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
-     diffstat texinfo python-curses">
+     diffstat texinfo python-curses patch">
 <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath">

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

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

documentation/profile-manual/profile-manual.xml

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

documentation/ref-manual/faq.xml

@@ -13,19 +13,17 @@
         </question>
         <answer>
             <para>
-                The term "Poky" refers to the specific reference build system that
+                The term "<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>"
+                refers to the specific reference build system that
                 the Yocto Project provides.
                 Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink>
-                and BitBake.
+                and <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>.
                 Thus, the generic term used here for the build system is
                 the "OpenEmbedded build system."
                 Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with
                 changes always being merged to OE-Core or BitBake first before being pulled back
                 into Poky.
                 This practice benefits both projects immediately.
-                For a fuller description of the term "Poky", see the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>poky</ulink> term in the Yocto Project
-                Development Manual.
             </para>
         </answer>
     </qandaentry>
@@ -95,8 +93,11 @@
         </question>
         <answer>
             <para>
-                Support for an additional board is added by creating a BSP layer for it.
+                Support for an additional board is added by creating a
+                Board Support Package (BSP) layer for it.
                 For more information on how to create a BSP layer, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
+                section in the Yocto Project Development Manual and the
                 <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
             </para>
             <para>
@@ -133,9 +134,11 @@
         </question>
         <answer>
             <para>
-                Because the same set of recipes can be used to create output of various formats, the
-                output of an OpenEmbedded build depends on how it was started.
-                Usually, the output is a flashable image ready for the target device.
+                Because you can use the same set of recipes to create output of 
+                various formats, the output of an OpenEmbedded build depends on 
+                how you start it.
+                Usually, the output is a flashable image ready for the target 
+                device.
             </para>
         </answer>
     </qandaentry>
@@ -150,7 +153,7 @@
             <para>
                 To add a package, you need to create a BitBake recipe.
                 For information on how to add a package, see the section
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg'>Adding a Package</ulink>"
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg'>Writing a Recipe to Add a Package to Your Image</ulink>"
                 in the Yocto Project Development Manual.
             </para>
         </answer>
@@ -165,11 +168,13 @@
         </question>
         <answer>
             <para>
-                The OpenEmbedded build system can build packages in various formats such as
-                <filename>ipk</filename> for <filename>opkg</filename>,
-                Debian package (<filename>.deb</filename>), or RPM.
-                The packages can then be upgraded using the package tools on the device, much like
-                on a desktop distribution such as Ubuntu or Fedora.
+                The OpenEmbedded build system can build packages in various 
+                formats such as IPK for OPKG, Debian package 
+                (<filename>.deb</filename>), or RPM.
+                You can then upgrade the packages using the package tools on 
+                the device, much like on a desktop distribution such as 
+                Ubuntu or Fedora. 
+                However, package management on the target is entirely optional.
             </para>
         </answer>
     </qandaentry>
@@ -241,6 +246,17 @@
                 </filename> to "0" or by removing the <filename>linux-2.6-execshield.patch</filename>
                 from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.
             </para>
+
+            <note>
+                <para>For information on distributions that the Yocto Project
+                uses during validation, see the 
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>
+                Wiki page.</para>
+                <para>For notes about using the Yocto Project on a RHEL 4-based
+                host, see the
+                <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>Building on RHEL4</ulink>
+                Wiki page.</para>
+            </note>
         </answer>
     </qandaentry>
 
@@ -248,7 +264,7 @@
         <question>
             <para>
                 I see lots of 404 responses for files on
-                <filename>http://www.yoctoproject.org/sources/*</filename>. Is something wrong?
+                <filename>&YOCTO_HOME_URL;/sources/*</filename>. Is something wrong?
             </para>
         </question>
         <answer>
@@ -257,7 +273,7 @@
                 The OpenEmbedded build system checks any configured source mirrors before downloading
                 from the upstream sources.
                 The build system does this searching for both source archives and
-                pre-checked out versions of SCM managed software.
+                pre-checked out versions of SCM-managed software.
                 These checks help in large installations because it can reduce load on the SCM servers
                 themselves.
                 The address above is one of the default mirrors configured into the
@@ -280,8 +296,10 @@
                 Set <filename><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link>
                 </filename> = "0" in the <filename>.bb</filename> file but make sure the package is
                 manually marked as
-                machine-specific in the case that needs it.
-                The code that handles <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in <filename>base.bbclass</filename>.
+                machine-specific for the case that needs it.
+                The code that handles 
+                <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in 
+                the <filename>meta/classes/base.bbclass</filename> file.
             </para>
         </answer>
     </qandaentry>
@@ -297,14 +315,14 @@
                 Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
                 and you therefore need to specify the proxy settings in a
                 <filename>.wgetrc</filename> file in your home directory.
-                Example settings in that file would be
+                Here are some example settings:
                 <literallayout class='monospaced'>
      http_proxy = http://proxy.yoyodyne.com:18023/
      ftp_proxy = http://proxy.yoyodyne.com:18023/
                 </literallayout>
-                The Yocto Project also includes a <filename>site.conf.sample</filename>
-                file that shows how to configure CVS and Git proxy servers
-                if needed.
+                The Yocto Project also includes a 
+                <filename>site.conf.sample</filename> file that shows how to 
+                configure CVS and Git proxy servers if needed.
             </para>
         </answer>
     </qandaentry>
@@ -334,13 +352,20 @@
         </question>
         <answer>
             <para>
-                If the same build is failing in totally different and random ways,
-                the most likely explanation is that either the hardware you're running the
-                build on has some problem, or, if you are running the build under virtualisation,
-                the virtualisation probably has bugs.
-                The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and
-                CPU activity and is sensitive to even single bit failures in any of these areas.
-                True random failures have always been traced back to hardware or virtualisation issues.
+                If the same build is failing in totally different and random 
+                ways, the most likely explanation is:
+                <itemizedlist>
+                    <listitem><para>The hardware you are running the build on 
+                        has some problem.</para></listitem>
+                    <listitem><para>You are running the build under 
+                        virtualization, in which case the virtualization 
+                        probably has bugs.</para></listitem>   
+                </itemizedlist>
+                The OpenEmbedded build system processes a massive amount of 
+                data that causes lots of network, disk and CPU activity and 
+                is sensitive to even single-bit failures in any of these areas.
+                True random failures have always been traced back to hardware 
+                or virtualization issues.
             </para>
         </answer>
     </qandaentry>
@@ -353,13 +378,22 @@
         </question>
         <answer>
             <para>
-                This is a difficult question and you need to consult your lawyer for the answer
-                for your specific case.
-                It is worth bearing in mind that for GPL compliance there needs to be enough
-                information shipped to allow someone else to rebuild the same end result
-                you are shipping.
-                This means sharing the source code, any patches applied to it, and also any
-                configuration information about how that package was configured and built.
+                This is a difficult question and you need to consult your lawyer 
+                for the answer for your specific case.
+                It is worth bearing in mind that for GPL compliance, there needs 
+                to be enough information shipped to allow someone else to 
+                rebuild and produce the same end result you are shipping.
+                This means sharing the source code, any patches applied to it, 
+                and also any configuration information about how that package 
+                was configured and built.
+            </para>
+
+            <para>
+                You can find more information on licensing in the 
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#licensing'>Licensing</ulink>"
+                and "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+                sections, both of which are in the Yocto Project Development
+                Manual.
             </para>
         </answer>
     </qandaentry>
@@ -374,7 +408,10 @@
             <para>
                 You need to create a form factor file as described in the
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</ulink>"
-                section and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one as follows:
+                section in the Yocto Project Board Support Packages (BSP)
+                Developer's Guide.
+                Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to 
+                one as follows:
                 <literallayout class='monospaced'>
      HAVE_TOUCHSCREEN=1
                 </literallayout>
@@ -395,7 +432,9 @@
                 Therefore, you will need to add a BSP-specific netbase that includes an interfaces
                 file.
                 See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</ulink>"
-                section for information on creating these types of miscellaneous recipe files.
+                section in the Yocto Project Board Support Packages (BSP)
+                Developer's Guide for information on creating these types of 
+                miscellaneous recipe files.
             </para>
             <para>
                 For example, add the following files to your layer:
@@ -415,15 +454,35 @@
         </question>
         <answer>
             <para>
-                Images are created to be 1.2 times the size of the populated root filesystem.
-                To modify this ratio so that there is more free space available, you need to
-                set the configuration value <filename>IMAGE_OVERHEAD_FACTOR</filename>.
-                For example, setting <filename>IMAGE_OVERHEAD_FACTOR</filename> to 1.5 sets
-                the image size ratio to one and a half times the size of the populated
-                root filesystem.
-                <literallayout class='monospaced'>
-     IMAGE_OVERHEAD_FACTOR = "1.5"
-                </literallayout>
+                By default, the OpenEmbedded build system creates images 
+                that are 1.3 times the size of the populated root filesystem.
+                To affect the image size, you need to set various 
+                configurations:
+                <itemizedlist>
+                    <listitem><para><emphasis>Image Size:</emphasis>
+                        The OpenEmbedded build system uses the 
+                        <link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link>
+                        variable to define the size of the image in Kbytes. 
+                        The build system determines the size by taking into 
+                        account the initial root filesystem size before any
+                        modifications such as requested size for the image and 
+                        any requested additional free disk space to be 
+                        added to the image.</para></listitem>
+                    <listitem><para><emphasis>Overhead:</emphasis>
+                        Use the 
+                        <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
+                        variable to define the multiplier that the build system 
+                        applies to the initial image size, which is 1.3 by 
+                        default.</para></listitem>
+                    <listitem><para><emphasis>Additional Free Space:</emphasis>
+                        Use the 
+                        <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
+                        variable to add additional free space to the image.
+                        The build system adds this space to the image after
+                        it determines its 
+                        <filename>IMAGE_ROOTFS_SIZE</filename>.
+                        </para></listitem>
+                </itemizedlist>
             </para>
         </answer>
     </qandaentry>
@@ -436,10 +495,12 @@
         </question>
         <answer>
             <para>
-                The Yocto Project team has tried to do this before but too many of the tools
-                the OpenEmbedded build system depends on such as <filename>autoconf</filename>
-                break when they find spaces in pathnames.
-                Until that situation changes, the team will not support spaces in pathnames.
+                The Yocto Project team has tried to do this before but too 
+                many of the tools the OpenEmbedded build system depends on, 
+                such as <filename>autoconf</filename>, break when they find 
+                spaces in pathnames.
+                Until that situation changes, the team will not support spaces 
+                in pathnames.
             </para>
         </answer>
     </qandaentry>
@@ -454,30 +515,46 @@
             <para>
                 The toolchain configuration is very flexible and customizable.
                 It is primarily controlled with the
-                <filename><link linkend='var-TCMODE'>TCMODE</link></filename> variable.
-                This variable controls which <filename>tcmode-*.inc</filename> file to include
-                from the <filename>meta/conf/distro/include</filename> directory within the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+                <filename><link linkend='var-TCMODE'>TCMODE</link></filename> 
+                variable.
+                This variable controls which <filename>tcmode-*.inc</filename> 
+                file to include from the 
+                <filename>meta/conf/distro/include</filename> directory within 
+                the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             </para>
 
             <para>
                 The default value of <filename>TCMODE</filename> is "default"
                 (i.e. <filename>tcmode-default.inc</filename>).
                 However, other patterns are accepted.
-                In particular, "external-*" refers to external toolchains of which there are some
-                basic examples included in the OpenEmbedded Core (<filename>meta</filename>).
-                You can use your own custom toolchain definition in your own layer
-                (or as defined in the <filename>local.conf</filename> file) at the location
+                In particular, "external-*" refers to external toolchains of 
+                which there are some basic examples included in the 
+                OpenEmbedded Core (<filename>meta</filename>).
+                You can use your own custom toolchain definition in your own 
+                layer (or as defined in the <filename>local.conf</filename> 
+                file) at the location
                 <filename>conf/distro/include/tcmode-*.inc</filename>.
             </para>
 
             <para>
-                In addition to the toolchain configuration, you also need a corresponding toolchain recipe file.
-                This recipe file needs to package up any pre-built objects in the toolchain such as
-                <filename>libgcc</filename>, <filename>libstdcc++</filename>,
-                any locales, and <filename>libc</filename>.
-                An example is the <filename>external-sourcery-toolchain.bb</filename>, which is located
-                in <filename>meta/recipes-core/meta/</filename> within the source directory.
+                In addition to the toolchain configuration, you also need a 
+                corresponding toolchain recipe file.
+                This recipe file needs to package up any pre-built objects in 
+                the toolchain such as <filename>libgcc</filename>, 
+                <filename>libstdcc++</filename>, any locales, and 
+                <filename>libc</filename>.
+                An example is the 
+                <filename>external-sourcery-toolchain.bb</filename>, which is 
+                located in <filename>meta/recipes-core/meta/</filename> within 
+                the Source Directory.
+            </para>
+
+            <para>
+                For information on installing and using cross-development 
+                toolchains, see the 
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+                section in the Yocto Project Application Developer's Guide.
             </para>
         </answer>
     </qandaentry>
@@ -548,8 +625,8 @@
                  <literallayout class='monospaced'>
      BB_FETCH_PREMIRRORONLY = "1"
                  </literallayout>
-                 This statement limits Poky to pulling source from the
-                 <filename>PREMIRRORS</filename> only.
+                 This statement limits the build system to pulling source 
+                 from the <filename>PREMIRRORS</filename> only.
                  Again, this technique is useful for reproducing builds.
              </para>
              <para>
@@ -557,7 +634,8 @@
                  <literallayout class='monospaced'>
      BB_GENERATE_MIRROR_TARBALLS = "1"
                  </literallayout>
-                 This statement tells Poky to generate mirror tarballs.
+                 This statement tells the build system to generate mirror 
+                 tarballs.
                  This technique is useful if you want to create a mirror server.
                  If not, however, the technique can simply waste time during
                  the build.
@@ -567,7 +645,7 @@
                  HTTP-only firewall.
                  You could make the following changes to the
                  <filename>local.conf</filename> configuration file as long as
-                 the <filename>PREMIRRORS</filename> server is up to date:
+                 the <filename>PREMIRRORS</filename> server is current:
                  <literallayout class='monospaced'>
      PREMIRRORS_prepend = "\
      ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
@@ -599,18 +677,21 @@
         <answer>
             <para>
                 Yes - you can easily do this.
-                When you use BitBake to build an image, all the build output goes into the
-                directory created when you source the <filename>oe-init-build-env</filename>
-                setup file.
-                By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+                When you use BitBake to build an image, all the build output 
+                goes into the directory created when you source the 
+                <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                setup script.
+                By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
                 is named <filename>build</filename> but can be named
                 anything you want.
             </para>
 
             <para>
-                Within the build directory is the <filename>tmp</filename> directory.
-                To remove all the build output yet preserve any source code or downloaded files
-                from previous builds, simply remove the <filename>tmp</filename> directory.
+                Within the Build Directory, is the <filename>tmp</filename> 
+                directory.
+                To remove all the build output yet preserve any source code or 
+                downloaded files from previous builds, simply remove the 
+                <filename>tmp</filename> directory.
             </para>
         </answer>
     </qandaentry>

documentation/ref-manual/introduction.xml

@@ -20,7 +20,9 @@
         For task-based information using the Yocto Project, see the
         <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
         and the <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
-        You can also find lots of information on the Yocto Project on the
+        For Board Support Package (BSP) structure information, see the
+        <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+        You can also find lots of Yocto Project information on the
         <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>.
     </para>
 </section>
@@ -31,54 +33,54 @@
         This reference manual consists of the following:
         <itemizedlist>
             <listitem><para><emphasis>
-                <link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis> This chapter
-                provides an overview of the components that make up the Yocto Project
+                <link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis>
+                Provides an overview of the components that make up the Yocto Project
                 followed by information about debugging images created in the Yocto Project.
                 </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='technical-details'>Technical Details</link>:</emphasis>
-                This chapter describes fundamental Yocto Project components as well as an explanation
+                Describes fundamental Yocto Project components as well as an explanation
                 behind how the Yocto Project uses shared state (sstate) cache to speed build time.
                 </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-structure'>Directory Structure</link>:</emphasis>
-                This chapter describes the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> created
+                Describes the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> created
                 either by unpacking a released Yocto Project tarball on your host development system,
                 or by cloning the upstream
                 <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
                 </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-bitbake'>BitBake</link>:</emphasis>
-                This chapter provides an overview of the BitBake tool and its role within
+                Provides an overview of the BitBake tool and its role within
                 the Yocto Project.</para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-classes'>Classes</link>:</emphasis>
-                This chapter describes the classes used in the Yocto Project.</para></listitem>
+                Describes the classes used in the Yocto Project.</para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-images'>Images</link>:</emphasis>
-                This chapter describes the standard images that the Yocto Project supports.
+                Describes the standard images that the Yocto Project supports.
                 </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-features'>Features</link>:</emphasis>
-                This chapter describes mechanisms for creating distribution, machine, and image
+                Describes mechanisms for creating distribution, machine, and image
                 features during the build process using the OpenEmbedded build system.</para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-variables-glos'>Variables Glossary</link>:</emphasis>
-                This chapter presents most variables used by the OpenEmbedded build system, which
-                using BitBake.
+                Presents most variables used by the OpenEmbedded build system, which
+                uses BitBake.
                 Entries describe the function of the variable and how to apply them.
                 </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-varlocality'>Variable Context</link>:</emphasis>
-                This chapter provides variable locality or context.</para></listitem>
+                Provides variable locality or context.</para></listitem>
             <listitem><para><emphasis>
                 <link linkend='faq'>FAQ</link>:</emphasis>
-                This chapter provides answers for commonly asked questions in the Yocto Project
+                Provides answers for commonly asked questions in the Yocto Project
                 development environment.</para></listitem>
             <listitem><para><emphasis>
                 <link linkend='resources'>Contributing to the Yocto Project</link>:</emphasis>
-                This chapter provides guidance on how you can contribute back to the Yocto
+                Provides guidance on how you can contribute back to the Yocto
                 Project.</para></listitem>
         </itemizedlist>
     </para>
@@ -101,10 +103,9 @@
         <para>
             Currently, the Yocto Project is supported on the following distributions:
             <itemizedlist>
-                <listitem><para>Ubuntu 10.04.4 LTS</para></listitem>
+                <listitem><para>Ubuntu 10.04</para></listitem>
                 <listitem><para>Ubuntu 11.10</para></listitem>
-                <listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
-                <listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
+                <listitem><para>Ubuntu 12.04 (LTS)</para></listitem>
                 <listitem><para>Ubuntu 12.10</para></listitem>
                 <listitem><para>Fedora release 16 (Verne)</para></listitem>
                 <listitem><para>Fedora release 17 (Beefy Miracle)</para></listitem>
@@ -113,10 +114,13 @@
                 <listitem><para>CentOS release 5.7 (Final)</para></listitem>
                 <listitem><para>CentOS release 5.8 (Final)</para></listitem>
                 <listitem><para>CentOS release 6.3 (Final)</para></listitem>
-                <listitem><para>Debian GNU/Linux 6.0.6 (squeeze)</para></listitem>
+                <listitem><para>CentOS release 6.4 (Final)</para></listitem>
+                <listitem><para>Debian GNU/Linux 6.0 (squeeze)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.0</para></listitem>
                 <listitem><para>openSUSE 11.4</para></listitem>
                 <listitem><para>openSUSE 12.1</para></listitem>
                 <listitem><para>openSUSE 12.2</para></listitem>
+                <listitem><para>openSUSE 12.3</para></listitem>
             </itemizedlist>
         </para>
 
@@ -133,8 +137,8 @@
         <para>
             The list of packages you need on the host development system can
             be large when covering all build scenarios using the Yocto Project.
-            This section provides required packages by Linux distribution and
-            further categorized by function.
+            This section provides required packages according to
+            Linux distribution and function.
         </para>
 
         <section id='ubuntu-packages'>
@@ -308,11 +312,11 @@
     <para>
         Development using the Yocto Project requires a local
         <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-        You can set up the source directory by downloading a Yocto Project release tarball and unpacking it,
+        You can set up the Source Directory by downloading a Yocto Project release tarball and unpacking it,
         or by cloning a copy of the upstream
         <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
         For information on both these methods, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Setup</ulink>"
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
         section in the Yocto Project Development Manual.
     </para>
 </section>

documentation/ref-manual/migration.xml

@@ -16,7 +16,7 @@
 
     <para>
         This section provides migration information for moving to the
-        Yocto Project 1.3 Release.
+        Yocto Project 1.3 Release from the prior release.
     </para>
 
     <section id='1.3-local-configuration'>
@@ -32,10 +32,10 @@
             <title>SSTATE_MIRRORS</title>
 
             <para>
-                The shared state cache (sstate-cache) as pointed to by
-                <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link> by default
-                now has two-character subdirectories to prevent there being an issue with too
-                many files in the same directory.
+                The shared state cache (sstate-cache), as pointed to by
+                <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>, by default
+                now has two-character subdirectories to prevent issues rising
+                from too many files in the same directory.
                 Also, native sstate-cache packages will go into a subdirectory named using
                 the distro ID string.
                 If you copy the newly structured sstate-cache to a mirror location
@@ -55,15 +55,15 @@
             <title>bblayers.conf</title>
 
             <para>
-                The <filename>meta-yocto</filename> layer has been split into
-                two parts: <filename>meta-yocto</filename> and
-                <filename>meta-yocto-bsp</filename>, corresponding to the
-                Poky reference distro configuration and the reference
-                hardware Board Support Packages (BSPs), respectively.
+                The <filename>meta-yocto</filename> layer consists of two parts
+                that correspond to the Poky reference distribution and the
+                reference hardware Board Support Packages (BSPs), respectively:
+                <filename>meta-yocto</filename> and
+                <filename>meta-yocto-bsp</filename>.
                 When running BitBake or Hob for the first time after upgrading,
                 your <filename>conf/bblayers.conf</filename> file will be
                 updated to handle this change and you will be asked to
-                re-run/restart for the changes to take effect.
+                re-run or restart for the changes to take effect.
             </para>
         </section>
     </section>
@@ -171,7 +171,7 @@
                 should now include "splash" instead to enable the boot-up
                 splash screen.
                 Retaining "apps-console-core" will still include the splash
-                screen generates a warning.
+                screen but generates a warning.
                 The "apps-x11-core" and "apps-x11-games"
                 <filename>IMAGE_FEATURES</filename> features have been removed.
             </para>
@@ -183,7 +183,8 @@
             <para>
                 The following recipes have been removed.
                 For most of them, it is unlikely that you would have any
-                references to them in your own metadata.
+                references to them in your own
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>.
                 However, you should check your metadata against this list to be sure:
                 <itemizedlist>
                     <listitem><para><emphasis><filename>libx11-trim</filename></emphasis>:
@@ -220,15 +221,340 @@
                 had become obsolete or broken.
                 Additionally, these recipes were not parsed in the default configuration.
                 Many of these recipes are already provided in an updated and
-                maintained form within OpenEmbedded community layers such as
+                maintained form within the OpenEmbedded community layers such as
                 <filename>meta-oe</filename> and <filename>meta-gnome</filename>.
                 For the remainder, you can now find them in the
                 <filename>meta-extras</filename> repository, which is in the
-                Yocto Project source repositories.
+                Yocto Project
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>.
             </para>
         </section>
     </section>
 </section>
+
+<section id='moving-to-the-yocto-project-1.4-release'>
+    <title>Moving to the Yocto Project 1.4 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.4 Release from the prior release.
+    </para>
+
+    <section id='migration-1.4-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            Differences include the following:
+            <itemizedlist>
+                <listitem><para><emphasis>Comment Continuation:</emphasis>
+                    If a comment ends with a line continuation (\) character, 
+                    then the next line must also be a comment.
+                    Any instance where this is not the case, now triggers 
+                    a warning. 
+                    You must either remove the continuation character, or be 
+                    sure the next line is a comment.
+                    </para></listitem>
+                <listitem><para><emphasis>Package Name Overrides:</emphasis>
+                    The runtime package specific variables 
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                    <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>, 
+                    <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                    <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
+                    <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
+                    <link linkend='var-FILES'><filename>FILES</filename></link>,
+                    <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
+                    and the pre, post, install, and uninstall script functions 
+                    <filename>pkg_preinst</filename>, 
+                    <filename>pkg_postinst</filename>, 
+                    <filename>pkg_prerm</filename>, and 
+                    <filename>pkg_postrm</filename> should always have a
+                    package name override.
+                    For example, use <filename>RDEPENDS_${PN}</filename> for 
+                    the main package instead of <filename>RDEPENDS</filename>.
+                    BitBake uses more strict checks when it parses recipes.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.4-build-behavior'>
+        <title>Build Behavior</title>
+
+        <para>
+            Differences include the following:
+            <itemizedlist>
+                <listitem><para><emphasis>Shared State Code:</emphasis>
+                    The shared state code has been optimized to avoid running 
+                    unnecessary tasks.
+                    For example, 
+                    <filename>bitbake -c rootfs some-image</filename> from 
+                    shared state no longer populates the target sysroot 
+                    since that is not necessary.
+                    Instead, the system just needs to extract the output 
+                    package contents, re-create the packages, and construct 
+                    the root filesystem. 
+                    This change is unlikely to cause any problems unless 
+                    you have missing declared dependencies.
+                    </para></listitem>
+                <listitem><para><emphasis>Scanning Directory Names:</emphasis>
+                    When scanning for files in 
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>, 
+                    the build system now uses <filename>FILESOVERRIDES</filename>
+                    instead of <filename>OVERRIDES</filename> for the directory 
+                    names. 
+                    In general, the values previously in
+                    <filename>OVERRIDES</filename> are now in 
+                    <filename>FILESOVERRIDES</filename> as well.
+                    However, if you relied upon an additional value 
+                    you previously added to <filename>OVERRIDES</filename>,
+                    you might now need to add it to 
+                    <filename>FILESOVERRIDES</filename> unless you are already 
+                    adding it through the 
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link> 
+                    or <link linkend='var-DISTROOVERRIDES'><filename>DISTROOVERRIDES</filename></link>
+                    variables, as appropriate.
+                    For more related changes, see the
+                    "<link linkend='migration-1.4-variables'>Variables</link>"
+                    section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+
+    <section id='migration-1.4-proxies-and-fetching-source'>
+        <title>Proxies and Fetching Source</title>
+
+        <para>
+            A new <filename>oe-git-proxy</filename> script has been added to 
+            replace previous methods of handling proxies and fetching source 
+            from Git. 
+            See the <filename>meta-yocto/conf/site.conf.sample</filename> file
+            for information on how to use this script.
+        </para>
+    </section>
+
+    <section id='migration-1.4-custom-interfaces-file-netbase-change'>
+        <title>Custom Interfaces File (netbase change)</title>
+
+        <para>
+            If you have created your own custom 
+            <filename>etc/network/interfaces</filename> file by creating 
+            an append file for the <filename>netbase</filename> recipe, 
+            you now need to create an append file for the 
+            <filename>init-ifupdown</filename> recipe instead, which you can 
+            find in the 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            at <filename>meta/recipes-core/init-ifupdown</filename>.
+            For information on how to use append files, see the 
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
+            in the Yocto Project Development Manual.
+        </para>
+    </section>
+
+    <section id='migration-1.4-remote-debugging'>
+        <title>Remote Debugging</title>
+
+        <para>
+            Support for remote debugging with the Eclipse IDE is now 
+            separated into an image feature 
+            (<filename>eclipse-debug</filename>) that corresponds to the 
+            <filename>packagegroup-core-eclipse-debug</filename> package group. 
+            Previously, the debugging feature was included through the 
+            <filename>tools-debug</filename> image feature, which corresponds 
+            to the <filename>packagegroup-core-tools-debug</filename>
+            package group.
+        </para>
+    </section>
+
+    <section id='migration-1.4-variables'>
+        <title>Variables</title>
+
+        <para>
+            The following variables have changed:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>SANITY_TESTED_DISTROS</filename>:</emphasis>
+                    This variable now uses a distribution ID, which is composed 
+                    of the host distributor ID followed by the release.
+                    Previously, 
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    was composed of the description field.
+                    For example, "Ubuntu 12.10" becomes "Ubuntu-12.10". 
+                    You do not need to worry about this change if you are not 
+                    specifically setting this variable, or if you are
+                    specifically setting it to "".
+                    </para></listitem>
+                <listitem><para><emphasis><filename>SRC_URI</filename>:</emphasis>
+                    The <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>, 
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>, 
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>, 
+                    and <filename>FILE_DIRNAME</filename> directories have been 
+                    dropped from the default value of the 
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable, which is used as the search path for finding files 
+                    referred to in 
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>. 
+                    If you have a recipe that relied upon these directories, 
+                    which would be unusual, then you will need to add the 
+                    appropriate paths within the recipe or, alternatively,
+                    rearrange the files. 
+                    The most common locations are still covered by 
+                    <filename>${BP}</filename>, <filename>${BPN}</filename>,
+                    and "files", which all remain in the default value of
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>. 
+                    </para></listitem>
+            </itemizedlist>           
+        </para>
+    </section>
+
+    <section id='migration-target-package-management-with-rpm'>
+        <title>Target Package Management with RPM</title>
+
+        <para>
+            If runtime package management is enabled and the RPM backend 
+            is selected, Smart is now installed for package download, dependency 
+            resolution, and upgrades instead of Zypper.
+            For more information on how to use Smart, run the following command 
+            on the target:
+            <literallayout class='monospaced'>
+     smart --help
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='migration-1.4-recipes-moved'>
+        <title>Recipes Moved</title>
+
+        <para>
+            The following recipes were moved from their previous locations 
+            because they are no longer used by anything in  
+            the OpenEmbedded-Core:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>clutter-box2d</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>evolution-data-server</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gthumb</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gtkhtml2</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gupnp</filename>:</emphasis>
+                    Now resides in the <filename>meta-multimedia</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gypsy</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libcanberra</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libgdata</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libmusicbrainz</filename>:</emphasis>
+                    Now resides in the <filename>meta-multimedia</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>metacity</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>polkit</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>zeroconf</filename>:</emphasis>
+                    Now resides in the <filename>meta-networking</filename> layer.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.4-removals-and-renames'>
+        <title>Removals and Renames</title>
+
+        <para>
+            The following list shows what has been removed or renamed:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>evieext</filename>:</emphasis>
+                    Removed because it has been removed from 
+                    <filename>xserver</filename> since 2008.
+                    </para></listitem>
+                <listitem><para><emphasis>Gtk+ DirectFB:</emphasis>
+                    Removed support because upstream Gtk+ no longer supports it
+                    as of version 2.18.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libxfontcache / xfontcacheproto</filename>:</emphasis>
+                    Removed because they were removed from the Xorg server in 2008.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libxp / libxprintapputil / libxprintutil / printproto</filename>:</emphasis>
+                    Removed because the XPrint server was removed from 
+                    Xorg in 2008.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libxtrap / xtrapproto</filename>:</emphasis>
+                    Removed because their functionality was broken upstream.
+                    </para></listitem>
+                <listitem><para><emphasis>linux-yocto 3.0 kernel:</emphasis>
+                    Removed with linux-yocto 3.8 kernel being added.
+                    The linux-yocto 3.2 and linux-yocto 3.4 kernels remain
+                    as part of the release.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>lsbsetup</filename>:</emphasis>
+                    Removed with functionality now provided by 
+                    <filename>lsbtest</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>matchbox-stroke</filename>:</emphasis>
+                    Removed because it was never more than a proof-of-concept.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>matchbox-wm-2 / matchbox-theme-sato-2</filename>:</emphasis>
+                    Removed because they are not maintained.
+                    However, <filename>matchbox-wm</filename> and  
+                    <filename>matchbox-theme-sato</filename> are still 
+                    provided.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>mesa-dri</filename>:</emphasis>
+                    Renamed to <filename>mesa</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>mesa-xlib</filename>:</emphasis>
+                    Removed because it was no longer useful.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>mutter</filename>:</emphasis>
+                    Removed because nothing ever uses it and the recipe is 
+                    very old.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>orinoco-conf</filename>:</emphasis>
+                    Removed because it has become obsolete.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>update-modules</filename>:</emphasis>
+                    Removed because it is no longer used.
+                    The kernel module <filename>postinstall</filename> and 
+                    <filename>postrm</filename> scripts can now do the same 
+                    task without the use of this script.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>web</filename>:</emphasis>
+                    Removed because it is not maintained.  Superseded by 
+                    <filename>web-webkit</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>xf86bigfontproto</filename>:</emphasis>
+                    Removed because upstream it has been disabled by default 
+                    since 2007.
+                    Nothing uses <filename>xf86bigfontproto</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>xf86rushproto</filename>:</emphasis>
+                    Removed because its dependency in 
+                    <filename>xserver</filename> was spurious and it was
+                    removed in 2005.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>zypper / libzypp / sat-solver</filename>:</emphasis>
+                    Removed and been functionally replaced with Smart 
+                    (<filename>python-smartpm</filename>) when RPM packaging 
+                    is used and package management is enabled on the target.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/ref-manual/ref-bitbake.xml

@@ -7,8 +7,9 @@
     <title>BitBake</title>
 
     <para>
-        BitBake is a program written in Python that interprets the metadata used by the OpenEmbedded
-        build system.
+        BitBake is a program written in Python that interprets the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> used by
+        the OpenEmbedded build system.
         At some point, developers wonder what actually happens when you enter:
         <literallayout class='monospaced'>
      $ bitbake core-image-sato
@@ -109,8 +110,8 @@
             consuming process, a cache is kept to speed up subsequent parsing.
             This cache is invalid if the timestamp of the <filename>.bb</filename>
             file itself changes, or if the timestamps of any of the include,
-            configuration or class files the <filename>.bb</filename>
-            file depends on changes.
+            configuration files or class files on which the
+            <filename>.bb</filename> file depends change.
         </para>
     </section>
 
@@ -258,7 +259,7 @@
             controlling terminal.
             Future versions of BitBake will write the functions to files similar to the way
             shell tasks are handled.
-            Logging will be handled in way similar to shell tasks as well.
+            Logging will be handled in a way similar to shell tasks as well.
         </para>
 
         <para>
@@ -385,7 +386,7 @@ Options:
             BitBake also contains a set of "fetcher" modules that allow
             retrieval of source code from various types of sources.
             For example, BitBake can get source code from a disk with the metadata, from websites,
-            from remote shell accounts or from Source Code Management (SCM) systems
+            from remote shell accounts, or from Source Code Management (SCM) systems
             like <filename>cvs/subversion/git</filename>.
         </para>
 

documentation/ref-manual/ref-classes.xml

@@ -8,13 +8,16 @@
 <para>
     Class files are used to abstract common functionality and share it amongst multiple
     <filename>.bb</filename> files.
-    Any metadata usually found in a <filename>.bb</filename> file can also be placed in a class
+    Any <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> usually
+    found in a <filename>.bb</filename> file can also be placed in a class
     file.
     Class files are identified by the extension <filename>.bbclass</filename> and are usually placed
     in a <filename>classes/</filename> directory beneath the
     <filename>meta*/</filename> directory found in the
     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-    Class files can also be pointed to by BUILDDIR (e.g. <filename>build/</filename>)in the same way as
+    Class files can also be pointed to by
+    <link linkend='var-BUILDDIR'><filename>BUILDDIR</filename></link>
+    (e.g. <filename>build/</filename>) in the same way as
     <filename>.conf</filename> files in the <filename>conf</filename> directory.
     Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
     using the same method by which <filename>.conf</filename> files are searched.
@@ -23,7 +26,16 @@
 <para>
     In most cases inheriting the class is enough to enable its features, although
     for some classes you might need to set variables or override some of the
-    default behaviour.
+    default behavior.
+</para>
+
+<para>
+    This chapter discusses only the most useful and important classes.
+        Other classes do exist within the <filename>meta/classes</filename>
+        directory in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        You can reference the <filename>.bbclass</filename> files directly
+        for more information.
 </para>
 
 <section id='ref-classes-base'>
@@ -62,19 +74,20 @@
         It's useful to have some idea of how the tasks defined by this class work
         and what they do behind the scenes.
         <itemizedlist>
-            <listitem><para><filename>do_configure</filename> &dash; regenerates the
+            <listitem><para><filename>do_configure</filename> &dash; Regenerates the
                 configure script (using <filename>autoreconf</filename>) and then launches it
                 with a standard set of arguments used during cross-compilation.
                 You can pass additional parameters to <filename>configure</filename> through the
                 <filename><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></filename> variable.
                 </para></listitem>
-            <listitem><para><filename>do_compile</filename> &dash; runs <filename>make</filename> with
+            <listitem><para><filename>do_compile</filename> &dash; Runs <filename>make</filename> with
                 arguments that specify the compiler and linker.
                 You can pass additional arguments through
                 the <filename><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></filename> variable.
                 </para></listitem>
-            <listitem><para><filename>do_install</filename> &dash; runs <filename>make install</filename>
-                and passes a DESTDIR option, which takes its value from the standard
+            <listitem><para><filename>do_install</filename> &dash; Runs <filename>make install</filename>
+                and passes a destination directory option, which takes its value
+                from the standard
                 <filename><link linkend='var-DESTDIR'>DESTDIR</link></filename> variable.
                 </para></listitem>
         </itemizedlist>
@@ -158,7 +171,7 @@
     <para>
         This class renames packages so that they follow the Debian naming
         policy (i.e. <filename>eglibc</filename> becomes <filename>libc6</filename>
-        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.
+        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.)
     </para>
 </section>
 
@@ -166,8 +179,10 @@
     <title>Pkg-config - <filename>pkgconfig.bbclass</filename></title>
 
     <para>
-        <filename>pkg-config</filename> brought standardization and this class aims to make its
-        integration smooth for all libraries that make use of it.
+        <filename>pkg-config</filename> provides a standard way to get 
+        header and library information.
+        This class aims to smooth integration of
+        <filename>pkg-config</filename> into libraries that use it.
     </para>
 
     <para>
@@ -178,35 +193,26 @@
     </para>
 </section>
 
-<section id='ref-classes-src-distribute'>
-    <title>Distribution of Sources - <filename>src_distribute_local.bbclass</filename></title>
+<section id='ref-classes-archiver'>
+    <title>Archiving Sources - <filename>archive*.bbclass</filename></title>
 
     <para>
-        Many software licenses require that source files be provided along with the binaries.
-        To simplify this process, two classes were created:
-        <filename>src_distribute.bbclass</filename> and
-        <filename>src_distribute_local.bbclass</filename>.
-    </para>
-
-    <para>
-        The results of these classes are <filename>tmp/deploy/source/</filename>
-        subdirs with sources sorted by
-        <filename><link linkend='var-LICENSE'>LICENSE</link></filename> field.
-        If recipes list few licenses (or have entries like "Bitstream Vera"),
-        the source archive is placed in each license directory.
-    </para>
-
-    <para>
-        This class operates using three modes:
+        Many software licenses require that source code and other materials be
+        released with the binaries. 
+        To help with that task, the following classes are provided:
         <itemizedlist>
-            <listitem><para><emphasis>copy:</emphasis> Copies the files to the
-                distribute directory.</para></listitem>
-            <listitem><para><emphasis>symlink:</emphasis> Symlinks the files to the
-                distribute directory.</para></listitem>
-            <listitem><para><emphasis>move+symlink:</emphasis> Moves the files into
-                the distribute directory and then symlinks them back.</para></listitem>
+            <listitem><filename>archive-original-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-patched-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-configured-sources.bbclass</filename></listitem>
+            <listitem><filename>archiver.bbclass</filename></listitem>
         </itemizedlist>
     </para>
+
+    <para>
+        For more details on the source archiver, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
 </section>
 
 <section id='ref-classes-perl'>
@@ -217,16 +223,16 @@
         These recipes usually only need to point to the source's archive and then inherit the
         proper <filename>.bbclass</filename> file.
         Building is split into two methods depending on which method the module authors used.
-    </para>
-
-    <para>
-        Modules that use old <filename>Makefile.PL</filename>-based build system require
-        <filename>cpan.bbclass</filename> in their recipes.
-    </para>
-
-    <para>
-        Modules that use <filename>Build.PL</filename>-based build system require
-        using <filename>cpan_build.bbclass</filename> in their recipes.
+        <itemizedlist>
+            <listitem><para>Modules that use old
+                <filename>Makefile.PL</filename>-based build system require
+                <filename>cpan.bbclass</filename> in their recipes.
+                </para></listitem>
+            <listitem><para>Modules that use
+                <filename>Build.PL</filename>-based build system require
+                using <filename>cpan_build.bbclass</filename> in their recipes.
+                </para></listitem>
+        </itemizedlist>
     </para>
 </section>
 
@@ -237,17 +243,18 @@
         Recipes for Python extensions are simple.
         These recipes usually only need to point to the source's archive and then inherit
         the proper <filename>.bbclass</filename> file.
-        Building is split into two methods dependling on which method the module authors used.
-    </para>
-
-    <para>
-        Extensions that use an Autotools-based build system require Autotools and
-        <filename>distutils</filename>-based <filename>.bbclasse</filename> files in their recipes.
-    </para>
-
-    <para>
-        Extensions that use <filename>distutils</filename>-based build systems require
-        <filename>distutils.bbclass</filename> in their recipes.
+        Building is split into two methods depending on which method the module authors used.
+        <itemizedlist>
+            <listitem><para>Extensions that use an Autotools-based build system
+                require Autotools and
+                <filename>distutils</filename>-based
+                <filename>.bbclasse</filename> files in their recipes.
+                </para></listitem>
+            <listitem><para>Extensions that use
+                <filename>distutils</filename>-based build systems require
+                <filename>distutils.bbclass</filename> in their recipes.
+                </para></listitem>
+        </itemizedlist>
     </para>
 </section>
 
@@ -267,16 +274,16 @@
     <title>Package Groups - <filename>packagegroup.bbclass</filename></title>
 
     <para>
-        This class sets default values appropriate for package group recipes (such as
+        This class sets default values appropriate for package group recipes (e.g.
         <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>,
         <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>,
         <filename><link linkend='var-ALLOW_EMPTY'>ALLOW_EMPTY</link></filename>,
-        and so forth.
+        and so forth).
         It is highly recommended that all package group recipes inherit this class.
     </para>
     <para>
         For information on how to use this class, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-customtasks'>Customizing Images Using Custom Package Tasks</ulink>"
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-customtasks'>Customizing Images Using Custom Package Groups</ulink>"
         section in the Yocto Project Development Manual.
     </para>
     <para>
@@ -310,36 +317,54 @@
         The first class listed in this variable is used for image generation.
     </para>
 
+    <para>
+        If you take the optional step to set up a repository (package feed)
+        on the development host that can be used by Smart, you can
+        install packages from the feed while you are running the image
+        on the target (i.e. runtime installation of packages).
+        For information on how to set up this repository, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-runtime-package-management'>Setting Up Runtime Package Management</ulink>"
+         in the Yocto Project Development Manual.
+    </para>
+
     <para>
         The package class you choose can affect build-time performance and has space
         ramifications.
-        In general, building a package with RPM takes about thirty percent more time as
-        compared to using IPK to build the same or similar package.
-        This comparison takes into account a complete build of the package with all
-        dependencies previously built.
-        The reason for this discrepancy is because the RPM package manager creates and
-        processes more metadata than the IPK package manager.
+        In general, building a package with IPK takes about thirty percent less
+        time as compared to using RPM to build the same or similar package.
+        This comparison takes into account a complete build of the package with
+        all dependencies previously built.
+        The reason for this discrepancy is because the RPM package manager
+        creates and processes more
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> than the
+        IPK package manager.
         Consequently, you might consider setting <filename>PACKAGE_CLASSES</filename>
         to "package_ipk" if you are building smaller systems.
     </para>
 
     <para>
-        Keep in mind, however, that RPM starts to provide more abilities than IPK due to
-        the fact that it processes more metadata.
-        For example, this information includes individual file types, file checksum generation
-        and evaluation on install, sparse file support, conflict detection and resolution
-        for multilib systems, ACID style upgrade, and repackaging abilities for rollbacks.
+        Before making your decision on package manager, however, you should
+        consider some further things about using RPM:
+        <itemizedlist>
+            <listitem><para>
+                RPM starts to provide more abilities than IPK due to
+                the fact that it processes more metadata.
+                For example, this information includes individual file types,
+                file checksum generation and evaluation on install, sparse file
+                support, conflict detection and resolution for Multilib systems,
+                ACID style upgrade, and repackaging abilities for rollbacks.
+                </para></listitem>
+            <listitem><para>
+                For smaller systems, the extra space used for the Berkley
+                Database and the amount of metadata when using RPM can affect
+                your ability to perform on-device upgrades.
+                </para></listitem>
+        </itemizedlist>
     </para>
 
     <para>
-        Another consideration for packages built using the RPM package manager is space.
-        For smaller systems, the extra space used for the Berkley Database and the amount
-        of metadata can affect your ability to do on-device upgrades.
-    </para>
-
-    <para>
-        You can find additional information on the effects of the package class at these
-        two Yocto Project mailing list links:
+        You can find additional information on the effects of the package
+        class at these two Yocto Project mailing list links:
         <itemizedlist>
             <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006362.html'>
                 https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html</ulink></para></listitem>
@@ -383,16 +408,16 @@
         First, the root filesystem is created from packages using
         one of the <filename>rootfs_*.bbclass</filename>
         files (depending on the package format used) and then the image is created.
-    </para>
-
-    <para>
-        The <filename><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link></filename>
-        variable controls the types of images to generate.
-    </para>
-
-    <para>
-        The <filename><link linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></filename>
-        variable controls the list of packages to install into the image.
+        <itemizedlist>
+            <listitem><para>The
+                <filename><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link></filename>
+                variable controls the types of images to generate.
+                </para></listitem>
+            <listitem><para>The
+                <filename><link linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></filename>
+                variable controls the list of packages to install into the
+                image.</para></listitem>
+        </itemizedlist>
     </para>
 </section>
 
@@ -400,8 +425,8 @@
     <title>Host System Sanity Checks - <filename>sanity.bbclass</filename></title>
 
     <para>
-        This class checks to see if prerequisite software is present so that
-        users can be notified of potential problems that might affect their build.
+        This class checks to see if prerequisite software is present on the host system
+        so that users can be notified of potential problems that might affect their build.
         The class also performs basic user configuration checks from
         the <filename>local.conf</filename> configuration file to
         prevent common mistakes that cause build failures.
@@ -468,8 +493,8 @@
                 The debug files should all be in the <filename>-dbg</filename> package.
                 Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
             <listitem><para><emphasis><filename>arch:</filename></emphasis>
-                Checks the Executable and Linkable Format (ELF) type, bit size and endianness
-                of any binaries to ensure it matches the target architecture.
+                Checks the Executable and Linkable Format (ELF) type, bit size, and endianness
+                of any binaries to ensure they match the target architecture.
                 This test fails if any binaries don't match the type since there would be an
                 incompatibility.
                 Sometimes software, like bootloaders, might need to bypass this check.
@@ -484,14 +509,63 @@
                 which would be a packaging bug.</para></listitem>
             <listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
                 Checks <filename>.pc</filename> files for any
-                <filename>TMPDIR/WORKDIR</filename> paths.
+                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>/<link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                paths.
                 Any <filename>.pc</filename> file containing these paths is incorrect
                 since <filename>pkg-config</filename> itself adds the correct sysroot prefix
                 when the files are accessed.</para></listitem>
+            <listitem><para><emphasis><filename>textrel:</filename></emphasis>
+                Checks for ELF binaries that contain relocations in their 
+                <filename>.text</filename> sections, which can result in a 
+                performance impact at runtime.</para></listitem>
+            <listitem><para><emphasis><filename>pkgvarcheck:</filename></emphasis>
+                Checks through the variables 
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>, 
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>, 
+                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
+                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>, 
+                <link linkend='var-FILES'><filename>FILES</filename></link>,
+                <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
+                <filename>pkg_preinst</filename>, 
+                <filename>pkg_postinst</filename>, 
+                <filename>pkg_prerm</filename>
+                and <filename>pkg_postrm</filename>, and reports if there are 
+                variable sets that are not package-specific.
+                Using these variables without a package suffix is bad practice,
+                and might unnecessarily complicate dependencies of other packages
+                within the same recipe or have other unintended consequences.
+                </para></listitem>
+            <listitem><para><emphasis><filename>xorg-driver-abi:</filename></emphasis>
+                Checks that all packages containing Xorg drivers have ABI 
+                dependencies.
+                The <filename>xserver-xorg</filename> recipe provides driver 
+                ABI names.
+                All drivers should depend on the ABI versions that they have 
+                been built against. 
+                Driver recipes that include 
+                <filename>xorg-driver-input.inc</filename>
+                or <filename>xorg-driver-video.inc</filename> will 
+                automatically get these versions.
+                Consequently, you should only need to explicitly add 
+                dependencies to binary driver recipes.
+                </para></listitem>
+            <listitem><para><emphasis><filename>libexec:</filename></emphasis>
+                Checks if a package contains files in 
+                <filename>/usr/libexec</filename>.
+                This check is not performed if the 
+                <filename>libexecdir</filename> variable has been set 
+                explicitly to <filename>/usr/libexec</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>staticdev:</filename></emphasis>
+                Checks for static library files (<filename>*.a</filename>) in
+                non-<filename>staticdev</filename> packages.
+                </para></listitem>
             <listitem><para><emphasis><filename>la:</filename></emphasis>
                 Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
                 paths.
-                Any <filename>.la</filename> file continaing these paths is incorrect since
+                Any <filename>.la</filename> file containing these paths is incorrect since
                 <filename>libtool</filename> adds the correct sysroot prefix when using the
                 files automatically itself.</para></listitem>
             <listitem><para><emphasis><filename>desktop:</filename></emphasis>
@@ -500,8 +574,63 @@
                 the specification for <filename>.desktop</filename> files.</para></listitem>
         </itemizedlist>
     </para>
+    <note>
+        You can use the <filename>WARN_QA</filename> and 
+        <filename>ERROR_QA</filename> variables to control the behavior of 
+        these checks at the global level (i.e. in your custom distro 
+        configuration).
+        However, to skip one or more checks in recipes, you should use 
+        <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>. 
+        For example, to skip the check for symbolic link 
+        <filename>.so</filename> files in the main package of a recipe, 
+        add the following to the recipe.
+        You need to realize that the package name override, in this example
+        <filename>${PN}</filename>, must be used:
+        <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+        </literallayout>
+        Please keep in mind that the QA checks exist in order to detect real 
+        or potential problems in the packaged output.
+        So exercise caution when disabling these checks.
+    </note>
 </section>
 
+<section id='ref-classes-rm-work'>
+    <title>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></title>
+
+    <para>
+        The OpenEmbedded build system can use a substantial amount of disk 
+        space during the build process.
+        A portion of this space is the work files under the 
+        <filename>${TMPDIR}/work</filename> directory for each recipe. 
+        Once the build system generates the packages for a recipe, the work 
+        files for that recipe are no longer needed.
+        However, by default, the build system preserves these files
+        for inspection and possible debugging purposes.
+        If you would rather have these files deleted to save disk space 
+        as the build progresses, you can enable <filename>rm_work</filename>
+        by adding the following to your <filename>local.conf</filename> file,
+        which is found in the 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        <literallayout class='monospaced'>
+    INHERIT += "rm_work"
+        </literallayout>
+        If you are modifying and building source code out of the work directory 
+        for a recipe, enabling <filename>rm_work</filename> will potentially 
+        result in your changes to the source being lost. 
+        To exclude some recipes from having their work directories deleted by
+        <filename>rm_work</filename>, you can add the names of the recipe or 
+        recipes you are working on to the <filename>RM_WORK_EXCLUDE</filename> 
+        variable, which can also be set in your <filename>local.conf</filename>
+        file.
+        Here is an example:
+        <literallayout class='monospaced'>
+    RM_WORK_EXCLUDE += "busybox eglibc"
+        </literallayout>
+    </para>
+</section>
+
+
 <section id='ref-classes-siteinfo'>
     <title>Autotools Configuration Data Cache - <filename>siteinfo.bbclass</filename></title>
 
@@ -540,7 +669,7 @@
         with those packages.
         The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
         recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
-        provides a simple exmample that shows how to add three
+        provides a simple example that shows how to add three
         users and groups to two packages.
         See the <filename>useradd-example.bb</filename> for more information on how to
         use this class.
@@ -595,7 +724,7 @@
         <link linkend='var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link> variable.
         When you do, the <link linkend='var-B'><filename>B</filename></link> variable must support the
         recipe's ability to build variants in different working directories.
-        Most autotools-based recipes support separating these directories.
+        Most Autotools-based recipes support separating these directories.
         The OpenEmbedded build system defaults to using separate directories for <filename>gcc</filename>
         and some kernel recipes.
         Alternatively, you can make sure that separate recipes exist that each
@@ -645,12 +774,16 @@
         deploy.bbclass
         distrodata.bbclass
         dummy.bbclass
+        fontcache.bbclass
         gconf.bbclass
         gettext.bbclass
         gnomebase.bbclass
         gnome.bbclass
+        grub-efi.bbclass
+        gsettings.bbclass
         gtk-doc.bbclass
         gtk-icon-cache.bbclass
+        gtk-immodules-cache.bbclass
         gzipnative.bbclass
         icecc.bbclass
         image-empty.bbclass
@@ -672,6 +805,7 @@
         logging.bbclass
         meta.bbclass
         metadata_scm.bbclass
+        migrate_localcount.bbclass
         mime.bbclass
         mirrors.bbclass
         multilib*.bbclass
@@ -683,12 +817,14 @@
         packageinfo.bbclass
         patch.bbclass
         perlnative.bbclass
+        pixbufcache.bbclass
         pkg_distribute.bbclass
         pkg_metainfo.bbclass
         populate_sdk*.bbclass
         prexport.bbclass
         primport.bbclass
         prserv.bbclass
+        ptest.bbclass
         python-dir.bbclass
         pythonnative.bbclass
         qemu.bbclass
@@ -696,7 +832,6 @@
         qt4*.bbclass
         recipe_sanity.bbclass
         relocatable.bbclass
-        rm_work.bbclass
         scons.bbclass
         sdl.bbclass
         setuptools.bbclass
@@ -706,6 +841,7 @@
         sstate.bbclass
         staging.bbclass
         syslinux.bbclass
+        systemd.bbclass
         terminal.bbclass
         tinderclient.bbclass
         toolchain-scripts.bbclass

documentation/ref-manual/ref-features.xml

@@ -5,6 +5,12 @@
 <chapter id='ref-features'>
     <title>Reference: Features</title>
 
+    <para>
+        This chapter provides a reference of shipped machine and distro features
+        you can include as part of the image, a reference on image types you can
+        build, and a reference on feature backfilling.
+    </para>
+
     <para>
         Features provide a mechanism for working out which packages
         should be included in the generated images.
@@ -27,7 +33,8 @@
     <para>
         One method you can use to determine which recipes are checking to see if a
         particular feature is contained or not is to <filename>grep</filename> through
-        the metadata for the feature.
+        the <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        for the feature.
         Here is an example that discovers the recipes whose build is potentially
         changed based on a given feature:
         <literallayout class='monospaced'>
@@ -36,13 +43,6 @@
         </literallayout>
     </para>
 
-    <para>
-        This chapter provides a reference of shipped machine and distro features
-        you can include as part of the image, a reference on image types you can
-        build, and a reference on feature backfilling.
-    </para>
-
-
     <section id='ref-features-distro'>
         <title>Distro</title>
 
@@ -60,41 +60,51 @@
         <para>
             This list only represents features as shipped with the Yocto Project metadata:
             <itemizedlist>
-                <listitem><para><emphasis>alsa:</emphasis> ALSA support will be included (OSS compatibility
-                    kernel modules will be installed if available).</para></listitem>
+                <listitem><para><emphasis>alsa:</emphasis> Include ALSA support (OSS compatibility
+                    kernel modules installed if available).</para></listitem>
                 <listitem><para><emphasis>bluetooth:</emphasis> Include bluetooth support (integrated BT only)
                     </para></listitem>
+                <listitem><para><emphasis>cramfs:</emphasis> Include CramFS support
+                    </para></listitem>
                 <listitem><para><emphasis>ext2:</emphasis> Include tools for supporting for devices with internal
                     HDD/Microdrive for storing files (instead of Flash only devices)
                     </para></listitem>
+                <listitem><para><emphasis>ipsec:</emphasis> Include IPSec support
+                    </para></listitem>
+                <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support
+                    </para></listitem>
                 <listitem><para><emphasis>irda:</emphasis> Include Irda support
                     </para></listitem>
                 <listitem><para><emphasis>keyboard:</emphasis> Include keyboard support (e.g. keymaps will be
                     loaded during boot).
                     </para></listitem>
+                <listitem><para><emphasis>nfs:</emphasis> Include NFS client support (for mounting NFS exports on
+                    device)</para></listitem>
                 <listitem><para><emphasis>pci:</emphasis> Include PCI bus support
                     </para></listitem>
                 <listitem><para><emphasis>pcmcia:</emphasis> Include PCMCIA/CompactFlash support
                     </para></listitem>
-                <listitem><para><emphasis>usbgadget:</emphasis> USB Gadget Device support (for USB
+                <listitem><para><emphasis>ppp:</emphasis> Include PPP dialup support</para></listitem>
+                <listitem><para><emphasis>smbfs:</emphasis> Include SMB networks client support (for mounting
+                    Samba/Microsoft Windows shares on device)</para></listitem>
+                <listitem><para><emphasis>systemd:</emphasis> Include support
+                    for this <filename>init</filename> manager, which is a full
+                    replacement of for <filename>init</filename> with parallel
+                    starting of services, reduced shell overhead, and other
+                    features.
+                    This <filename>init</filename> manager is used by many
+                    distributions.</para></listitem>
+                <listitem><para><emphasis>usbgadget:</emphasis> Include USB Gadget Device support (for USB
                     networking/serial/storage)
                     </para></listitem>
-                <listitem><para><emphasis>usbhost:</emphasis> USB Host support (allows to connect external
+                <listitem><para><emphasis>usbhost:</emphasis> Include USB Host support (allows to connect external
                     keyboard, mouse, storage, network etc)
                     </para></listitem>
-                <listitem><para><emphasis>wifi:</emphasis> WiFi support (integrated only)
+                <listitem><para><emphasis>wayland:</emphasis> Include the
+                    Wayland display server protocol and the library that
+                    supports it.</para></listitem>
+                <listitem><para><emphasis>wifi:</emphasis> Include WiFi support (integrated only)
                     </para></listitem>
-                <listitem><para><emphasis>cramfs:</emphasis> CramFS support
-                    </para></listitem>
-                <listitem><para><emphasis>ipsec:</emphasis> IPSec support
-                    </para></listitem>
-                <listitem><para><emphasis>ipv6:</emphasis> IPv6 support
-                    </para></listitem>
-                <listitem><para><emphasis>nfs:</emphasis> NFS client support (for mounting NFS exports on
-                    device)</para></listitem>
-                <listitem><para><emphasis>ppp:</emphasis> PPP dialup support</para></listitem>
-                <listitem><para><emphasis>smbfs:</emphasis> SMB networks client support (for mounting
-                    Samba/Microsoft Windows shares on device)</para></listitem>
             </itemizedlist>
         </para>
     </section>
@@ -158,7 +168,7 @@
             <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
             and <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename>
             variables that you typically configure in your image recipes.
-            Through these variables you can add several different
+            Through these variables, you can add several different
             predefined packages such as development utilities or packages with debug
             information needed to investigate application problems or profile applications.
         </para>
@@ -167,6 +177,19 @@
             Current list of
             <filename>IMAGE_FEATURES</filename> contains the following:
             <itemizedlist>
+                <listitem><para><emphasis>dbg-pkgs:</emphasis> Installs debug symbol packages for all packages
+                    installed in a given image.</para></listitem>
+                <listitem><para><emphasis>dev-pkgs:</emphasis> Installs development packages (headers and
+                    extra library links) for all packages installed in a given image.</para></listitem>
+                <listitem><para><emphasis>doc-pkgs:</emphasis> Installs documentation packages for all packages
+                    installed in a given image.</para></listitem>
+                <listitem><para><emphasis>nfs-server:</emphasis> Installs an NFS server.</para></listitem>
+                <listitem><para><emphasis>read-only-fsroot:</emphasis> Creates
+                    an image whose root filesystem is read-only.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"
+                    section in the Yocto Project Development Manual for more
+                    information.</para></listitem>
                 <listitem><para><emphasis>splash:</emphasis> Enables showing a splash screen during boot.
                     By default, this screen is provided by <filename>psplash</filename>, which does
                     allow customization.
@@ -182,31 +205,32 @@
                     Note that if both the OpenSSH SSH server and the Dropbear minimal SSH server
                     are present in <filename>IMAGE_FEATURES</filename>, then OpenSSH will take
                     precedence and Dropbear will not be installed.</para></listitem>
+                <listitem><para><emphasis>staticdev-pkgs:</emphasis> Installs static development
+                    packages (i.e. static libraries containing <filename>*.a</filename> files) for all
+                    packages installed in a given image.</para></listitem>
+                <listitem><para><emphasis>tools-debug:</emphasis> Installs debugging tools such as
+                    <filename>strace</filename> and <filename>gdb</filename>.
+                    For information on GDB, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
+                    section in the Yocto Project Development Manual.
+                    For information on tracing and profiling, see the
+                    <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-profile:</emphasis> Installs profiling tools such as
+                    <filename>oprofile</filename>, <filename>exmap</filename>, and
+                    <filename>LTTng</filename>.
+                    For general information on user-space tools, see the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#user-space-tools'>User-Space Tools</ulink>"
+                    section in the Yocto Project Application Developer's Guide.</para></listitem>
+                <listitem><para><emphasis>tools-sdk:</emphasis> Installs a full SDK that runs on the device.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-testapps:</emphasis> Installs device testing tools (e.g.
+                    touchscreen debugging).</para></listitem>
                 <listitem><para><emphasis>x11:</emphasis> Installs the X server</para></listitem>
                 <listitem><para><emphasis>x11-base:</emphasis> Installs the X server with a
                     minimal environment.</para></listitem>
                 <listitem><para><emphasis>x11-sato:</emphasis> Installs the OpenedHand Sato environment.
                     </para></listitem>
-                <listitem><para><emphasis>tools-sdk:</emphasis> Installs a full SDK that runs on the device.
-                    </para></listitem>
-                <listitem><para><emphasis>tools-debug:</emphasis> Installs debugging tools such as
-                    <filename>strace</filename> and <filename>gdb</filename>.
-                    </para></listitem>
-                <listitem><para><emphasis>tools-profile:</emphasis> Installs profiling tools such as
-                    <filename>oprofile</filename>, <filename>exmap</filename>, and
-                    <filename>LTTng</filename>.</para></listitem>
-                <listitem><para><emphasis>tools-testapps:</emphasis> Installs device testing tools (e.g.
-                    touchscreen debugging).</para></listitem>
-                <listitem><para><emphasis>nfs-server:</emphasis> Installs an NFS server.</para></listitem>
-                <listitem><para><emphasis>dev-pkgs:</emphasis> Installs development packages (headers and
-                    extra library links) for all packages installed in a given image.</para></listitem>
-                <listitem><para><emphasis>staticdev-pkgs:</emphasis> Installs static development
-                    packages (i.e. static libraries containing <filename>*.a</filename> files) for all
-                    packages installed in a given image.</para></listitem>
-                <listitem><para><emphasis>dbg-pkgs:</emphasis> Installs debug symbol packages for all packages
-                    installed in a given image.</para></listitem>
-                <listitem><para><emphasis>doc-pkgs:</emphasis> Installs documentation packages for all packages
-                    installed in a given image.</para></listitem>
             </itemizedlist>
         </para>
     </section>

documentation/ref-manual/ref-images.xml

@@ -31,13 +31,25 @@
         </literallayout>
         These recipes reside in the <filename>meta/recipes-core/images</filename>,
         <filename>meta/recipes-extended/images</filename>,
-        <filename>meta/recipes-graphics/images</filename>, and
-        <filename>meta/recipes-sato/images</filename> directories
-        within the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+        <filename>meta/recipes-graphics/images</filename>,
+        <filename>meta/recipes-qt/images</filename>,
+        <filename>meta/recipes-rt/images</filename>,
+        <filename>meta/recipes-sato/images</filename>, and
+        <filename>meta-skeleton/recipes-multilib/images</filename> directories
+        within the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
         Although the recipe names are somewhat explanatory, here is a list that describes them:
     </para>
 
     <itemizedlist>
+        <listitem><para><emphasis><filename>build-appliance-image</filename>:</emphasis>
+            An example virtual machine that contains all the pieces required to
+            run builds using the build system as well as the build system itself.
+            You can boot and run the image using either the
+            <ulink url='http://www.vmware.com/products/player/overview.html'>VMware Player</ulink>
+            or <ulink url='http://www.vmware.com/products/workstation/overview.html'>VMware Workstation</ulink>.
+            For more information on this image, see the
+            <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on
+            the Yocto Project website.</para></listitem>
         <listitem><para><emphasis><filename>core-image-base</filename>:</emphasis>
             A console-only image that fully supports the target device hardware.</para></listitem>
         <listitem><para><emphasis><filename>core-image-minimal</filename>:</emphasis>
@@ -58,14 +70,12 @@
             for the Minimal MTD Utilities, which let the user interact with the
             MTD subsystem in the kernel to perform operations on flash devices.
             </para></listitem>
-        <listitem><para><emphasis><filename>core-image-x11</filename>:</emphasis>
-            A very basic X11 image with a terminal.
-            </para></listitem>
         <listitem><para><emphasis><filename>core-image-basic</filename>:</emphasis>
             A console-only image with more full-featured Linux system
             functionality installed.</para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb</filename>:</emphasis>
-            An image that conforms to the Linux Standard Base (LSB) specification.</para></listitem>
+            An image that conforms to the Linux Standard Base (LSB) specification.
+            </para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb-dev</filename>:</emphasis>
             A <filename>core-image-lsb</filename> image that is suitable for development work
             using the host.
@@ -79,21 +89,17 @@
         <listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis>
             An image with support for the Open GL-based toolkit Clutter, which enables development of
             rich and animated graphical user interfaces.</para></listitem>
-        <listitem><para><emphasis><filename>core-image-sato</filename>:</emphasis>
-            An image with Sato support, a mobile environment and visual style that works well
-            with mobile devices.
-            The image supports X11 with a Sato theme and applications such as
-            a terminal, editor, file manager, media player, and so forth.</para></listitem>
-        <listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
-            A <filename>core-image-sato</filename> image suitable for development
-            using the host.
-            The image includes libraries needed to build applications on the device itself,
-            testing and profiling tools, and debug symbols.
-            This image was formerly <filename>core-image-sdk</filename>.</para></listitem>
-        <listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis>
-            A <filename>core-image-sato</filename> image that includes everything in meta-toolchain.
-            The image also includes development headers and libraries to form a complete standalone SDK
-            and is suitable for development using the target.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-gtk-directfb</filename>:</emphasis>
+            An image that uses <filename>gtk+</filename> over <filename>directfb</filename>
+            instead of X11.
+            In order to build, this image requires specific distro configuration that enables
+            <filename>gtk</filename> over <filename>directfb</filename>.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-x11</filename>:</emphasis>
+            A very basic X11 image with a terminal.
+            </para></listitem>
+        <listitem><para><emphasis><filename>qt4e-demo-image</filename>:</emphasis>
+            An image that launches into the demo application for the embedded
+            (not based on X11) version of Qt.</para></listitem>
         <listitem><para><emphasis><filename>core-image-rt</filename>:</emphasis>
             A <filename>core-image-minimal</filename> image plus a real-time test suite and
             tools appropriate for real-time use.</para></listitem>
@@ -101,19 +107,30 @@
             A <filename>core-image-rt</filename> image that includes everything in
             <filename>meta-toolchain</filename>.
             The image also includes development headers and libraries to form a complete
-            stand-alone SDK and is suitable for development using the target.</para></listitem>
-        <listitem><para><emphasis><filename>core-image-gtk-directfb</filename>:</emphasis>
-            An image that uses <filename>gtk+</filename> over <filename>directfb</filename>
-            instead of X11.
-            In order to build, this image requires specific distro configuration that enables
-            <filename>gtk</filename> over <filename>directfb</filename>.</para></listitem>
-        <listitem><para><emphasis><filename>build-appliance-image</filename>:</emphasis>
-            An image you can boot and run using either the
-            <ulink url='http://www.vmware.com/products/player/overview.html'>VMware Player</ulink>
-            or <ulink url='http://www.vmware.com/products/workstation/overview.html'>VMware Workstation</ulink>.
-            For more information on this image, see the
-            <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on
-            the Yocto Project website.</para></listitem>
+            stand-alone SDK and is suitable for development using the target.
+            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-sato</filename>:</emphasis>
+            An image with Sato support, a mobile environment and visual style that works well
+            with mobile devices.
+            The image supports X11 with a Sato theme and applications such as
+            a terminal, editor, file manager, media player, and so forth.
+            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
+            A <filename>core-image-sato</filename> image suitable for development
+            using the host.
+            The image includes libraries needed to build applications on the device itself,
+            testing and profiling tools, and debug symbols.
+            This image was formerly <filename>core-image-sdk</filename>.
+            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis>
+            A <filename>core-image-sato</filename> image that includes everything in meta-toolchain.
+            The image also includes development headers and libraries to form a complete standalone SDK
+            and is suitable for development using the target.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-multilib-example</filename>:</emphasis>
+            An example image that includes a <filename>lib32</filename> version
+            of Bash into an otherwise standard <filename>sato</filename> image.
+            The image assumes a "lib32" multilib has been enabled in the your
+            configuration.</para></listitem>
     </itemizedlist>
 
     <tip>

documentation/ref-manual/ref-manual.xml

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

documentation/ref-manual/ref-structure.xml

@@ -27,16 +27,22 @@
 </note>
 
 <section id='structure-core'>
-    <title>Top level core components</title>
+    <title>Top-Level Core Components</title>
+
+    <para>
+        This section describes the top-level components of the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+    </para>
 
     <section id='structure-core-bitbake'>
         <title><filename>bitbake/</filename></title>
 
         <para>
-            The <ulink url='source-directory'>Source Directory</ulink>
-            includes a copy of BitBake for ease of use.
+            This directory includes a copy of BitBake for ease of use.
             The copy usually matches the current stable BitBake release from the BitBake project.
-            BitBake, a metadata interpreter, reads the Yocto Project metadata and runs the tasks
+            BitBake, a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            interpreter, reads the Yocto Project metadata and runs the tasks
             defined by that data.
             Failures are usually from the metadata and not from BitBake itself.
             Consequently, most users do not need to worry about BitBake.
@@ -46,7 +52,7 @@
             When you run the <filename>bitbake</filename> command, the wrapper script in
             <filename>scripts/</filename> is executed to run the main BitBake executable,
             which resides in the <filename>bitbake/bin/</filename> directory.
-            Sourcing the <link linkend="structure-core-script">&OE_INIT_FILE;</link>
+            Sourcing the <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
             script places the <filename>scripts</filename> and <filename>bitbake/bin</filename>
             directories (in that order) into the shell's <filename>PATH</filename> environment
             variable.
@@ -54,7 +60,7 @@
 
         <para>
             For more information on BitBake, see the BitBake documentation
-            inculded in the <filename>bitbake/doc/manual</filename> directory of the
+            included in the <filename>bitbake/doc/manual</filename> directory of the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
         </para>
     </section>
@@ -77,8 +83,10 @@
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
             by providing a directory name when you <filename>source</filename>
             the setup script.
-            For information on separating output from your local Source Directory files, see <link
-            linkend='structure-core-script'>&OE_INIT_FILE;</link>.
+            For information on separating output from your local
+            Source Directory files, see the
+            "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>"
+            section.
         </para>
     </section>
 
@@ -101,8 +109,8 @@
         <para>
             This directory contains the OpenEmbedded Core metadata.
             The directory holds recipes, common classes, and machine
-            configuration for emulated targets (qemux86, qemuarm,
-            and so on.)
+            configuration for emulated targets (<filename>qemux86</filename>,
+            <filename>qemuarm</filename>, and so forth.)
         </para>
     </section>
 
@@ -120,7 +128,10 @@
 
         <para>
             This directory contains the Yocto Project reference
-            hardware BSPs.
+            hardware Board Support Packages (BSPs).
+            For more information on BSPs, see the
+            <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support
+            Package (BSP) Developer's Guide</ulink>.
         </para>
     </section>
 
@@ -128,9 +139,11 @@
         <title><filename>meta-hob/</filename></title>
 
         <para>
-            This directory contains template recipes used by the
-            <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink>
-            build UI.
+            This directory contains template recipes used by Hob,
+            which is a Yocto Project build user interface.
+            For more information on the Hob, see the
+            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob Project</ulink>
+            webpage.
         </para>
     </section>
 
@@ -148,8 +161,9 @@
         <para>
             This directory contains various integration scripts that implement
             extra functionality in the Yocto Project environment (e.g. QEMU scripts).
-            The <link linkend="structure-core-script">&OE_INIT_FILE;</link> script appends this
-            directory to the shell's <filename>PATH</filename> environment variable.
+            The <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
+            script appends this directory to the shell's
+            <filename>PATH</filename> environment variable.
         </para>
 
         <para>
@@ -165,19 +179,20 @@
         <para>
             This script sets up the OpenEmbedded build environment.
             Running this script with the <filename>source</filename> command in
-            a shell makes changes to <filename>PATH</filename> and sets other core BitBake variables based on the
-            current working directory.
+            a shell makes changes to <filename>PATH</filename> and sets other
+            core BitBake variables based on the current working directory.
             You need to run this script before running BitBake commands.
-            The script uses other scripts within the <filename>scripts</filename> directory to do
-            the bulk of the work.
+            The script uses other scripts within the
+            <filename>scripts</filename> directory to do the bulk of the work.
         </para>
 
         <para>
-            By default, running this script without a Build Directory argument creates the
-            <filename>build</filename> directory.
-            If you provide a Build Directory argument when you <filename>source</filename>
-            the script, you direct OpenEmbedded build system to create a
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> of your choice.
+            By default, running this script without a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            argument creates the <filename>build</filename> directory.
+            If you provide a Build Directory argument when you
+            <filename>source</filename> the script, you direct OpenEmbedded
+            build system to create a Build Directory of your choice.
             For example, the following command creates a Build Directory named
             <filename>mybuilds</filename> that is outside of the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
@@ -208,6 +223,13 @@
 <section id='structure-build'>
     <title>The Build Directory - <filename>build/</filename></title>
 
+    <para>
+        The OpenEmbedded build system creates the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+        during the build.
+        By default, this directory is named <filename>build</filename>.
+    </para>
+
     <section id='structure-build-pseudodone'>
         <title><filename>build/pseudodone</filename></title>
 
@@ -235,7 +257,7 @@
             Edit this file to set the <filename><link linkend='var-MACHINE'>MACHINE</link></filename>
             for which you want to build, which package types you wish to use
             (<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>),
-            where you want to downloaded files
+            the location from which you want to downloaded files
             (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>),
             and how you want your host machine to use resources
             (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> and
@@ -247,7 +269,9 @@
         <title><filename>build/conf/bblayers.conf</filename></title>
 
         <para>
-            This file defines layers, which are directory trees, traversed (or walked) by BitBake.
+            This file defines
+            <ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>layers</ulink>,
+            which are directory trees, traversed (or walked) by BitBake.
             If <filename>bblayers.conf</filename>
             is not present, it is created from <filename>bblayers.conf.sample</filename> when
             you <filename>source</filename> the environment setup script.
@@ -267,7 +291,8 @@
         <title><filename>build/conf/sanity_info</filename></title>
 
         <para>
-            This file is created during the build to indicate the state of the sanity checks.
+            This file indicates the state of the sanity checks and is created
+            during the build.
         </para>
     </section>
 
@@ -275,8 +300,9 @@
         <title><filename>build/downloads/</filename></title>
 
         <para>
-            This directory is used for the upstream source tarballs.
-            The directory can be reused by multiple builds or moved to another location.
+            This directory contains downloaded upstream source tarballs.
+            You can reuse the directory for multiple builds or move
+            the directory to another location.
             You can control the location of this directory through the
             <filename><link linkend='var-DL_DIR'>DL_DIR</link></filename> variable.
         </para>
@@ -286,8 +312,9 @@
         <title><filename>build/sstate-cache/</filename></title>
 
         <para>
-            This directory is used for the shared state cache.
-            The directory can be reused by multiple builds or moved to another location.
+            This directory contains the shared state cache.
+            You can reuse the directory for multiple builds or move
+            the directory to another location.
             You can control the location of this directory through the
             <filename><link linkend='var-SSTATE_DIR'>SSTATE_DIR</link></filename> variable.
         </para>
@@ -302,8 +329,8 @@
             As a last resort, to clean up a build and start it from scratch (other than the downloads),
             you can remove everything in the <filename>tmp</filename> directory or get rid of the
             directory completely.
-            If you do, you should also completely remove the <filename>build/sstate-cache</filename>
-            directory as well.
+            If you do, you should also completely remove the
+            <filename>build/sstate-cache</filename> directory.
         </para>
     </section>
 
@@ -321,7 +348,7 @@
         <para>
             When BitBake parses the metadata, it creates a cache file of the result that can
             be used when subsequently running commands.
-            These results are stored here on a per-machine basis.
+            BitBake stores these results here on a per-machine basis.
         </para>
     </section>
 
@@ -329,7 +356,7 @@
         <title><filename>build/tmp/deploy/</filename></title>
 
         <para>
-            This directory contains any 'end result' output from the OpenEmbedded build process.
+            This directory contains any "end result" output from the OpenEmbedded build process.
         </para>
     </section>
 
@@ -361,6 +388,9 @@
             For example, the directory contains sub-directories for <filename>bash</filename>,
             <filename>busybox</filename>, and <filename>eglibc</filename> (among others) that in turn
             contain appropriate <filename>COPYING</filename> license files with other licensing information.
+            For information on licensing, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+            section.
         </para>
     </section>
 
@@ -380,7 +410,7 @@
             However, the kernel (<filename>*zImage*</filename>, <filename>*uImage*</filename>, etc.),
             bootloader and other supplementary files might be deployed here prior to building an
             image.
-            Because these files, however, are not directly produced from the image, if you
+            Because these files are not directly produced from the image, if you
             delete them they will not be automatically re-created when you build the image again.
         </para>
 
@@ -471,7 +501,7 @@
 
         <para>
             It is worth considering the structure of a typical work directory.
-            As an example, consider the <filename>linux-yocto-kernel-3.0</filename>
+            As an example, consider <filename>linux-yocto-kernel-3.0</filename>
             on the machine <filename>qemux86</filename>
             built within the Yocto Project.
             For this package, a work directory of
@@ -479,10 +509,10 @@
             referred to as the
             <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, is created.
             Within this directory, the source is unpacked to
-            <filename>linux-qemux86-standard-build</filename> and then patched by Quilt
-            (see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-a-quilt-workflow'>Modifying Package
-            Source Code with Quilt</ulink>" section in the Yocto Project Development Manual.
+            <filename>linux-qemux86-standard-build</filename> and then patched by Quilt.
+            (See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-a-quilt-workflow'>Using a Quilt Flow</ulink>"
+            section in the Yocto Project Development Manual for more information.)
             Within the <filename>linux-qemux86-standard-build</filename> directory,
             standard Quilt directories <filename>linux-3.0/patches</filename>
             and <filename>linux-3.0/.pc</filename> are created,
@@ -506,7 +536,9 @@
     <title>The Metadata - <filename>meta/</filename></title>
 
     <para>
-        As mentioned previously, metadata is the core of the Yocto Project.
+        As mentioned previously,
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> is the core
+        of the Yocto Project.
         Metadata has several important subdivisions:
     </para>
 
@@ -526,6 +558,11 @@
             such as <filename>image.bbclass</filename>, <filename>rootfs_*.bbclass</filename> and
             <filename>package*.bbclass</filename>.
         </para>
+
+        <para>
+            For reference information on classes, see the
+            "<link linkend='ref-classes'>Classes</link>" chapter.
+        </para>
     </section>
 
     <section id='structure-meta-conf'>
@@ -535,7 +572,8 @@
             This directory contains the core set of configuration files that start from
             <filename>bitbake.conf</filename> and from which all other configuration
             files are included.
-            See the include statements at the end of the file and you will note that even
+            See the include statements at the end of the
+            <filename>bitbake.conf</filename> file and you will note that even
             <filename>local.conf</filename> is loaded from there.
             While <filename>bitbake.conf</filename> sets up the defaults, you can often override
             these by using the (<filename>local.conf</filename>) file, machine file or
@@ -548,7 +586,7 @@
 
         <para>
             This directory contains all the machine configuration files.
-            If you set <filename>MACHINE="qemux86"</filename>,
+            If you set <filename>MACHINE = "qemux86"</filename>,
             the OpenEmbedded build system looks for a <filename>qemux86.conf</filename> file in this
             directory.
             The <filename>include</filename> directory contains various data common to multiple machines.
@@ -560,7 +598,8 @@
         <title><filename>meta/conf/distro/</filename></title>
 
         <para>
-            Any distribution-specific configuration is controlled from this directory.
+            The contents of this directory controls any distribution-specific
+            configurations.
             For the Yocto Project, the <filename>defaultsetup.conf</filename> is the main file here.
             This directory includes the versions and the
             <filename>SRCDATE</filename> definitions for applications that are configured here.
@@ -569,6 +608,26 @@
         </para>
     </section>
 
+    <section id='structure-meta-files'>
+        <title><filename>meta/files/</filename></title>
+
+        <para>
+            This directory contains common license files and several text files
+            used by the build system.
+            The text files contain minimal device information and
+            lists of files and directories with knows permissions.
+        </para>
+    </section>
+
+    <section id='structure-meta-lib'>
+        <title><filename>meta/lib/</filename></title>
+
+        <para>
+            This directory contains OpenEmbedded Python library code
+            used during the build process.
+        </para>
+    </section>
+
     <section id='structure-meta-recipes-bsp'>
         <title><filename>meta/recipes-bsp/</filename></title>
 
@@ -640,6 +699,15 @@
         </para>
     </section>
 
+    <section id='structure-meta-recipes-lsb4'>
+        <title><filename>meta/recipes-lsb4/</filename></title>
+
+        <para>
+            This directory contains recipes specifically added to support
+            the Linux Standard Base (LSB) version 4.x.
+        </para>
+    </section>
+
     <section id='structure-meta-recipes-multimedia'>
         <title><filename>meta/recipes-multimedia/</filename></title>
 
@@ -678,8 +746,9 @@
         <title><filename>meta/recipes-support/</filename></title>
 
         <para>
-            This directory contains recipes that used by other recipes, but that are not directly
-            included in images (i.e. dependencies of other recipes).
+            This directory contains recipes used by other recipes, but that are
+            not directly included in images (i.e. dependencies of other
+            recipes).
         </para>
     </section>
 

documentation/ref-manual/ref-varlocality.xml

@@ -6,7 +6,7 @@
     <title>Variable Context</title>
 
     <para>
-        While most variables can be used in almost any context such as
+        While you can use most variables in almost any context such as
         <filename>.conf</filename>, <filename>.bbclass</filename>,
         <filename>.inc</filename>, and <filename>.bb</filename> files,
         some variables are often associated with a particular locality or context.
@@ -25,7 +25,8 @@
             <title>Distribution (Distro)</title>
 
             <para>
-               This section lists variables whose context is the distribution, or distro.
+               This section lists variables whose configuration context is the
+               distribution, or distro.
                <itemizedlist>
                    <listitem><para><filename><link linkend='var-DISTRO'>DISTRO</link></filename></para></listitem>
                    <listitem><para><filename><link linkend='var-DISTRO_NAME'>DISTRO_NAME</link></filename>
@@ -52,7 +53,8 @@
             <title>Machine</title>
 
             <para>
-                This section lists variables whose context is the machine.
+                This section lists variables whose configuration context is the
+                machine.
                 <itemizedlist>
                     <listitem><para><filename><link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></filename>
                         </para></listitem>
@@ -80,8 +82,9 @@
             <title>Local</title>
 
             <para>
-                This section lists variables whose context is the local configuration through the
-                <filename>local.conf</filename> file.
+                This section lists variables whose configuration context is the
+                local configuration through the <filename>local.conf</filename>
+                file.
                 <itemizedlist>
                     <listitem><para><filename><link linkend='var-DISTRO'>DISTRO</link></filename>
                         </para></listitem>

documentation/ref-manual/resources.xml

@@ -12,7 +12,7 @@
         A number of places exist to find help if you run into difficulties or find bugs.
         To find out how to download source code,
         see the "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto Project Release</ulink>"
-        list item in the Yocto Project Development Manual.
+        section in the Yocto Project Development Manual.
     </para>
 </section>
 
@@ -29,10 +29,11 @@
     <title>Mailing lists</title>
 
     <para>
-        There are a number of mailing lists maintained by the Yocto Project as well as
-        related OpenEmbedded mailing lists for discussion, patch submission and announcements.
-        To subscribe to one of the following mailing lists, click on the appropriate URL
-        in the following list and follow the instructions:
+        A number of mailing lists maintained by the Yocto Project exist 
+        as well as related OpenEmbedded mailing lists for discussion, 
+        patch submission and announcements.
+        To subscribe to one of the following mailing lists, click on the 
+        appropriate URL in the following list and follow the instructions:
         <itemizedlist>
             <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> -
                 General Yocto Project discussion mailing list. </para></listitem>
@@ -41,9 +42,13 @@
             <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/openembedded-devel'></ulink> -
                 Discussion mailing list about OpenEmbedded.</para></listitem>
             <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'></ulink> -
-                Discussion mailing list about the BitBake build tool.</para></listitem>
+                Discussion mailing list about the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+                build tool.</para></listitem>
             <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> -
-                Discussion mailing list about Poky.</para></listitem>
+                Discussion mailing list about 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>.
+                </para></listitem>
             <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink> -
                 Mailing list to receive official Yocto Project release and milestone
                 announcements.</para></listitem>
@@ -67,30 +72,37 @@
     <title>Links</title>
 
     <para>
-        Following is a list of resources you will find helpful:
+        Here is a list of resources you will find helpful:
         <itemizedlist>
-            <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
-                </emphasis> The home site for the Yocto Project.</para></listitem>
-<!--            <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
-                The company where the Yocto Project build system Poky was first developed.
-                OpenedHand has since been acquired by Intel Corporation.</para></listitem> -->
-            <listitem><para><emphasis><ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
-                The company who acquired OpenedHand in 2008 and began development on the
-                Yocto Project.</para></listitem>
-            <listitem><para><emphasis><ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
-                The upstream, generic, embedded distribution used as the basis for the build system in the
-                Yocto Project.
-                Poky derives from and contributes back to the OpenEmbedded project.</para></listitem>
-            <listitem><para><emphasis><ulink url='http://developer.berlios.de/projects/bitbake/'>
+            <listitem><para><emphasis>
+                <ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
+                </emphasis> The home site for the Yocto 
+                Project.</para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
+                The company who acquired OpenedHand in 2008 and began 
+                development on the Yocto Project.</para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
+                The upstream, generic, embedded distribution used as the basis 
+                for the build system in the Yocto Project.
+                Poky derives from and contributes back to the OpenEmbedded 
+                project.</para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='http://developer.berlios.de/projects/bitbake/'>
                 BitBake</ulink>:</emphasis> The tool used to process metadata.</para></listitem>
-            <listitem><para><emphasis>BitBake User Manual:</emphasis>
+            <listitem><para><emphasis>
+                BitBake User Manual:</emphasis>
                 A comprehensive guide to the BitBake tool.
-                You can find the BitBake User Manual in the <filename>bitbake/doc/manual</filename>
-                directory, which is found in the
+                You can find the BitBake User Manual in the 
+                <filename>bitbake/doc/manual</filename> directory, which is 
+                found in the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para></listitem>
-            <listitem><para><emphasis><ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
-                </emphasis> An open source machine emulator and virtualizer.</para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
+                </emphasis> An open source machine emulator and virtualizer.
+                </para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -100,9 +112,11 @@
 
     <para>
         The Yocto Project gladly accepts contributions.
-        You can submit changes to the project either by creating and sending pull requests,
+        You can submit changes to the project either by creating and sending 
+        pull requests,
         or by submitting patches through email.
-        For information on how to do both, see the
+        For information on how to do both as well as information on how
+        to find out who is the maintainer for areas of code, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
         section in the Yocto Project Development Manual.
     </para>

documentation/ref-manual/technical-details.xml

@@ -7,7 +7,8 @@
 
     <para>
         This chapter provides technical details for various parts of the Yocto Project.
-        Currently, topics include Yocto Project components and shared state (sstate) cache.
+        Currently, topics include Yocto Project components,
+        shared state (sstate) cache, x32, and Licenses.
     </para>
 
 <section id='usingpoky-components'>
@@ -16,8 +17,8 @@
     <para>
         The BitBake task executor together with various types of configuration files form the
         OpenEmbedded Core.
-        This section overviews the BitBake task executor and the
-        configuration files by describing what they are used for and how they interact.
+        This section overviews these by describing what they are used for
+        and how they interact.
     </para>
 
     <para>
@@ -25,11 +26,11 @@
         The data itself is of various types:
     <itemizedlist>
         <listitem><para><emphasis>Recipes:</emphasis>  Provides details about particular
-            pieces of software</para></listitem>
-        <listitem><para><emphasis>Class Data:</emphasis>  An abstraction of common build
+            pieces of software.</para></listitem>
+        <listitem><para><emphasis>Class Data:</emphasis>  Abstracts common build
             information (e.g. how to build a Linux kernel).</para></listitem>
         <listitem><para><emphasis>Configuration Data:</emphasis>  Defines machine-specific settings,
-            policy decisions, etc.
+            policy decisions, and so forth.
             Configuration data acts as the glue to bind everything together.</para></listitem>
     </itemizedlist>
         For more information on data, see the
@@ -47,18 +48,20 @@
 
     <para>
         Following are some brief details on these core components.
-        For more detailed information on these components see the
-        "<link linkend='ref-structure'>Directory Structure</link>" chapter.
+        For more detailed information on these components, see the
+        "<link linkend='ref-structure'>Source Directory Structure</link>" chapter.
     </para>
 
     <section id='usingpoky-components-bitbake'>
         <title>BitBake</title>
 
         <para>
-            BitBake is the tool at the heart of the OpenEmbedded build system and is responsible
-            for parsing the metadata, generating a list of tasks from it,
-            and then executing those tasks.
-            To see a list of the options BitBake supports, use the following help command:
+            BitBake is the tool at the heart of the OpenEmbedded build system
+            and is responsible for parsing the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+            generating a list of tasks from it, and then executing those tasks.
+            To see a list of the options BitBake supports, use the following
+            help command:
             <literallayout class='monospaced'>
      $ bitbake --help
             </literallayout>
@@ -125,8 +128,9 @@
         <title>Classes</title>
 
         <para>
-            Class files (<filename>.bbclass</filename>) contain information that is useful to share
-            between metadata files.
+            Class files (<filename>.bbclass</filename>) contain information that
+            is useful to share between
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> files.
             An example is the Autotools class, which contains
             common settings for any application that Autotools uses.
             The "<link linkend='ref-classes'>Classes</link>" chapter provides details
@@ -142,9 +146,9 @@
             that govern the OpenEmbedded build process.
             These files fall into several areas that define machine configuration options,
             distribution configuration options, compiler tuning options, general common configuration
-            options and user configuration options (<filename>local.conf</filename>, which is found
+            options, and user configuration options in <filename>local.conf</filename>, which is found
             in the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>).
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
         </para>
     </section>
 </section>
@@ -154,7 +158,7 @@
 
     <para>
         By design, the OpenEmbedded build system builds everything from scratch unless
-        BitBake can determine that parts don't need to be rebuilt.
+        BitBake can determine that parts do not need to be rebuilt.
         Fundamentally, building from scratch is attractive as it means all parts are
         built fresh and there is no possibility of stale data causing problems.
         When developers hit problems, they typically default back to building from scratch
@@ -166,7 +170,7 @@
         As mentioned in the previous paragraph, building from scratch ensures that
         everything is current and starts from a known state.
         However, building from scratch also takes much longer as it generally means
-        rebuilding things that don't necessarily need rebuilt.
+        rebuilding things that do not necessarily need rebuilt.
     </para>
 
     <para>
@@ -176,7 +180,7 @@
         <itemizedlist>
             <listitem>What pieces of the system have changed and what pieces have not changed?</listitem>
             <listitem>How are changed pieces of software removed and replaced?</listitem>
-            <listitem>How are pre-built components that don't need to be rebuilt from scratch
+            <listitem>How are pre-built components that do not need to be rebuilt from scratch
                 used when they are available?</listitem>
         </itemizedlist>
     </para>
@@ -197,7 +201,7 @@
     <note>
         The OpenEmbedded build system does not maintain
         <link linkend='var-PR'><filename>PR</filename></link> information
-        as part of the Shared State packages.
+        as part of the shared state packages.
         Consequently, considerations exist that affect maintaining shared
         state feeds.
         For information on how the OpenEmbedded works with packages and can
@@ -252,7 +256,7 @@
             the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
             It does not matter if the working directory changes because it should not
             affect the output for target packages.
-            Also, the build process has the objective of making native/cross packages relocatable.
+            Also, the build process has the objective of making native or cross packages relocatable.
             The checksum therefore needs to exclude <filename>WORKDIR</filename>.
             The simplistic approach for excluding the working directory is to set
             <filename>WORKDIR</filename> to some fixed value and create the checksum
@@ -271,9 +275,9 @@
 
         <para>
             So far we have solutions for shell scripts.
-            What about python tasks?
+            What about Python tasks?
             The same approach applies even though these tasks are more difficult.
-            The process needs to figure out what variables a python function accesses
+            The process needs to figure out what variables a Python function accesses
             and what functions it calls.
             Again, the incremental build solution contains code that first figures out
             the variable and function dependencies, and then creates a checksum for the data
@@ -303,7 +307,7 @@
         </para>
 
         <para>
-            Consider a case with inline python, for example, where BitBake is not
+            Consider a case with in-line Python, for example, where BitBake is not
             able to figure out dependencies.
             When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake
             produces output when it discovers something for which it cannot figure out
@@ -317,7 +321,8 @@
             Information based on direct inputs is referred to as the "basehash" in the
             code.
             However, there is still the question of a task's indirect inputs - the
-            things that were already built and present in the Build Directory.
+            things that were already built and present in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
             The checksum (or signature) for a particular task needs to add the hashes
             of all the tasks on which the particular task depends.
             Choosing which dependencies to add is a policy decision.
@@ -348,7 +353,7 @@
         <para>
             The rules for deciding which hashes of dependent tasks to include through
             dependency chains are more complex and are generally accomplished with a
-            python function.
+            Python function.
             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.
@@ -363,12 +368,12 @@
             </literallayout>
             The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
             "OEBasic" version but adds the task hash to the stamp files.
-            This results in any metadata change that changes the task hash, automatically
+            This results in any
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            change that changes the task hash, automatically
             causing the task to be run again.
             This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
-            values and changes to metadata automatically ripple across the build.
-            Currently, this behavior is not the default behavior for <filename>OE-Core</filename>
-            but is the default in <filename>poky</filename>.
+            values and changes to Metadata automatically ripple across the build.
         </para>
 
         <para>
@@ -399,7 +404,7 @@
             is a relatively generic implementation of how to "capture" a snapshot of a given task.
             The idea is that the build process does not care about the source of a task's output.
             Output could be freshly built or it could be downloaded and unpacked from
-            somewhere - the build process doesn't need to worry about its source.
+            somewhere - the build process does not need to worry about its source.
         </para>
 
         <para>
@@ -484,7 +489,7 @@
         </para>
 
         <para>
-            The build processes uses the <filename>*_setscene</filename> tasks
+            The build processes use the <filename>*_setscene</filename> tasks
             for the task acceleration phase.
             BitBake goes through this phase before the main execution code and tries
             to accelerate any tasks for which it can find shared state packages.
@@ -524,22 +529,22 @@
                 <itemizedlist>
                     <listitem><para>Whenever a shared state package is written out, so is a
                         corresponding <filename>.siginfo</filename> file.
-                        This practice results in a pickled python database of all
+                        This practice results in a pickled Python database of all
                         the metadata that went into creating the hash for a given shared state
                         package.</para></listitem>
-                    <listitem><para>If BitBake is run with the <filename>--dump-signatures</filename>
+                    <listitem><para>If you run BitBake with the <filename>--dump-signatures</filename>
                         (or <filename>-S</filename>) option, BitBake dumps out
                         <filename>.siginfo</filename> files in
                         the stamp directory for every task it would have executed instead of
                         building the specified target package.</para></listitem>
                     <listitem><para>There is a <filename>bitbake-diffsigs</filename> command that
-                        can process these <filename>.siginfo</filename> files.
-                        If one file is specified, it will dump out the dependency
+                        can process <filename>.siginfo</filename> files.
+                        If you specify one of these files, BitBake dumps out the dependency
                         information in the file.
-                        If two files are specified, it will compare the two files and dump out
+                        If you specify two files, BitBake compares the two files and dumps out
                         the differences between the two.
-                        This allows the question of "What changed between X and Y?" to be
-                        answered easily.</para></listitem>
+                        This more easily helps answer the question of "What
+                        changed between X and Y?"</para></listitem>
                 </itemizedlist>
             </para>
         </section>
@@ -554,12 +559,14 @@
                 It is possible that you could make implicit changes that are not factored
                 into the checksum calculation, but do affect a task's output.
                 A good example is perhaps when a tool changes its output.
-                Let's say that the output of <filename>rpmdeps</filename> needed to change.
-                The result of the change should be that all the "package", "package_write_rpm",
-                and "package_deploy-rpm" shared state cache items would become invalid.
+                Assume that the output of <filename>rpmdeps</filename> needed to change.
+                The result of the change should be that all the
+                <filename>package</filename>, <filename>package_write_rpm</filename>,
+                and <filename>package_deploy-rpm</filename> shared state cache
+                items would become invalid.
                 But, because this is a change that is external to the code and therefore implicit,
                 the associated shared state cache items do not become invalidated.
-                In this case, the build process would use the cached items rather than running the
+                In this case, the build process uses the cached items rather than running the
                 task again.
                 Obviously, these types of implicit changes can cause problems.
             </para>
@@ -571,9 +578,9 @@
                 the checksum calculation and thus, will invalidate the associated area of sstate cache.
                 You need to be aware of any implicit changes that are not obvious changes to the
                 code and could affect the output of a given task.
-                Once you are aware of such a change, you can take steps to invalidate the cache
-                and force the task to run.
-                The step to take is as simple as changing a function's comments in the source code.
+                Once you are aware of such changes, you can take steps to invalidate the cache
+                and force the tasks to run.
+                The steps to take are as simple as changing function's comments in the source code.
                 For example, to invalidate package shared state files, change the comment statements
                 of <filename>do_package</filename> or the comments of one of the functions it calls.
                 The change is purely cosmetic, but it causes the checksum to be recalculated and
@@ -593,7 +600,7 @@
     <title>x32</title>
 
     <para>
-        x32 is a new processor-specific Application Binary Interface (psABI) for x86_64.
+        x32 is a processor-specific Application Binary Interface (psABI) for x86_64.
         An ABI defines the calling conventions between functions in a processing environment.
         The interface determines what registers are used and what the sizes are for various C data types.
     </para>
@@ -623,10 +630,6 @@
             <itemizedlist>
                 <listitem><para>You can create packages and images in x32 psABI format on x86_64 architecture targets.
                     </para></listitem>
-                <listitem><para>You can use the x32 psABI support through the <filename>meta-x32</filename>
-                    layer on top of the OE-core/Yocto layer.</para></listitem>
-                <listitem><para>The toolchain from the <filename>experimental/meta-x32</filename> layer
-                    is used for building x32 psABI program binaries.</para></listitem>
                 <listitem><para>You can successfully build many recipes with the x32 toolchain.</para></listitem>
                 <listitem><para>You can create and boot <filename>core-image-minimal</filename> and
                     <filename>core-image-sato</filename> images.</para></listitem>
@@ -634,12 +637,12 @@
         </para>
     </section>
 
-    <section id='future-development-and-limitations'>
-        <title>Future Development and Limitations</title>
+    <section id='stabilizing-and-completing-x32'>
+        <title>Stabilizing and Completing x32</title>
 
         <para>
-            As of this Yocto Project release, the x32 psABI kernel and library interfaces
-            specifications are not finalized.
+            As of this Yocto Project release, the x32 psABI kernel and library
+            interfaces specifications are not finalized.
         </para>
 
         <para>
@@ -649,8 +652,6 @@
                     work with and support x32 toolchains.</para></listitem>
                 <listitem><para>Enhance RPM Package Manager (RPM) support for x32 binaries.</para></listitem>
                 <listitem><para>Support larger images.</para></listitem>
-                <listitem><para>Integrate x32 recipes, toolchain, and kernel changes from
-                    <filename>experimental/meta-x32</filename> into OE-core.</para></listitem>
             </itemizedlist>
         </para>
     </section>
@@ -659,28 +660,8 @@
         <title>Using x32 Right Now</title>
 
         <para>
-            Despite the fact the x32 psABI support is in development state for this release of the
-            Yocto Project, you can follow these steps to use the x32 spABI:
+            Follow these steps to use the x32 spABI:
             <itemizedlist>
-                <listitem><para>Add the <filename>experimental/meta-x32</filename> layer to your local
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-                    You can find the <filename>experimental/meta-x32</filename> source repository at
-                    <ulink url='&YOCTO_GIT_URL;'></ulink>.</para></listitem>
-                <listitem><para>Edit your <filename>conf/bblayers.conf</filename> file so that it includes
-                    the <filename>meta-x32</filename>.
-                    Here is an example:
-                    <literallayout class='monospaced'>
-     BBLAYERS ?= " \
-        /home/nitin/prj/poky.git/meta \
-        /home/nitin/prj/poky.git/meta-yocto \
-        /home/nitin/prj/poky.git/meta-yocto-bsp \
-        /home/nitin/prj/meta-x32.git \
-        "
-     BBLAYERS_NON_REMOVABLE ?= " \
-        /home/nitin/prj/poky.git/meta \
-        /home/nitin/prj/poky.git/meta-yocto \
-        "
-                    </literallayout></para></listitem>
                 <listitem><para>Enable the x32 psABI tuning file for <filename>x86_64</filename>
                     machines by editing the <filename>conf/local.conf</filename> like this:
                     <literallayout class='monospaced'>
@@ -694,7 +675,7 @@
                 <listitem><para>As usual, use BitBake to build an image that supports the x32 psABI.
                     Here is an example:
                     <literallayout class='monospaced'>
-     $ bitake core-image-sato
+     $ bitbake core-image-sato
                     </literallayout></para></listitem>
                 <listitem><para>As usual, run your image using QEMU:
                     <literallayout class='monospaced'>
@@ -705,6 +686,136 @@
     </section>
 </section>
 
+<section id="wayland">
+    <title>Wayland</title>
+
+    <para>
+        <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston'>Wayland</ulink>
+        is a computer display server protocol that when implemented
+        provides a method for compositing window managers to communicate
+        directly with applications and video hardware and expects them to
+        communicate with input hardware using other libraries.
+        Using Wayland with supporting targets can result in better control
+        over graphics frame rendering than an application might otherwise
+        achieve.
+    </para>
+
+    <para>
+        The Yocto Project provides the Wayland protocol libraries and the
+        reference Weston compositor as part of it release.
+        This section describes what you need to do to implement Wayland and
+        use the compositor when building an image for a supporting target.
+    </para>
+
+    <section id="wayland-support">
+        <title>Support</title>
+
+        <para>
+            The Wayland protocol libraries and the reference Weston compositor
+            ship as integrated packages in the <filename>meta</filename> layer
+            of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Specifically, you can find the recipes that build both Wayland
+            and Weston at <filename>meta/recipes-graphics/wayland</filename>.
+        </para>
+
+        <para>
+            You can build both the Wayland and Weston packages for use only
+            with targets that accept the
+            <ulink url='http://dri.freedesktop.org/wiki/'>Mesa 3D and Direct Rendering Infrastructure</ulink>,
+            which is also known as Mesa DRI.
+            This implies that you cannot build and use the packages if your
+            target uses, for example, the
+            <trademark class='registered'>Intel</trademark> Embedded Media and
+            Graphics Driver (<trademark class='registered'>Intel</trademark>
+            EMGD) that overrides Mesa DRI.
+        </para>
+
+        <note>
+            Due to lack of EGL support, Weston 1.0.3 will not run directly on
+            the emulated QEMU hardware.
+            However, this version of Weston will run under X emulation without
+            issues.
+        </note>
+    </section>
+
+    <section id="enabling-wayland-in-an-image">
+        <title>Enabling Wayland in an Image</title>
+
+        <para>
+            To enable Wayland, you need to enable it to be built and enable
+            it to be included in the image.
+        </para>
+
+        <section id="enable-building">
+            <title>Building</title>
+
+            <para>
+                To cause Mesa to build the <filename>wayland-egl</filename>
+                platform and Weston to build Wayland with Kernel Mode
+                Setting
+                (<ulink url='https://wiki.archlinux.org/index.php/Kernel_Mode_Setting'>KMS</ulink>)
+                support, include the "wayland" flag in the
+                <link linkend="var-DISTRO_FEATURES"><filename>DISTRO_FEATURES</filename></link>
+                statement in your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     DISTRO_FEATURES_append = " wayland"
+                </literallayout>
+            </para>
+
+            <note>
+                If X11 has been enabled elsewhere, Weston will build Wayland
+                with X11 support
+            </note>
+        </section>
+
+        <section id="enable-installation-in-an-image">
+            <title>Installing</title>
+
+            <para>
+                To install the Wayland feature into an image, you must
+                include the following
+                <link linkend='var-CORE_IMAGE_EXTRA_INSTALL'><filename>CORE_IMAGE_EXTRA_INSTALL</filename></link>
+                statement in your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
+                </literallayout>
+            </para>
+        </section>
+    </section>
+
+    <section id="running-weston">
+        <title>Running Weston</title>
+
+        <para>
+            To run Weston inside X11, enabling it as described earlier and
+            building a Sato image is sufficient.
+            If you are running your image under Sato, a Weston Launcher appears
+            in the "Utility" category.
+        </para>
+
+        <para>
+            Alternatively, you can run Weston through the command-line
+            interpretor (CLI), which is better suited for development work.
+            To run Weston under the CLI you need to do the following after
+            your image is built:
+            <orderedlist>
+                <listitem><para>Run these commands to export
+                    <filename>XDG_RUNTIME_DIR</filename>:
+                    <literallayout class='monospaced'>
+     mkdir -p /tmp/$USER-weston
+     chmod 0700 /tmp/$USER-weston
+     export XDG_RUNTIME_DIR=/tmp/$USER=weston
+                    </literallayout></para></listitem>
+                <listitem><para>Launch Weston in the shell:
+                    <literallayout class='monospaced'>
+     weston
+                    </literallayout></para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
 <section id="licenses">
     <title>Licenses</title>
 
@@ -773,7 +884,8 @@
                 of <filename><link linkend='var-S'>S</link></filename>.
             </para>
             <para>
-                Note that this variable is mandatory for all recipes, unless the
+                Note that <filename>LIC_FILES_CHKSUM</filename> variable is
+                mandatory for all recipes, unless the
                 <filename>LICENSE</filename> variable is set to "CLOSED".
             </para>
         </section>
@@ -894,82 +1006,104 @@
             <title>License Flag Matching</title>
 
             <para>
-		        The definition of 'matching' in reference to a
-		        recipe's <filename>LICENSE_FLAGS</filename> setting is simple.
-                However, some things exist that you should know about in order to
-                correctly and effectively use it.
+		        License flag matching allows you to control what recipes the
+                OpenEmbedded build system includes in the build.
+                Fundamentally, the build system attempts to match
+                <filename>LICENSE_FLAG</filename> strings found in
+                recipes against <filename>LICENSE_FLAGS_WHITELIST</filename>
+                strings found in the whitelist.
+                A match, causes the build system to include a recipe in the
+                build, while failure to find a match causes the build system to
+                exclude a recipe.
+            </para>
+
+            <para>
+                In general, license flag matching is simple.
+                However, understanding some concepts will help you
+                correctly and effectively use matching.
             </para>
 
             <para>
                 Before a flag
                 defined by a particular recipe is tested against the
-                contents of the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, the
-                string <filename>_${PN}</filename> (with
-                <link linkend='var-PN'><filename>PN</filename></link> expanded of course) is
-                appended to the flag, thus automatically making each
-                <filename>LICENSE_FLAGS</filename> value recipe-specific.
-                That string is
-                then matched against the whitelist.
-                So if you specify <filename>LICENSE_FLAGS = "commercial"</filename> in recipe
-		        "foo" for example, the string <filename>"commercial_foo"</filename>
-                would normally be what is specified in the whitelist in order for it to
-                match.
+                contents of the whitelist, the expanded string
+                <filename>_${PN}</filename> is appended to the flag.
+                This expansion makes each <filename>LICENSE_FLAGS</filename>
+                value recipe-specific.
+                After expansion, the string is then matched against the
+                whitelist.
+                Thus, specifying
+                <filename>LICENSE_FLAGS = "commercial"</filename>
+                in recipe "foo", for example, results in the string
+                <filename>"commercial_foo"</filename>.
+                And, to create a match, that string must appear in the
+                whitelist.
             </para>
 
             <para>
-                You can broaden the match by
-                putting any "_"-separated beginning subset of a
-                <filename>LICENSE_FLAGS</filename> flag in the whitelist, which will also
-                match.
-                For example, simply specifying "commercial" in
-                the whitelist would match any expanded <filename>LICENSE_FLAGS</filename>
-                definition starting with "commercial" such as
-                "commercial_foo" and "commercial_bar", which are the
-                strings that would be automatically generated for
-                hypothetical "foo" and "bar" recipes assuming those
-                recipes had simply specified the following:
+                Judicious use of the <filename>LICENSE_FLAGS</filename>
+                strings and the contents of the
+                <filename>LICENSE_FLAGS_WHITELIST</filename> variable
+                allows you a lot of flexibility for including or excluding
+                recipes based on licensing.
+                For example, you can broaden the matching capabilities by
+                using license flags string subsets in the whitelist.
+                <note>When using a string subset, be sure to use the part of
+                    the expanded string that precedes the appended underscore
+                    character (e.g. <filename>usethispart_1.3</filename>,
+                    <filename>usethispart_1.4</filename>, and so forth).
+                </note>
+                For example, simply specifying the string "commercial" in
+                the whitelist matches any expanded
+                <filename>LICENSE_FLAGS</filename> definition that starts with
+                the string "commercial" such as "commercial_foo" and
+                "commercial_bar", which are the strings the build system
+                automatically generates for hypothetical recipes named
+                "foo" and "bar" assuming those recipes simply specify the
+                following:
                 <literallayout class='monospaced'>
      LICENSE_FLAGS = "commercial"
                 </literallayout>
+                Thus, you can choose to exhaustively
+                enumerate each license flag in the whitelist and
+                allow only specific recipes into the image, or
+                you can use a string subset that causes a broader range of
+                matches to allow a range of recipes into the image.
             </para>
 
             <para>
-                Broadening the match allows for a range of specificity for the items
-                in the whitelist, from more general to perfectly
-                specific.
-                So you have the choice of exhaustively
-                enumerating each license flag in the whitelist to
-                allow only those specific recipes into the image, or
-                of using a more general string to pick up anything
-                matching just the first component or components of the specified
-                string.
+                This scheme works even if the
+                <filename>LICENSE_FLAG</filename> string already
+                has <filename>_${PN}</filename> appended.
+                For example, the build system turns the license flag
+                "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would
+                match both the general "commercial" and the specific
+                "commercial_1.2_foo" strings found in the whitelist, as
+                expected.
             </para>
 
             <para>
-                This scheme works even if the flag already
-                has <filename>_${PN}</filename> appended - the extra <filename>_${PN}</filename> is
-                redundant, but does not affect the outcome.
-                For example, a license flag of "commercial_1.2_foo" would
-                turn into "commercial_1.2_foo_foo" and would match
-                both the general "commercial" and the specific
-                "commercial_1.2_foo", as expected.
-                The flag would also match
-                "commercial_1.2_foo_foo" and "commercial_1.2", which
-                does not make much sense regarding use in the whitelist.
-            </para>
-
-            <para>
-                For a versioned string, you could instead specify
-                "commercial_foo_1.2", which would turn into
-                "commercial_foo_1.2_foo".
-                And, as expected, this flag allows
-                you to pick up this package along with
-                anything else "commercial" when you specify "commercial"
-                in the whitelist.
-                Or, the flag allows you to pick up this package along with anything "commercial_foo"
-                regardless of version when you use "commercial_foo" in the whitelist.
-                Finally, you can be completely specific about the package and version and specify
-                "commercial_foo_1.2" package and version.
+                Here are some other scenarios:
+                <itemizedlist>
+                    <listitem><para>You can specify a versioned string in the
+                        recipe such as "commercial_foo_1.2" in a "foo" recipe.
+                        The build system expands this string to
+                        "commercial_foo_1.2_foo".
+                        Combine this license flag with a whitelist that has
+                        the string "commercial" and you match the flag along
+                        with any other flag that starts with the string
+                        "commercial".</para></listitem>
+                    <listitem><para>Under the same circumstances, you can
+                        use "commercial_foo" in the whitelist and the
+                        build system not only matches "commercial_foo_1.2" but
+                        also matches any license flag with the string
+                        "commercial_foo", regardless of the version.
+                        </para></listitem>
+                    <listitem><para>You can be very specific and use both the
+                        package and version parts in the whitelist (e.g.
+                        "commercial_foo_1.2") to specifically match a
+                        versioned recipe.</para></listitem>
+                </itemizedlist>
             </para>
         </section>
 
@@ -986,7 +1120,8 @@
      COMMERCIAL_QT = ""
                 </literallayout>
                 If you want to enable these components, you can do so by making sure you have
-                the following statements in your <filename>local.conf</filename> configuration file:
+                statements similar to the following
+                in your <filename>local.conf</filename> configuration file:
                 <literallayout class='monospaced'>
      COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
         gst-plugins-ugly-mpegaudioparse"
@@ -1009,7 +1144,7 @@
                 Specifying audio and video plug-ins as part of the
                 <filename>COMMERCIAL_AUDIO_PLUGINS</filename> and
                 <filename>COMMERCIAL_VIDEO_PLUGINS</filename> statements
-                or commercial qt components as part of
+                or commercial Qt components as part of
                 the <filename>COMMERCIAL_QT</filename> statement (along
                 with the enabling <filename>LICENSE_FLAGS_WHITELIST</filename>) includes the
                 plug-ins or components into built images, thus adding

documentation/ref-manual/usingpoky.xml

@@ -30,7 +30,7 @@
             The first thing you need to do is set up the OpenEmbedded build environment by sourcing
             the <link linkend='structure-core-script'>environment setup script</link> as follows:
             <literallayout class='monospaced'>
-     $ source &OE_INIT_FILE; [build_dir]
+     $ source &OE_INIT_FILE; [&lt;build_dir&gt;]
             </literallayout>
         </para>
 
@@ -38,13 +38,13 @@
             The <filename>build_dir</filename> is optional and specifies the directory the
             OpenEmbedded build system uses for the build -
             the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-            If you do not specify a Build Directory it defaults to <filename>build</filename>
+            If you do not specify a Build Directory, it defaults to <filename>build</filename>
             in your current working directory.
             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.
-            See <link linkend="structure-core-script">&OE_INIT_FILE;</link>
-            for more information on this script.
+            See the "<link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>"
+            section for more information on this script.
         </para>
 
         <para>
@@ -60,7 +60,7 @@
             <filename>/meta/recipes-sato/images</filename>, etc. all found in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             Or, the target can be the name of a recipe for a specific piece of software such as
-            <application>busybox</application>.
+            BusyBox.
             For more details about the images the OpenEmbedded build system supports, see the
             "<link linkend="ref-images">Images</link>" chapter.
         </para>
@@ -98,7 +98,7 @@
         "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
         section in the Yocto Project Quick Start.
         For information about how to install these images, see the documentation for your
-        particular board/machine.
+        particular board or machine.
     </para>
 </section>
 
@@ -116,6 +116,14 @@
         this section provides some general tips to aid in debugging.
     </para>
 
+    <para>
+        For discussions on debugging, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
+        and
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working within Eclipse</ulink>"
+        sections in the Yocto Project Development Manual.
+    </para>
+
     <section id='usingpoky-debugging-taskfailures'>
         <title>Task Failures</title>
 
@@ -148,7 +156,8 @@
             Some tasks exist, such as <filename>devshell</filename>, that are not part of the
             default build chain.
             If you wish to run a task that is not part of the default build chain, you can use the
-            <filename>-c</filename> option in BitBake as follows:
+            <filename>-c</filename> option in BitBake.
+            Here is an example:
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop -c devshell
             </literallayout>
@@ -171,7 +180,8 @@
         </para>
 
         <para>
-            This sequence first builds <filename>matchbox-desktop</filename> and then recompiles it.
+            This sequence first builds and then recompiles
+            <filename>matchbox-desktop</filename>.
             The last command reruns all tasks (basically the packaging tasks) after the compile.
             BitBake recognizes that the <filename>compile</filename> task was rerun and therefore
             understands that the other tasks also need to be run again.
@@ -230,7 +240,7 @@
             build to fail.
             Following are known, host-specific problems.
             Be sure to always consult the
-            <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-&DISTRO;-release-notes-poky-&POKYVERSION;'>Release Notes</ulink>
+            <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>
             for a look at all release-related issues.
             <itemizedlist>
                 <listitem><para><emphasis><filename>eglibc-initial</filename> fails to build</emphasis>:
@@ -239,7 +249,7 @@
                     the <filename>do_install</filename> task
                     fails for <filename>eglibc-initial</filename> during the
                     build.</para>
-                    <para>Typically, every distrobution that ships
+                    <para>Typically, every distribution that ships
                     <filename>GNU Make 3.82</filename> as
                     the default already has the patched version.
                     However, some distributions, such as Debian, have
@@ -268,10 +278,12 @@
     <section id='usingpoky-debugging-variables'>
         <title>Variables</title>
         <para>
-            The <filename>-e</filename> option dumps the resulting environment for
-            either the configuration (no package specified) or for a
-            specific package when specified; or <filename>-b recipename</filename>
-            to show the environment from parsing a single recipe file only.
+            You can use the <filename>-e</filename> BitBake option to
+            display the resulting environment for a configuration
+            when you do not specify a package or for a specific package when
+            you do specify the package.
+            If you want to show the environment resulting from parsing a single
+            recipe, use the <filename>-b recipename</filename> form.
         </para>
     </section>
 
@@ -305,10 +317,10 @@
         <section id='logging-with-python'>
             <title>Logging With Python</title>
             <para>
-                When creating recipes using Python and inserting code that handles build logs
+                When creating recipes using Python and inserting code that handles build logs,
                 keep in mind the goal is to have informative logs while keeping the console as
                 "silent" as possible.
-                Also, if you want status messages in the log use the "debug" loglevel.
+                Also, if you want status messages in the log, use the "debug" loglevel.
             </para>
 
             <para>
@@ -338,7 +350,7 @@
             <title>Logging With Bash</title>
             <para>
                 When creating recipes using Bash and inserting code that handles build
-                logs you have the same goals - informative with minimal console output.
+                logs, you have the same goals - informative with minimal console output.
                 The syntax you use for recipes written in Bash is similar to that of
                 recipes written in Python described in the previous section.
             </para>
@@ -380,9 +392,11 @@
                     For example, you do not want references to local system files like
                     <filename>/usr/lib/</filename> or <filename>/usr/include/</filename>.
                     </para></listitem>
-                <listitem><para>If you want to remove the psplash boot splashscreen,
+                <listitem><para>If you want to remove the <filename>psplash</filename>
+                    boot splashscreen,
                     add <filename>psplash=false</filename> to  the kernel command line.
-                    Doing so prevents psplash from loading and thus allows you to see the console.
+                    Doing so prevents <filename>psplash</filename> from loading
+                    and thus allows you to see the console.
                     It is also possible to switch out of the splashscreen by
                     switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
                     </para></listitem>
@@ -395,7 +409,7 @@
     <title>Maintaining Build Output Quality</title>
 
     <para>
-        A build's quality can be influenced by many things.
+        Many factors can influence the quality of a build.
         For example, if you upgrade a recipe to use a new version of an upstream software
         package or you experiment with some new configuration options, subtle changes
         can occur that you might not detect until later.
@@ -403,7 +417,7 @@
         In this case, a new version of a piece of software might introduce an optional
         dependency on another library, which is auto-detected.
         If that library has already been built when the software is building,
-        then the software will link to the built library and that library will be pulled
+        the software will link to the built library and that library will be pulled
         into your image along with the new software even if you did not want the
         library.
     </para>
@@ -413,7 +427,7 @@
         the quality of your build output.
         You can use the class to highlight unexpected and possibly unwanted
         changes in the build output.
-        When you enable build history it records information about the contents of
+        When you enable build history, it records information about the contents of
         each package and image and then commits that information to a local Git
         repository where you can examine the information.
     </para>
@@ -464,13 +478,13 @@
             are using the OEBasicHash signature generator (the default
             for many current distro configurations including
             <filename>DISTRO = "poky"</filename> and
-            <filename>DISTRO = ""</filename>) will result in the packaging
+            <filename>DISTRO = ""</filename>) and will result in the packaging
             tasks being re-run during the subsequent build.
         </para>
 
         <para>
             To disable the build history functionality without causing the
-            packaging tasks to be re-run, add just this statement to your
+            packaging tasks to be re-run, add this statement to your
             <filename>conf/local.conf</filename> file:
             <literallayout class='monospaced'>
      BUILDHISTORY_FEATURES = ""
@@ -483,12 +497,21 @@
 
         <para>
             Build history information is kept in
-            <link linkend='var-TMPDIR'><filename>$TMPDIR</filename></link><filename>/buildhistory</filename>
+            <filename>$</filename><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>/buildhistory</filename>
             in the Build Directory.
             The following is an example abbreviated listing:
             <imagedata fileref="figures/buildhistory.png" align="center" width="6in" depth="4in" />
         </para>
 
+        <para>At the top level, there is a <filename>metadata-revs</filename> file
+            that lists the revisions of the repositories for the layers enabled
+            when the build was produced.
+            The rest of the data splits into separate
+            <filename>packages</filename>, <filename>images</filename> and
+            <filename>sdk</filename> directories, the contents of which are
+            described below.
+        </para>
+
         <section id='build-history-package-information'>
             <title>Build History Package Information</title>
 
@@ -509,7 +532,7 @@
         /usr/share/idl /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers
      FILELIST = /etc/busybox.links /etc/init.d/hwclock.sh /bin/busybox /bin/sh
                 </literallayout>
-                Most of these name-value pairs corresponds to variables used
+                Most of these name-value pairs correspond to variables used
                 to produce the package.
                 The exceptions are <filename>FILELIST</filename>, which is the
                 actual list of files in the package, and
@@ -531,6 +554,71 @@
         busybox-staticdev busybox-locale
                 </literallayout>
             </para>
+
+            <para>
+                Finally, for those recipes fetched from a version control
+                system (e.g., Git), a file exists that lists source revisions
+                that are specified in the recipe and lists the actual revisions
+                used during the build.
+                Listed and actual revisions might differ when
+                <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
+                is set to
+                <filename>${<link linkend='var-AUTOREV'>AUTOREV</link>}</filename>.
+                Here is an example assuming
+                <filename>buildhistory/packages/emenlow-poky-linux/linux-yocto/latest_srcrev</filename>):
+                <literallayout class='monospaced'>
+     # SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
+     SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
+     # SRCREV_emgd = "caea08c988e0f41103bbe18eafca20348f95da02"
+     SRCREV_emgd = "caea08c988e0f41103bbe18eafca20348f95da02"
+     # SRCREV_meta = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+     SRCREV_meta = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+                </literallayout>
+                You can use the <filename>buildhistory-collect-srcrevs</filename>
+                command to collect the stored <filename>SRCREV</filename> values
+                from build history and report them in a format suitable for use in
+                global configuration (e.g., <filename>local.conf</filename>
+                or a distro include file) to override floating
+                <filename>AUTOREV</filename> values to a fixed set of revisions.
+                Here is some example output from this command:
+                <literallayout class='monospaced'>
+     # emenlow-poky-linux
+     SRCREV_machine_pn-linux-yocto = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
+     SRCREV_emgd_pn-linux-yocto = "caea08c988e0f41103bbe18eafca20348f95da02"
+     SRCREV_meta_pn-linux-yocto = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+     # core2-poky-linux
+     SRCREV_pn-kmod = "62081c0f68905b22f375156d4532fd37fa5c8d33"
+     SRCREV_pn-blktrace = "d6918c8832793b4205ed3bfede78c2f915c23385"
+     SRCREV_pn-opkg = "649"
+                </literallayout>
+                <note>
+                    Here are some notes on using the
+                    <filename>buildhistory-collect-srcrevs</filename> command:
+                    <itemizedlist>
+                        <listitem><para>By default, only values where the
+                            <filename>SRCREV</filename> was
+                            not hardcoded (usually when <filename>AUTOREV</filename>
+                            was used) are reported.
+                            Use the <filename>-a</filename> option to see all
+                            <filename>SRCREV</filename> values.
+                            </para></listitem>
+                        <listitem><para>The output statements might not have any effect
+                            if overrides are applied elsewhere in the build system
+                            configuration.
+                            Use the <filename>-f</filename> option to add the
+                            <filename>forcevariable</filename> override to each output line
+                            if you need to work around this restriction.
+                            </para></listitem>
+                        <listitem><para>The script does apply special handling when
+                            building for multiple machines.
+                            However, the script does place a
+                            comment before each set of values that specifies
+                            which triplet to which they belong as shown above
+                            (e.g., <filename>emenlow-poky-linux</filename>).
+                            </para></listitem>
+                    </itemizedlist>
+                </note>
+            </para>
         </section>
 
         <section id='build-history-image-information'>
@@ -539,29 +627,29 @@
             <para>
                 The files produced for each image are as follows:
                 <itemizedlist>
-                    <listitem><para><emphasis>build-id:</emphasis>
+                    <listitem><para><filename>build-id:</filename>
                         Human-readable information about the build configuration
                         and metadata source revisions.</para></listitem>
-                    <listitem><para><emphasis>*.dot:</emphasis>
+                    <listitem><para><filename>*.dot:</filename>
                         Dependency graphs for the image that are
                         compatible with <filename>graphviz</filename>.
                         </para></listitem>
-                    <listitem><para><emphasis>files-in-image.txt:</emphasis>
+                    <listitem><para><filename>files-in-image.txt:</filename>
  	                    A list of files in the image with permissions,
                         owner, group, size, and symlink information.
                         </para></listitem>
-                    <listitem><para><emphasis>image-info.txt:</emphasis>
+                    <listitem><para><filename>image-info.txt:</filename>
                         A text file containing name-value pairs with information
                         about the image.
                         See the following listing example for more information.
                         </para></listitem>
-                    <listitem><para><emphasis>installed-package-names.txt:</emphasis>
+                    <listitem><para><filename>installed-package-names.txt:</filename>
                         A list of installed packages by name only.</para></listitem>
-                    <listitem><para><emphasis>installed-package-sizes.txt:</emphasis>
+                    <listitem><para><filename>installed-package-sizes.txt:</filename>
                         A list of installed packages ordered by size.
                         </para></listitem>
-                    <listitem><para><emphasis>installed-packages.txt:</emphasis>
-                        A list of installed packages with fuill package
+                    <listitem><para><filename>installed-packages.txt:</filename>
+                        A list of installed packages with full package
                         filenames.</para></listitem>
                 </itemizedlist>
                 <note>
@@ -617,6 +705,72 @@
             </para>
         </section>
 
+        <section id='build-history-sdk-information'>
+            <title>Build History SDK Information</title>
+            <para>
+                Build history collects similar information on the contents
+                of SDKs (e.g., <filename>meta-toolchain</filename>
+                or <filename>bitbake -c populate_sdk imagename</filename>)
+                as compared to information it collects for images.
+                The following list shows the files produced for each SDK:
+                <itemizedlist>
+                    <listitem><para><filename>files-in-sdk.txt:</filename>
+                        A list of files in the SDK with permissions,
+                        owner, group, size, and symlink information.
+                        This list includes both the host and target parts
+                        of the SDK.
+                        </para></listitem>
+                    <listitem><para><filename>sdk-info.txt:</filename>
+                        A text file containing name-value pairs with information
+                        about the SDK.
+                        See the following listing example for more information.
+                        </para></listitem>
+                    <listitem><para>The following information appears under
+                        each of the <filename>host</filename>
+                        and <filename>target</filename> directories
+                        for the portions of the SDK that run on the host and
+                        on the target, respectively:
+                        <itemizedlist>
+                            <listitem><para><filename>depends.dot:</filename>
+                                Dependency graph for the SDK that is
+                                compatible with <filename>graphviz</filename>.
+                                </para></listitem>
+                            <listitem><para><filename>installed-package-names.txt:</filename>
+                                A list of installed packages by name only.
+                                </para></listitem>
+                            <listitem><para><filename>installed-package-sizes.txt:</filename>
+                                A list of installed packages ordered by size.
+                                </para></listitem>
+                            <listitem><para><filename>installed-packages.txt:</filename>
+                                A list of installed packages with full package
+                                filenames.</para></listitem>
+                            </itemizedlist>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Here is an example of <filename>sdk-info.txt</filename>:
+                <literallayout class='monospaced'>
+     DISTRO = poky
+     DISTRO_VERSION = 1.3+snapshot-20130327
+     SDK_NAME = poky-eglibc-i686-arm
+     SDK_VERSION = 1.3+snapshot
+     SDKMACHINE =
+     SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
+     BAD_RECOMMENDATIONS =
+     SDKSIZE = 352712
+                </literallayout>
+                Other than <filename>SDKSIZE</filename>, which is the
+                total size of the files in the SDK in Kbytes, the
+                name-value pairs are variables that might have influenced the
+                content of the SDK.
+                This information is often useful when you are trying to
+                determine why a change in the package or file listings
+                has occurred.
+            </para>
+        </section>
+
         <section id='examining-build-history-information'>
             <title>Examining Build History Information</title>
 
@@ -641,7 +795,7 @@
 
             <para>
                 A command-line tool called <filename>buildhistory-diff</filename>
-                does exist though that queries the Git repository and prints just
+                does exist, though, that queries the Git repository and prints just
                 the differences that might be significant in human-readable form.
                 Here is an example:
                 <literallayout class='monospaced'>

documentation/tools/mega-manual.sed

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

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

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

meta-hob/conf/layer.conf

@@ -1,7 +1,7 @@
 # We have a conf and classes directory, add to BBPATH
 BBPATH .= ":${LAYERDIR}"
 
-# We have a packages directory, add to BBFILES
+# We have recipes-* directories, add to BBFILES
 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb"
 
 BBFILE_COLLECTIONS += "hob"

meta-skeleton/conf/layer.conf

@@ -1,7 +1,7 @@
 # We have a conf and classes directory, add to BBPATH
 BBPATH .= ":${LAYERDIR}"
 
-# We have a packages directory, add to BBFILES
+# We have recipes-* directories, add to BBFILES
 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb"
 
 BBFILE_COLLECTIONS += "skeleton"

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

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

meta-yocto-bsp/conf/layer.conf

@@ -1,7 +1,7 @@
 # We have a conf and classes directory, add to BBPATH
 BBPATH .= ":${LAYERDIR}"
 
-# We have a packages directory, add to BBFILES
+# We have recipes-* directories, add to BBFILES
 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
             ${LAYERDIR}/recipes-*/*/*.bbappend"
 

meta-yocto-bsp/conf/machine/atom-pc.conf

@@ -19,7 +19,8 @@ XSERVER ?= "xserver-xorg \
            xf86-input-evdev \
            xf86-input-synaptics \
            xf86-video-intel \
-           mesa-driver-i915"
+           mesa-driver-i915 \
+           mesa-driver-i965"
 
 #MACHINE_EXTRA_RDEPENDS = "rt2860"
 

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

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

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

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

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

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

meta-yocto/classes/poky-sanity.bbclass

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

meta-yocto/conf/distro/include/package_regex.inc

@@ -60,10 +60,20 @@ REGEX_pn-flac = "[hH][rR][eE][fF]=\"/projects/flac/files/flac-linux-i386/flac\-(
 REGEX_URI_pn-flex = "http://sourceforge.net/projects/flex/files/"
 REGEX_pn-flex = "[hH][rR][eE][fF]=\"http://sourceforge.net/projects/flex/files/flex-(?P<pver>((\d+[\.\-_]*)+)).tar.gz/download\""
 REGEX_pn-foomatic-filters = "[hH][rR][eE][fF]=\"foomatic-filters-(?P<pver>((\d|\d\d)\.*)+)\.tar\.gz\""
+REGEX_URI_pn-fotowall = "https://code.google.com/p/fotowall/downloads/list"
+REGEX_pn-fotowall = "[hH][rR][eE][fF]=\"//fotowall.googlecode.com/files/[F|f]otowall\-(?P<pver>((\d+[\.\-_]*)+))\.tar\.bz2\""
 REGEX_URI_pn-freetype = "http://sourceforge.net/projects/freetype/files/freetype2"
 REGEX_pn-freetype = "[hH][rR][eE][fF]=\"/projects/freetype/files/freetype\d/(?P<pver>((\d+[\.\-_]*)+))/\""
 REGEX_URI_pn-freetype-native = "http://sourceforge.net/projects/freetype/files/freetype2"
 REGEX_pn-freetype-native = "[hH][rR][eE][fF]=\"/projects/freetype/files/freetype\d/(?P<pver>((\d+[\.\-_]*)+))/\""
+REGEX_URI_pn-gcc-cross-canadian-i586 = "ftp://ftp.gnu.org/gnu/gcc/"
+REGEX_pn-gcc-cross-canadian-i586 = "[hH][rR][eE][fF]=\"ftp://ftp.gnu.org:21/gnu/gcc/gcc\-(?P<pver>((\d+[\.\-_]*)+))/\""
+REGEX_URI_pn-gcc-cross-initial = "ftp://ftp.gnu.org/gnu/gcc/"
+REGEX_pn-gcc-cross-initial = "[hH][rR][eE][fF]=\"ftp://ftp.gnu.org:21/gnu/gcc/gcc\-(?P<pver>((\d+[\.\-_]*)+))/\""
+REGEX_URI_pn-gcc-runtime = "ftp://ftp.gnu.org/gnu/gcc/"
+REGEX_pn-gcc-runtime = "[hH][rR][eE][fF]=\"ftp://ftp.gnu.org:21/gnu/gcc/gcc\-(?P<pver>((\d+[\.\-_]*)+))/\""
+REGEX_URI_pn-gcc-crosssdk = "ftp://ftp.gnu.org/gnu/gcc/"
+REGEX_pn-gcc-crosssdk = "[hH][rR][eE][fF]=\"ftp://ftp.gnu.org:21/gnu/gcc/gcc\-(?P<pver>((\d+[\.\-_]*)+))/\""
 REGEX_URI_pn-glew = "http://sourceforge.net/projects/glew/files/glew"
 REGEX_pn-glew  = " [hH][rR][eE][fF]=\"/projects/glew/files/glew/(?P<pver>((\d+[\.\-_]*)+))/\""
 REGEX_URI_pn-hdparm = "http://sourceforge.net/projects/hdparm/files/hdparm/"
@@ -84,13 +94,18 @@ REGEX_URI_pn-less  = "http://www.greenwoodsoftware.com/less/download.html"
 REGEX_pn-less = "[hH][rR][eE][fF]=\"less\-(?P<pver>(\d+))\.tar\.gz\""
 REGEX_URI_pn-liba52 = "http://liba52.sourceforge.net/downloads.html"
 REGEX_pn-liba52 = "[hH][rR][eE][fF]=\"/files/a52\w*\-(?P<pver>((\d+[a-z]?[\.\-_]*)+))\.tar\.gz\""
+REGEX_URI_pn-libacpi = "http://www.ngolde.de/libacpi.html"
 REGEX_URI_pn-libaio = "http://ftp.debian.org/debian/pool/main/liba/libaio/"
 REGEX_pn-libaio = "[hH][rR][eE][fF]=\"libaio_(?P<pver>((\d+[\.\-_]*)+)).orig.tar.gz\""
+REGEX_URI_pn-libarchive = "http://www.libarchive.org/"
+REGEX_pn-libarchive = "[hH][rR][eE][fF]=\"downloads/libarchive\-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz\""
 REGEX_URI_pn-libcgroup = "http://sourceforge.net/projects/libcg/files/libcgroup/"
 #REGEX_pn-libcgroup = "[hH][rR][eE][fF]=\"/projects/libcg/files/libcgroup/v?(?P<pver>((\.?\d+[\.\-_]*)+(rc\d?)*)+)/\""
 REGEX_pn-libcgroup = "[hH][rR][eE][fF]=\"/projects/libcg/files/libcgroup/v?(?P<pver>((\.?\d+[\.\-_]*))+)/\""
 REGEX_URI_pn-libcheck = "http://sourceforge.net/projects/check/files/check/"
 REGEX_pn-libcheck = "[hH][rR][eE][fF]=\"/projects/check/files/check/(?P<pver>((\d+[\.\-_]*)+))/\""
+REGEX_URI_pn-libgcc = "ftp://ftp.gnu.org/gnu/gcc/"
+REGEX_pn-libgcc = "[hH][rR][eE][fF]=\"ftp://ftp.gnu.org:21/gnu/gcc/gcc\-(?P<pver>((\d+[\.\-_]*)+))/\""
 #REGEX_URI_pn-libevent = "http://sourceforge.net/projects/levent/files/libevent/libevent-2.0/"
 REGEX_URI_pn-libevent = "http://libevent.org/"
 #REGEX_pn-libevent = "[hH][rR][eE][fF]=\"http://sourceforge.net/projects/levent/files/libevent/libevent-2.0/libevent-(?P<pver>((\d+[\.\-_]*)+))\-stable\.tar\.gz/download\""
@@ -105,6 +120,7 @@ REGEX_URI_pn-libmad = "http://sourceforge.net/projects/mad/files/libmad/"
 REGEX_pn-libmad = "[hH][rR][eE][fF]=\"/projects/mad/files/libmad/(?P<pver>((\d+[\.\-_]*)+([a-z]?)))/\""
 REGEX_URI_pn-libogg = "http://downloads.xiph.org/releases/ogg/"
 REGEX_pn-libogg = "[hH][rR][eE][fF]=\"libogg\-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz\""
+REGEX_URI_pn-libmpc = "http://www.multiprecision.org/index.php?prog=mpc&page=download"
 REGEX_URI_pn-libomxil = "http://sourceforge.net/projects/omxil/files/omxil/"
 REGEX_pn-libomxil = "[hH][rR][eE][fF]=\"/projects/omxil/files/omxil/Bellagio.20(?P<pver>((\d+[\.\-_]*)+))/\""
 REGEX_URI_pn-libpcap = "http://www.tcpdump.org/release/"
@@ -128,6 +144,7 @@ REGEX_URI_pn-libusb1 = "http://sourceforge.net/projects/libusb/files/libusb-1.0/
 REGEX_pn-libusb1 = "[hH][rR][eE][fF]=\"/projects/libusb/files/libusb-1.0/libusb-(?P<pver>((\d+[\.\-_]*)+))/""
 REGEX_URI_pn-libvorbis = "http://downloads.xiph.org/releases/vorbis/"
 REGEX_pn-libvorbis = "[hH][rR][eE][fF]=\"libvorbis-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz\""
+REGEX_URI_pn-lrzsz = "http://ohse.de/uwe/software/lrzsz.html"
 REGEX_URI_pn-lsb = "http://sourceforge.net/projects/lsb/files/lsb_release/"
 REGEX_pn-lsb = "[hH][rR][eE][fF]=\"/projects/lsb/files/lsb_release/(?P<pver>((\d+[\.\-_]*)+))/\""
 REGEX_URI_pn-ltp = "http://sourceforge.net/projects/ltp/files/LTP%20Source"
@@ -136,6 +153,8 @@ REGEX_URI_pn-mailx = "http://sourceforge.net/projects/heirloom/files/heirloom-ma
 REGEX_pn-mailx = "[hH][rR][eE][fF]=\"/projects/heirloom/files/heirloom-mailx/(?P<pver>((\d+[\.]*)+))/\""
 REGEX_URI_pn-menu-cache = "http://sourceforge.net/projects/lxde/files/menu-cache/"
 REGEX_pn-menu-cache = "[hH][rR][eE][fF]=\"/projects/lxde/files/menu\-cache/menu-cache%20(?P<pver>((\d+[\.\-_]*)+))/\""
+REGEX_URI_pn-mesa-demos = "ftp://ftp.freedesktop.org/pub/mesa/demos/"
+REGEX_pn-mesa-demos = "[hH][rR][eE][fF]=\"ftp://ftp.freedesktop.org:21/pub/mesa/demos/(?P<pver>((\d+[\.\-_]*)+))/\""
 REGEX_URI_pn-minicom = "https://alioth.debian.org/frs/?group_id=30018"
 REGEX_pn-minicom = "[hH][rR][eE][fF]=\"/frs/download.php/\d+/minicom\-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz\""
 REGEX_URI_pn-mingetty = "http://sourceforge.net/projects/mingetty/files/mingetty"
@@ -164,8 +183,10 @@ REGEX_URI_pn-pcmanfm = "http://sourceforge.net/projects/pcmanfm/files/PCManFM%20
 REGEX_pn-pcmanfm = "[hH][rR][eE][fF]=\"http://sourceforge.net/projects/pcmanfm/files/PCManFM.20.2B.20Libfm.20.28tarball.20release.29/PCManFM/pcmanfm-(?P<pver>((\d+[\.\-_]*)+)).tar.gz/download\""
 REGEX_URI_pn-procps = "http://procps.sourceforge.net/download.html"
 REGEX_pn-procps = "[hH][rR][eE][fF]=\"procps\-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz\""
+REGEX_URI_pn-powertop = "https://01.org/powertop/downloads"
 REGEX_URI_pn-psmisc = "http://sourceforge.net/projects/psmisc/files/psmisc/"
 REGEX_pn-psmisc = "[hH][rR][eE][fF]=\"http://sourceforge.net/projects/psmisc/files/psmisc/psmisc\-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz/download\""
+REGEX_URI_pn-python-argparse = "https://code.google.com/p/argparse/downloads/list"
 REGEX_URI_pn-python-pycurl = "http://pycurl.sourceforge.net/download/"
 REGEX_pn-python-pycurl = "[hH][rR][eE][fF]=\"pycurl-(?P<pver>((\d+[\.\-_]*)+)).tar.gz\""
 REGEX_URI_pn-python-scons = "http://sourceforge.net/projects/scons/files/scons/"

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

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

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

@@ -37,7 +37,7 @@ DISTRO = "poky-tiny"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny = "3.4%"
+PREFERRED_VERSION_linux-yocto-tiny = "3.8%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"

meta-yocto/conf/distro/poky.conf

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

meta-yocto/conf/layer.conf

@@ -1,7 +1,7 @@
 # We have a conf and classes directory, add to BBPATH
 BBPATH =. "${LAYERDIR}:"
 
-# We have a packages directory, add to BBFILES
+# We have recipes-* directories, add to BBFILES
 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
             ${LAYERDIR}/recipes-*/*/*.bbappend"
 

meta-yocto/conf/local.conf.sample

@@ -139,6 +139,8 @@ PACKAGE_CLASSES ?= "package_rpm"
 #                     (adds symbol information for debugging/profiling)
 #  "dev-pkgs"       - add -dev packages for all installed packages
 #                     (useful if you want to develop against libs in the image)
+#  "ptest-pkgs"     - add -ptest packages for all ptest-enabled packages
+#                     (useful if you want to run the package test suites)
 #  "tools-sdk"      - add development tools (gcc, make, pkgconfig etc.)
 #  "tools-debug"    - add debugging tools (gdb, strace)
 #  "eclipse-debug"  - add Eclipse remote debugging support

meta/classes/archive-configured-source.bbclass

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

meta/classes/archive-original-source.bbclass

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

meta/classes/archive-patched-source.bbclass

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

meta/classes/archiver.bbclass

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

meta/classes/autotools.bbclass

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

meta/classes/base.bbclass

@@ -308,13 +308,15 @@ python base_eventhandler() {
         oe.utils.features_backfill("MACHINE_FEATURES", e.data)
 
     if isinstance(e, bb.event.BuildStarted):
+        localdata = bb.data.createCopy(e.data)
+        bb.data.update_data(localdata)
         statuslines = []
-        for func in oe.data.typed_value('BUILDCFG_FUNCS', e.data):
+        for func in oe.data.typed_value('BUILDCFG_FUNCS', localdata):
             g = globals()
             if func not in g:
                 bb.warn("Build configuration function '%s' does not exist" % func)
             else:
-                flines = g[func](e.data)
+                flines = g[func](localdata)
                 if flines:
                     statuslines.extend(flines)
 
@@ -515,11 +517,12 @@ python () {
         need_machine = d.getVar('COMPATIBLE_MACHINE', True)
         if need_machine:
             import re
-            this_machine = d.getVar('MACHINE', True)
-            if this_machine and not re.match(need_machine, this_machine):
-                this_soc_family = d.getVar('SOC_FAMILY', True)
-                if (this_soc_family and not re.match(need_machine, this_soc_family)) or not this_soc_family:
-                    raise bb.parse.SkipPackage("incompatible with machine %s (not in COMPATIBLE_MACHINE)" % this_machine)
+            compat_machines = (d.getVar('MACHINEOVERRIDES', True) or "").split(":")
+            for m in compat_machines:
+                if re.match(need_machine, m):
+                    break
+            else:
+                raise bb.parse.SkipPackage("incompatible with machine %s (not in COMPATIBLE_MACHINE)" % d.getVar('MACHINE', True))
 
 
         bad_licenses = (d.getVar('INCOMPATIBLE_LICENSE', True) or "").split()

meta/classes/bootimg.bbclass

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

meta/classes/buildhistory.bbclass

@@ -500,7 +500,7 @@ END
 		repostatus=`git status --porcelain | grep -v " metadata-revs$"`
 		HOSTNAME=`hostname 2>/dev/null || echo unknown`
 		if [ "$repostatus" != "" ] ; then
-			git add .
+			git add -A .
 			# porcelain output looks like "?? packages/foo/bar"
 			# Ensure we commit metadata-revs with the first commit
 			for entry in `echo "$repostatus" | awk '{print $2}' | awk -F/ '{print $1}' | sort | uniq` ; do
@@ -538,24 +538,39 @@ def _get_srcrev_values(d):
             scms.append(u)
 
     autoinc_templ = 'AUTOINC+'
-    dict = {}
+    dict_srcrevs = {}
+    dict_tag_srcrevs = {}
     for scm in scms:
         ud = urldata[scm]
         for name in ud.names:
             rev = ud.method.sortable_revision(scm, ud, d, name)
             if rev.startswith(autoinc_templ):
                 rev = rev[len(autoinc_templ):]
-            dict[name] = rev
-    return dict
+            dict_srcrevs[name] = rev
+            if 'tag' in ud.parm:
+                tag = ud.parm['tag'];
+                key = name+'_'+tag
+                dict_tag_srcrevs[key] = rev
+    return (dict_srcrevs, dict_tag_srcrevs)
 
-python do_write_srcrev() {
+do_fetch[postfuncs] += "write_srcrev"
+python write_srcrev() {
     pkghistdir = d.getVar('BUILDHISTORY_DIR_PACKAGE', True)
     srcrevfile = os.path.join(pkghistdir, 'latest_srcrev')
 
-    srcrevs = _get_srcrev_values(d)
+    srcrevs, tag_srcrevs = _get_srcrev_values(d)
     if srcrevs:
         if not os.path.exists(pkghistdir):
             os.makedirs(pkghistdir)
+        old_tag_srcrevs = {}
+        if os.path.exists(srcrevfile):
+            with open(srcrevfile) as f:
+                for line in f:
+                    if line.startswith('# tag_'):
+                        key, value = line.split("=", 1)
+                        key = key.replace('# tag_', '').strip()
+                        value = value.replace('"', '').strip()
+                        old_tag_srcrevs[key] = value
         with open(srcrevfile, 'w') as f:
             orig_srcrev = d.getVar('SRCREV', False) or 'INVALID'
             if orig_srcrev != 'INVALID':
@@ -568,9 +583,14 @@ python do_write_srcrev() {
                     f.write('SRCREV_%s = "%s"\n' % (name, srcrev))
             else:
                 f.write('SRCREV = "%s"\n' % srcrevs.itervalues().next())
+            if len(tag_srcrevs) > 0:
+                for name, srcrev in tag_srcrevs.items():
+                    f.write('# tag_%s = "%s"\n' % (name, srcrev))
+                    if name in old_tag_srcrevs and old_tag_srcrevs[name] != srcrev:
+                        pkg = d.getVar('PN', True)
+                        bb.warn("Revision for tag %s in package %s was changed since last build (from %s to %s)" % (name, pkg, old_tag_srcrevs[name], srcrev))
+
     else:
         if os.path.exists(srcrevfile):
             os.remove(srcrevfile)
 }
-
-addtask write_srcrev after do_fetch before do_build

meta/classes/cmake.bbclass

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

meta/classes/cpan.bbclass

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

meta/classes/fontcache.bbclass

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

meta/classes/gettext.bbclass

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

meta/classes/gtk-icon-cache.bbclass

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

meta/classes/icecc.bbclass

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