dev-manual: Spell check.

Found a couple words that were fat-fingered and fixed them.

(From yocto-docs rev: 593fd043f350bbce302c3de7dce0ab4bdbd2f247)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.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

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_extra.py

@@ -44,6 +44,7 @@ class HobRecipeInfo(RecipeInfoCommon):
         self.homepage = self.getvar('HOMEPAGE', metadata)
         self.bugtracker = self.getvar('BUGTRACKER', metadata)
         self.prevision = self.getvar('PR', metadata)
+        self.files_info = self.getvar('FILES_INFO', metadata)
 
     @classmethod
     def init_cacheData(cls, cachedata):
@@ -55,6 +56,7 @@ class HobRecipeInfo(RecipeInfoCommon):
         cachedata.homepage = {}
         cachedata.bugtracker = {}
         cachedata.prevision = {}
+        cachedata.files_info = {}
 
     def add_cacheData(self, cachedata, fn):
         cachedata.summary[fn] = self.summary
@@ -64,3 +66,4 @@ class HobRecipeInfo(RecipeInfoCommon):
         cachedata.homepage[fn] = self.homepage
         cachedata.bugtracker[fn] = self.bugtracker
         cachedata.prevision[fn] = self.prevision
+        cachedata.files_info[fn] = self.files_info

bitbake/lib/bb/cooker.py

@@ -576,6 +576,7 @@ class BBCooker:
             description = self.status.description[fn]
             homepage = self.status.homepage[fn]
             bugtracker = self.status.bugtracker[fn]
+            files_info = self.status.files_info[fn]
             rdepends = self.status.rundeps[fn]
             rrecs = self.status.runrecs[fn]
             prevision = self.status.prevision[fn]
@@ -591,6 +592,7 @@ class BBCooker:
                 depend_tree["pn"][pn]["inherits"] = inherits
                 depend_tree["pn"][pn]["homepage"] = homepage
                 depend_tree["pn"][pn]["bugtracker"] = bugtracker
+                depend_tree["pn"][pn]["files_info"] = files_info
                 depend_tree["pn"][pn]["revision"] = prevision
 
             if fnid not in seen_fnids:

bitbake/lib/bb/data.py

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

bitbake/lib/bb/tests/fetch.py

@@ -308,6 +308,8 @@ class FetcherTest(unittest.TestCase):
     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()
@@ -320,12 +322,16 @@ class FetcherTest(unittest.TestCase):
         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)
@@ -351,21 +357,29 @@ class FetcherTest(unittest.TestCase):
         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"

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

@@ -41,11 +41,11 @@ class PropertyDialog(CrumbsDialog):
 		
 		super(PropertyDialog, self).__init__(title, parent, flags, buttons)
                 
-                self.properties = information		
+                self.properties = information
 
                 if len(self.properties) == 10:
 		        self.create_recipe_visual_elements()
-                elif len(self.properties) == 4:
+                elif len(self.properties) == 5:
                         self.create_package_visual_elements()
                 else:
                         self.create_information_visual_elements()
@@ -56,6 +56,8 @@ class PropertyDialog(CrumbsDialog):
                 HOB_ICON_BASE_DIR = os.path.join(os.path.dirname(os.path.dirname(os.path.dirname(__file__))), ("icons/"))
                 ICON_PACKAGES_DISPLAY_FILE    = os.path.join(HOB_ICON_BASE_DIR, ('info/info_display.png'))
 
+                self.set_resizable(False)
+
                 self.table = gtk.Table(1,1,False)
                 self.table.set_row_spacings(0)
                 self.table.set_col_spacings(0)
@@ -86,6 +88,19 @@ class PropertyDialog(CrumbsDialog):
         
                 self.vbox.add(self.table)
 
+        def treeViewTooltip( self, widget, e, tooltips, cell, emptyText="" ):
+                 try:
+                           (path,col,x,y) = widget.get_path_at_pos( int(e.x), int(e.y) )
+                           it = widget.get_model().get_iter(path)
+                           value = widget.get_model().get_value(it,cell)
+                           if value in self.tooltip_items:
+                                tooltips.set_tip(widget, self.tooltip_items[value])
+                                tooltips.enable()
+                           else:
+                                tooltips.set_tip(widget, emptyText)
+                 except:
+                           tooltips.set_tip(widget, emptyText)
+
                 
         def create_package_visual_elements(self):
 
@@ -93,7 +108,18 @@ class PropertyDialog(CrumbsDialog):
                 binb = self.properties['binb']
                 size = self.properties['size']
                 recipe = self.properties['recipe']
+                file_list = self.properties['files_list']
 
+                file_list = file_list.strip("{}'")
+                files_temp = ''
+                paths_temp = ''
+                files_binb = []
+                paths_binb = []
+
+                self.tooltip_items = {}
+
+                self.set_resizable(False)
+                
                 #cleaning out the recipe variable
                 recipe = recipe.split("+")[0]
 
@@ -151,9 +177,71 @@ class PropertyDialog(CrumbsDialog):
                         self.vbox.add(self.label_short)
                         self.vbox.add(self.label_info)
 
+                #################################### FILES BROUGHT BY PACKAGES ###################################
+
+                if file_list != '':
+                
+                        self.textWindow = gtk.ScrolledWindow()
+                        self.textWindow.set_shadow_type(gtk.SHADOW_IN)
+                        self.textWindow.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
+                        self.textWindow.set_size_request(100, 170)
+
+                        sstatemirrors_store = gtk.ListStore(str)
+
+                        self.sstatemirrors_tv = gtk.TreeView()
+                        self.sstatemirrors_tv.set_rules_hint(True)
+                        self.sstatemirrors_tv.set_headers_visible(True)
+                        self.textWindow.add(self.sstatemirrors_tv)
+
+                        self.cell1 = gtk.CellRendererText()
+                        col1 = gtk.TreeViewColumn('Package files', self.cell1)
+                        col1.set_cell_data_func(self.cell1, self.regex_field)
+                        self.sstatemirrors_tv.append_column(col1)
+
+                        for items in file_list.split(']'):
+                            if len(items) > 1:
+                                paths_temp = items.split(":")[0]
+                                paths_binb.append(paths_temp.strip(" ,'"))
+                                files_temp = items.split(":")[1]
+                                files_binb.append(files_temp.strip(" ['"))
+
+                        unsorted_list = []
+                        
+                        for items in range(len(paths_binb)):
+                              if len(files_binb[items]) > 1:
+                                  for aduse in (files_binb[items].split(",")):
+                                        unsorted_list.append(paths_binb[items].split(name)[len(paths_binb[items].split(name))-1] + '/' + aduse.strip(" '"))
+                       
+                         
+                        unsorted_list.sort()
+                        for items in unsorted_list:
+                                temp = items
+                                while len(items) > 35:
+                                        items = items[:len(items)/2] + "" + items[len(items)/2+1:]
+                                if len(items) == 35:
+                                        items = items[:len(items)/2] + "..." + items[len(items)/2+3:]
+                                        self.tooltip_items[items] = temp
+
+                                sstatemirrors_store.append([str(items)])
+                                
+                                
+                        self.sstatemirrors_tv.set_model(sstatemirrors_store)
+
+                        tips = gtk.Tooltips()
+                        tips.set_tip(self.sstatemirrors_tv, "")
+                        self.sstatemirrors_tv.connect("motion-notify-event", self.treeViewTooltip, tips, 0)
+                        self.sstatemirrors_tv.set_events(gtk.gdk.POINTER_MOTION_MASK)
+                        
+                        self.vbox.add(self.textWindow)                                      
+
                 self.vbox.show_all()
 
 
+        def regex_field(self, column, cell, model, iter):
+                cell.set_property('text', model.get_value(iter, 0))
+                return
+
+
 	def create_recipe_visual_elements(self):
 
                 summary = self.properties['summary']
@@ -166,6 +254,8 @@ class PropertyDialog(CrumbsDialog):
 		homepage = self.properties['homepage']
 		bugtracker = self.properties['bugtracker']
 		description = self.properties['description']
+
+                self.set_resizable(False)
 		
                 #cleaning out the version variable and also the summary
                 version = version.split(":")[1]

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

@@ -35,7 +35,7 @@ class PackageListModel(gtk.ListStore):
     provide filtered views of the data.
     """
 
-    (COL_NAME, COL_VER, COL_REV, COL_RNM, COL_SEC, COL_SUM, COL_RDEP, COL_RPROV, COL_SIZE, COL_RCP, COL_BINB, COL_INC, COL_FADE_INC, COL_FONT) = range(14)
+    (COL_NAME, COL_VER, COL_REV, COL_RNM, COL_SEC, COL_SUM, COL_RDEP, COL_RPROV, COL_SIZE, COL_RCP, COL_BINB, COL_INC, COL_FADE_INC, COL_FONT, COL_FLIST) = range(15)
 
     __gsignals__ = {
         "package-selection-changed" : (gobject.SIGNAL_RUN_LAST,
@@ -61,6 +61,7 @@ class PackageListModel(gtk.ListStore):
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_BOOLEAN,
                                 gobject.TYPE_BOOLEAN,
+                                gobject.TYPE_STRING,
                                 gobject.TYPE_STRING)
 
     """
@@ -90,7 +91,7 @@ class PackageListModel(gtk.ListStore):
         for key in filter.keys():
             if key == self.COL_NAME:
                 if filter[key] != 'Search packages by name':
-                    if filter[key] not in name:
+                    if name and filter[key] not in name:
                         return False
             else:
                 if model.get_value(it, key) not in filter[key]:
@@ -199,6 +200,7 @@ class PackageListModel(gtk.ListStore):
             rdep = getpkgvalue(pkginfo, 'RDEPENDS', pkg, "")
             rrec = getpkgvalue(pkginfo, 'RRECOMMENDS', pkg, "")
             rprov = getpkgvalue(pkginfo, 'RPROVIDES', pkg, "")
+            files_list = getpkgvalue(pkginfo, 'FILES_INFO', pkg, "")
             for i in rprov.split():
                 self.rprov_pkg[i] = pkg
 
@@ -218,7 +220,7 @@ class PackageListModel(gtk.ListStore):
                      self.COL_RDEP, rdep + ' ' + rrec,
                      self.COL_RPROV, rprov, self.COL_SIZE, size,
                      self.COL_RCP, recipe, self.COL_BINB, "",
-                     self.COL_INC, False, self.COL_FONT, '10')
+                     self.COL_INC, False, self.COL_FONT, '10', self.COL_FLIST, files_list)
 
         self.pn_path = {}
         it = self.get_iter_first()

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

@@ -142,7 +142,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)
@@ -165,6 +165,7 @@ class HobViewTable (gtk.VBox):
         no_result_tab.attach(label, 1, 14, 1, 4)
 
         clear_button = HobButton("Clear search")
+        clear_button.set_tooltip_text("Clear search query")
         clear_button.connect('clicked', self.set_search_entry_clear_cb, entry)
         no_result_tab.attach(clear_button, 16, 19, 1, 4)
 
@@ -480,6 +481,8 @@ class HobNotebook(gtk.Notebook):
         self.pages = []
 
         self.search = None
+        self.search_focus = False
+        self.page_changed = False
 
         self.connect("switch-page", self.page_changed_cb)
 
@@ -493,6 +496,7 @@ class HobNotebook(gtk.Notebook):
                 lbl.set_active(False)
 
         if self.search:
+            self.page_changed = True
             self.reset_entry(self.search, page_num)
 
     def append_page(self, child, tab_label, tab_tooltip=None):
@@ -536,15 +540,20 @@ class HobNotebook(gtk.Notebook):
                 child.set_count(0)
 
     def set_search_entry_editable_cb(self, search, event):
+        self.search_focus = True
         search.set_editable(True)
-        search.set_text("")
+        text = search.get_text()
+        if text in self.search_names:
+            search.set_text("")
         style = self.search.get_style()
         style.text[gtk.STATE_NORMAL] = self.get_colormap().alloc_color(HobColors.BLACK, False, False)
         search.set_style(style)
 
     def set_search_entry_reset_cb(self, search, event):
         page_num = self.get_current_page()
-        self.reset_entry(search, page_num)
+        text = search.get_text()
+        if not text:
+            self.reset_entry(search, page_num)
 
     def reset_entry(self, entry, page_num):
         style = entry.get_style()
@@ -559,6 +568,7 @@ class HobNotebook(gtk.Notebook):
         if search.get_editable() == True:
             search.set_text("")
         search.set_icon_sensitive(gtk.ENTRY_ICON_SECONDARY, False)
+        search.grab_focus()
 
     def set_page(self, title):
         for child in self.pages:

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

@@ -180,9 +180,19 @@ class PackageSelectionPage (HobPage):
         self.button_box.pack_end(self.back_button, expand=False, fill=False)
 
     def search_entry_changed(self, entry):
+        text = entry.get_text()
+        if self.ins.search_focus:
+            self.ins.search_focus = False
+        elif self.ins.page_changed:
+            self.ins.page_change = False
+            self.filter_search(entry)
+        elif text not in self.ins.search_names:
+            self.filter_search(entry)
+
+    def filter_search(self, entry):
+        text = entry.get_text()
         current_tab = self.ins.get_current_page()
         filter = self.pages[current_tab]['filter']
-        text = entry.get_text()
         filter[PackageListModel.COL_NAME] = text
         self.tables[current_tab].set_model(self.package_model.tree_model(filter, search_data=text))
         if self.package_model.filtered_nb == 0:
@@ -202,12 +212,13 @@ class PackageSelectionPage (HobPage):
     def button_click_cb(self, widget, event):
         path, col = widget.table_tree.get_cursor()
         tree_model = widget.table_tree.get_model()
-        if path: # else activation is likely a removal
-            properties = {'binb': '' , 'name': '', 'size':'', 'recipe':''}
+        if path and col.get_title() != 'Included': # else activation is likely a removal
+            properties = {'binb': '' , 'name': '', 'size':'', 'recipe':'', 'files_list':''}
             properties['binb'] = tree_model.get_value(tree_model.get_iter(path), PackageListModel.COL_BINB)
             properties['name'] = tree_model.get_value(tree_model.get_iter(path), PackageListModel.COL_NAME)
             properties['size'] = tree_model.get_value(tree_model.get_iter(path), PackageListModel.COL_SIZE)
             properties['recipe'] = tree_model.get_value(tree_model.get_iter(path), PackageListModel.COL_RCP)
+            properties['files_list'] = tree_model.get_value(tree_model.get_iter(path), PackageListModel.COL_FLIST)
 
             self.builder.show_recipe_property_dialog(properties)
 

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

@@ -195,9 +195,19 @@ class RecipeSelectionPage (HobPage):
         button_box.pack_end(self.back_button, expand=False, fill=False)
 
     def search_entry_changed(self, entry):
+        text = entry.get_text()
+        if self.ins.search_focus:
+            self.ins.search_focus = False
+        elif self.ins.page_changed:
+            self.ins.page_change = False
+            self.filter_search(entry)
+        elif text not in self.ins.search_names:
+            self.filter_search(entry)
+
+    def filter_search(self, entry):
+        text = entry.get_text()
         current_tab = self.ins.get_current_page()
         filter = self.pages[current_tab]['filter']
-        text = entry.get_text()
         filter[RecipeListModel.COL_NAME] = text
         self.tables[current_tab].set_model(self.recipe_model.tree_model(filter, search_data=text))
         if self.recipe_model.filtered_nb == 0:
@@ -217,7 +227,7 @@ class RecipeSelectionPage (HobPage):
     def button_click_cb(self, widget, event):
         path, col = widget.table_tree.get_cursor()
         tree_model = widget.table_tree.get_model()
-        if path: # else activation is likely a removal
+        if path and col.get_title() != 'Included': # else activation is likely a removal
             properties = {'summary': '', 'name': '', 'version': '', 'revision': '', 'binb': '', 'group': '', 'license': '', 'homepage': '', 'bugtracker': '', 'description': ''}
             properties['summary'] = tree_model.get_value(tree_model.get_iter(path), RecipeListModel.COL_SUMMARY)
             properties['name'] = tree_model.get_value(tree_model.get_iter(path), RecipeListModel.COL_NAME)

documentation/adt-manual/adt-manual.xml

@@ -58,7 +58,7 @@
             </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>

documentation/bsp-guide/bsp-guide.xml

@@ -70,7 +70,7 @@
             </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>

documentation/bsp-guide/bsp.xml

@@ -312,14 +312,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 +329,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>

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'>
@@ -142,11 +146,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 +165,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 +179,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 +191,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

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

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

@@ -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,7 +776,8 @@
     <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
@@ -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,7 +1084,7 @@
         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.
@@ -1080,7 +1094,7 @@
     </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 +1105,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 +1113,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 +1150,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 +1158,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 +1186,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 +1232,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 +1248,9 @@
                 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>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
         </orderedlist>
     </para>
@@ -1253,9 +1271,10 @@
     </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 +1289,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 +1357,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 +1372,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 +1388,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 +1439,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 +1465,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 +1474,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 +1524,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,7 +48,7 @@
             </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>

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

@@ -224,6 +224,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 +233,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

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

@@ -135,6 +135,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 +143,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,

documentation/kernel-dev/kernel-dev.xml

@@ -33,7 +33,7 @@
         <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>
         </revhistory>

documentation/profile-manual/profile-manual.xml

@@ -33,7 +33,7 @@
         <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>
         </revhistory>

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,12 @@
         </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.
             </para>
         </answer>
     </qandaentry>
@@ -241,6 +245,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 +263,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 +272,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 +295,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 +314,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 +351,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 visualization issues.
             </para>
         </answer>
     </qandaentry>
@@ -353,13 +377,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 +407,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 +431,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 +453,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 +494,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 +514,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 +624,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 +633,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 +644,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 +676,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>
@@ -133,8 +135,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 +310,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,278 @@
                 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>,
+                    <filename>RSUGGESTS</filename>, 
+                    <filename>RPROVIDES</filename>,
+                    <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 <filename>MACHINEOVERRIDES</filename> 
+                    or <filename>DISTROOVERRIDES</filename> variables, 
+                    as appropriate.
+                    </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-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 <filename>SANITY_TESTED_DISTROS</filename> variable now uses a
+            distribution ID, which is composed of the host distributor ID 
+            followed by the release.
+            Previously, it was composed of the description field.
+            For example, "Ubuntu 12.10" becomes "Ubuntu-12.10". 
+            You do not need to worry about this change if you are not 
+            specifically setting this variable, or if you are
+            specifically setting it to "".
+        </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>
@@ -166,8 +179,9 @@
     <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> brought standardization and this class
+        aims to smooth integration of <filename>pkg-config</filename>
+        into libraries that use it.
     </para>
 
     <para>
@@ -190,7 +204,7 @@
 
     <para>
         The results of these classes are <filename>tmp/deploy/source/</filename>
-        subdirs with sources sorted by
+        subdirectories with sources sorted by
         <filename><link linkend='var-LICENSE'>LICENSE</link></filename> field.
         If recipes list few licenses (or have entries like "Bitstream Vera"),
         the source archive is placed in each license directory.
@@ -200,11 +214,13 @@
         This class operates using three modes:
         <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>
+                distribution directory.</para></listitem>
+            <listitem><para><emphasis>symlink:</emphasis> Creates symbolic
+                links for the files to the distribution directory.
+                </para></listitem>
+            <listitem><para><emphasis>move+symlink:</emphasis> Moves the files
+                into the distribution directory and then creates symbolic
+                links back to where they originated.</para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -217,16 +233,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 +253,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 +284,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 +327,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 +418,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>
 
@@ -468,8 +503,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 +519,15 @@
                 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>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>
@@ -540,7 +576,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 +631,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

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,7 +64,7 @@
             </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>

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

@@ -27,7 +27,7 @@
        <link linkend='var-IMAGE_FEATURES'>I</link>
 <!--               <link linkend='var-glossary-j'>J</link> -->
        <link linkend='var-KARCH'>K</link>
-       <link linkend='var-LAYERDIR'>L</link>
+       <link linkend='var-LAYERDEPENDS'>L</link>
        <link linkend='var-MACHINE'>M</link>
 <!--               <link linkend='var-glossary-n'>N</link> -->
        <link linkend='var-OE_TERMINAL'>O</link>
@@ -69,16 +69,17 @@
 
          <glossentry id='var-AUTHOR'><glossterm>AUTHOR</glossterm>
             <glossdef>
-                <para>The email address used to contact the original author or authors in
-                    order to send patches, forward bugs, etc.</para>
+                <para>The email address used to contact the original author
+                    or authors in order to send patches and forward bugs.</para>
             </glossdef>
          </glossentry>
 
         <glossentry id='var-AUTOREV'><glossterm>AUTOREV</glossterm>
             <glossdef>
                 <para>When <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
-                    is set to the value of this variable, it specifies that the latest
-                    source revision in the repository should be used. Here is an example:
+                    is set to the value of this variable, it specifies to use the latest
+                    source revision in the repository.
+                    Here is an example:
                     <literallayout class='monospaced'>
      SRCREV = "${AUTOREV}"
                     </literallayout>
@@ -103,7 +104,7 @@
                     </literallayout>
                     You can separate the (<filename>S</filename>) directory and the directory pointed to
                     by the <filename>B</filename> variable.
-                    Most autotools-based recipes support separating these directories.
+                    Most Autotools-based recipes support separating these directories.
                     The build system defaults to using separate directories for <filename>gcc</filename>
                     and some kernel recipes.
                 </para>
@@ -115,7 +116,7 @@
                 <para>
                     A list of packages not to install despite being recommended by a recipe.
                     Support for this variable exists only when using the
-                    <filename>ipk</filename> packaging backend.
+                    IPK packaging backend.
                 </para>
             </glossdef>
         </glossentry>
@@ -233,8 +234,8 @@
                 <para>
                     The second example stops the build after all currently
                     executing tasks complete when the minimum disk space
-                    in the <filename>${TMPDIR}</filename> directory drops
-                    below 1 Gbyte.
+                    in the <filename>${<link linkend='var-TMPDIR'>TMPDIR</link>}</filename>
+                    directory drops below 1 Gbyte.
                     No disk monitoring occurs for the free inodes in this case.
                 </para>
 
@@ -310,7 +311,7 @@
                     of free inodes further reduces by 5 Kbytes in the
                     <filename>${SSTATE_DIR}</filename> directory.
                     Subsequent warnings based on the interval occur each time
-                    a respective interval is reached beyond the intial warning
+                    a respective interval is reached beyond the initial warning
                     (i.e. 1 Gbytes and 100 Kbytes).
                 </para>
             </glossdef>
@@ -321,7 +322,7 @@
                 <para>
                     Allows you to extend a recipe so that it builds variants of the software.
                     Common variants for recipes exist such as "natives" like <filename>quilt-native</filename>,
-                    which is a copy of quilt built to run on the build system;
+                    which is a copy of Quilt built to run on the build system;
                     "crosses" such as <filename>gcc-cross</filename>,
                     which is a compiler built to run on the build machine but produces binaries
                     that run on the target <link linkend='var-MACHINE'><filename>MACHINE</filename></link>;
@@ -361,11 +362,11 @@
                     Consequently, matching files are not parsed or otherwise
                     used by BitBake.</para>
                 <para>
-                    The value you provide is passed to python's regular
+                    The value you provide is passed to Python's regular
                     expression compiler.
                     The expression is compared against the full paths to
                     the files.
-                    For complete syntax information, see python's
+                    For complete syntax information, see Python's
                     documentation at
                     <ulink url='http://docs.python.org/release/2.3/lib/re-syntax.html'></ulink>.
                 </para>
@@ -421,7 +422,9 @@
 
         <glossentry id='var-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm>
             <glossdef>
-                <para>Variable that expands to match files from <filename>BBFILES</filename> in a particular layer.
+                <para>Variable that expands to match files from
+                    <link linkend='var-BBFILES'><filename>BBFILES</filename></link>
+                    in a particular layer.
                     This variable is used in the <filename>conf/layer.conf</filename> file and must
                     be suffixed with the name of the specific layer (e.g.
                     <filename>BBFILE_PATTERN_emenlow</filename>).</para>
@@ -437,7 +440,8 @@
                     layer against other layers that contain the same recipe - effectively
                     letting you control the precedence for the multiple layers.
                     The precedence established through this variable stands regardless of a
-                    recipe's version (<filename>PV</filename> variable).
+                    recipe's version
+                    (<link linkend='var-PV'><filename>PV</filename></link> variable).
                     For example, a layer that has a recipe with a higher <filename>PV</filename> value but for
                     which the <filename>BBFILE_PRIORITY</filename> is set to have a lower precedence still has a
                     lower precedence.</para>
@@ -460,7 +464,7 @@
 
         <glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm>
             <glossdef>
-                <para>List of recipe files used by BitBake to build software</para>
+                <para>List of recipe files used by BitBake to build software.</para>
             </glossdef>
         </glossentry>
 
@@ -552,10 +556,25 @@ Core layer for images cannot be removed
                     <link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link> variable.
                     The exact list of prefixes removed is specified by the
                     <link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link> variable.
-                    Prefixes are removed for multilib and nativesdk cases.</para>
+                    Prefixes are removed for <filename>multilib</filename>
+                    and <filename>nativesdk</filename> cases.</para>
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-BUILDDIR'><glossterm>BUILDDIR</glossterm>
+            <glossdef>
+                <para>Points to the location of the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    You can define this directory indirectly through the
+                    <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                    script by passing in a Build Directory path when you run the
+                    script.
+                    If you run the script and do not provide a Build Directory
+                    path, the <filename>BUILDDIR</filename> defaults to
+                    <filename>build</filename> in the current directory.
+                </para>
+            </glossdef>
+        </glossentry>
     </glossdiv>
 
     <glossdiv id='var-glossary-c'><title>C</title>
@@ -563,7 +582,7 @@ Core layer for images cannot be removed
         <glossentry id='var-CFLAGS'><glossterm>CFLAGS</glossterm>
             <glossdef>
                 <para>
-                    Flags passed to C compiler for the target system.
+                    Flags passed to the C compiler for the target system.
                     This variable evaluates to the same as
                     <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>.
                 </para>
@@ -581,12 +600,14 @@ Core layer for images cannot be removed
 
         <glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
             <glossdef>
-                <para>A regular expression which evaluates to match the machines the recipe
-                    works with.
-                    It stops recipes being run on machines for which they are not compatible.
+                <para>A regular expression that evaluates to match the machines
+                    with which the recipe works.
+                    You can use the variable to stop recipes from being run
+                    on machines for which they are not compatible.
                     This is particularly useful with kernels.
-                    It also helps to increase parsing speed as further parsing of the recipe is skipped
-                    if it is found the current machine is not compatible.</para>
+                    The variable also helps to increase parsing speed as
+                    further parsing of the recipe is skipped if it is found
+                    the current machine is not compatible.</para>
             </glossdef>
         </glossentry>
 
@@ -655,8 +676,9 @@ Core layer for images cannot be removed
             <glossdef>
                 <para>
                     Specifies the list of packages to be added to the image.
-                    This variable should only be set in the <filename>local.conf</filename>
-                    configuration file found in the
+                    You should only set this variable in the
+                    <filename>local.conf</filename> configuration file found
+                    in the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
                 </para>
 
@@ -741,9 +763,10 @@ Core layer for images cannot be removed
                     This variable corresponds to a file with the
                     extension <filename>.conf</filename>
                     located in a <filename>conf/distro</filename> directory
-                    within the metadata that contains the distribution configuration.
-                    The
-                    value must not contain spaces, and is typically all lower-case.
+                    within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    that contains the distribution configuration.
+                    The value must not contain spaces, and is typically all lower-case.
                 </para>
                 <para>
                     If the variable is blank, a set of default configuration
@@ -775,8 +798,8 @@ Core layer for images cannot be removed
                     Specifies a list of distro-specific packages to add to all images
                     if the packages exist.
                     The packages might not exist or be empty (e.g. kernel modules).
-                    The list of packages are automatically installed but can be
-                    removed by the user.
+                    The list of packages are automatically installed but you can
+                    remove them.
                 </para>
             </glossdef>
         </glossentry>
@@ -784,8 +807,9 @@ Core layer for images cannot be removed
         <glossentry id='var-DISTRO_FEATURES'><glossterm>DISTRO_FEATURES</glossterm>
             <glossdef>
                 <para>The features enabled for the distribution.
-                    For a list of features supported by the Yocto Project as shipped,
-                    see the "<link linkend='ref-features-distro'>Distro</link>"
+                    For a list of supported features that ship with the
+                    Yocto Project, see the
+                    "<link linkend='ref-features-distro'>Distro</link>"
                     section.
                 </para>
             </glossdef>
@@ -814,7 +838,7 @@ Core layer for images cannot be removed
             <glossdef>
                 <para>Features from
                     <filename><link linkend='var-DISTRO_FEATURES_BACKFILL'>DISTRO_FEATURES_BACKFILL</link></filename>
-                    that should not backfilled (i.e. added to
+                    that should not be backfilled (i.e. added to
                     <filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>)
                     during the build.
                     See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
@@ -879,8 +903,9 @@ Core layer for images cannot be removed
                 <para>
                     You can safely share this directory between multiple builds on the
                     same development machine.
-                    For additional information on how the build process gets source files
-                    when working behind a firewall or proxy server, see the
+                    For additional information on how the build process gets
+                    source files when working behind a firewall or proxy server,
+                    see this specific question in the
                     "<link linkend='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</link>"
                     chapter.
                 </para>
@@ -894,8 +919,9 @@ Core layer for images cannot be removed
         <glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
             <glossdef>
                 <para></para>
-                <para>Variable that controls which locales for <filename>eglibc</filename> are
-                    to be generated during the build (useful if the target device has 64Mbytes
+                <para>Variable that controls which locales for
+                    <filename>eglibc</filename> are generated during the
+                    build (useful if the target device has 64Mbytes
                     of RAM or less).</para>
             </glossdef>
         </glossentry>
@@ -920,25 +946,43 @@ Core layer for images cannot be removed
 
         <glossentry id='var-EXTRA_IMAGE_FEATURES'><glossterm>EXTRA_IMAGE_FEATURES</glossterm>
             <glossdef>
-                <para>Allows extra packages to be added to the generated images.
-                    You set this variable in the <filename>local.conf</filename>
-                    configuration file.
-                    Note that some image features are also added using the
-                    <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
-                    variable generally configured in image recipes.
-                    You can use this variable to add more features in addition to those.
-                    Here are some examples of features you can add:</para>
+                <para>
+                    The list of additional features to include in an image.
+                    Typically, you configure this variable in your
+                    <filename>local.conf</filename> file, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    Although you can use this variable from within a recipe,
+                    best practices dictate that you do not.
+                    <note>
+                        To enable primary features from within the image
+                        recipe, use the
+                        <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                        variable.
+                    </note>
+                </para>
+
+                <para>
+                    Here are some examples of features you can add:
                     <literallayout class='monospaced'>
 "dbg-pkgs" - Adds -dbg packages for all installed packages
              including symbol information for debugging and
              profiling.
 
+"debug-tweaks" - Makes an image suitable for development.
+                 For example, ssh root access has a blank
+                 password.  You should remove this feature
+                 before you produce a production image.
+
 "dev-pkgs" - Adds -dev packages for all installed packages.
              This is useful if you want to develop against
              the libraries in the image.
 
-"tools-sdk" - Adds development tools such as gcc, make,
-              pkgconfig and so forth.
+"read-only-rootfs" - 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
 
 "tools-debug" - Adds debugging tools such as gdb and
                 strace.
@@ -946,26 +990,36 @@ Core layer for images cannot be removed
 "tools-profile" - Adds profiling tools such as oprofile,
                   exmap, lttng and valgrind (x86 only).
 
+"tools-sdk" - Adds development tools such as gcc, make,
+              pkgconfig and so forth.
+
 "tools-testapps" - Adds useful testing tools such as
                    ts_print, aplay, arecord and so
                    forth.
 
-"debug-tweaks" - Makes an image suitable for development.
-                 For example, ssh root access has a blank
-                 password.  You should remove this feature
-                 before you produce a production image.
                     </literallayout>
+                </para>
 
-                 <para>There are other valid features too, see the
-                 <link linkend='ref-features-image'>Images</link>
-                 section for more details.</para>
+                <para>
+                    For a complete list of image features that ships with the
+                    Yocto Project, see the
+                    "<link linkend="ref-features-image">Images</link>"
+                    section.
+                </para>
+
+                <para>
+                    For an example that shows how to customize your image by
+                    using this variable, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
             </glossdef>
         </glossentry>
 
         <glossentry id='var-EXTRA_IMAGEDEPENDS'><glossterm>EXTRA_IMAGEDEPENDS</glossterm>
             <glossdef>
-                <para>A list of recipes to be built that do not provide packages to be installed in
-                    the root filesystem.
+                <para>A list of recipes to build that do not provide packages
+                    for installing into the root filesystem.
                 </para>
                 <para>Sometimes a recipe is required to build the final image but is not
                     needed in the root filesystem.
@@ -975,7 +1029,8 @@ Core layer for images cannot be removed
                 </para>
                 <note>
                     To add packages to the root filesystem, see the various
-                    <filename>*DEPENDS</filename> and <filename>*RECOMMENDS</filename>
+                    <filename>*<link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
+                    and <filename>*<link linkend='var-RRECOMMENDS'>RRECOMMENDS</link></filename>
                     variables.
                 </note>
             </glossdef>
@@ -1180,13 +1235,30 @@ Core layer for images cannot be removed
 
         <glossentry id='var-IMAGE_FEATURES'><glossterm>IMAGE_FEATURES</glossterm>
             <glossdef>
-                <para>The list of features to include in an image.
-                Typically, you configure this variable in an image recipe.
-                Note that you can also add extra features to the image by using the
-                <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable.
-                See the "<link linkend="ref-features-image">Images</link>" section for the
-                full list of features that can be included in images built by the
-                OpenEmbedded build system.</para>
+                <para>
+                    The primary list of features to include in an image.
+                    Typically, you configure this variable in an image recipe.
+                    Although you can use this variable from your
+                    <filename>local.conf</filename> file, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                    best practices dictate that you do not.
+                    <note>
+                        To enable extra features from outside the image recipe,
+                        use the
+                        <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable.
+                    </note>
+                    For a list of image features that ships with the Yocto
+                    Project, see the
+                    "<link linkend="ref-features-image">Images</link>"
+                    section.
+                </para>
+
+                <para>
+                    For example that shows how to customize your image by
+                    using this variable, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
             </glossdef>
         </glossentry>
 
@@ -1335,6 +1407,9 @@ Core layer for images cannot be removed
 
       xspace = IMAGE_ROOTFS_EXTRA_SPACE
                     </literallayout>
+                    See the <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
+                    and <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
+                    variables for related information.
 <!--                    In the above example, <filename>overhead</filename> is defined by the
                     <filename><link linkend='var-IMAGE_OVERHEAD_FACTOR'>IMAGE_OVERHEAD_FACTOR</link></filename>
                     variable, <filename>xspace</filename> is defined by the
@@ -1354,13 +1429,14 @@ Core layer for images cannot be removed
                 <para>Suppose, for example, you have a set of recipes that
                     are used across several projects.
                     And, within each of those recipes the revision
-                    (its <filename>PR</filename> value) is set accordingly.
-                    In this case, when the revision of those recipes changes
+                    (its <link linkend='var-PR'><filename>PR</filename></link>
+                    value) is set accordingly.
+                    In this case, when the revision of those recipes changes,
                     the burden is on you to find all those recipes and
                     be sure that they get changed to reflect the updated
                     version of the recipe.
                     In this scenario, it can get complicated when recipes
-                    used in many places and that provide common functionality
+                    that are used in many places and provide common functionality
                     are upgraded to a new revision.</para>
                 <para>A more efficient way of dealing with this situation is
                     to set the <filename>INC_PR</filename> variable inside
@@ -1425,7 +1501,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     to the other <filename>INITSCRIPT_*</filename> as an override.</para>
                  <para>
                     This variable is used in recipes when using <filename>update-rc.d.bbclass</filename>.
-                    The variable is optional and defaults to the <filename>PN</filename> variable.
+                    The variable is optional and defaults to the
+                    <link linkend='var-PN'><filename>PN</filename></link> variable.
                 </para>
            </glossdef>
         </glossentry>
@@ -1433,7 +1510,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-INITSCRIPT_NAME'><glossterm>INITSCRIPT_NAME</glossterm>
             <glossdef>
                 <para>
-                    The filename of the initscript (as installed to <filename>${etcdir}/init.d)</filename>.
+                    The filename of the initscript as installed to <filename>${etcdir}/init.d</filename>.
                 </para>
                 <para>
                     This variable is used in recipes when using <filename>update-rc.d.bbclass</filename>.
@@ -1446,8 +1523,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             <glossdef>
                 <para>
                     Specifies the options to pass to <filename>update-rc.d</filename>.
-                    An example is <filename>start 99 5 2 . stop 20 0 1 6 .</filename>, which gives the script a
-                    runlevel of 99, starts the script in initlevels 2 and 5, and
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
+                    </literallayout>
+                    In this example, the script has a runlevel of 99,
+                    starts the script in initlevels 2 and 5, and
                     stops the script in levels 0, 1 and 6.
                 </para>
                 <para>
@@ -1468,7 +1549,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-KARCH'><glossterm>KARCH</glossterm>
             <glossdef>
                 <para>
-                    Defines the kernel architecture to be used in assembling
+                    Defines the kernel architecture used when assembling
                     the configuration.
                     Architectures supported for this release are:
                     <literallayout class='monospaced'>
@@ -1558,8 +1639,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             <glossdef>
                 <para>Includes additional metadata from the Yocto Project kernel Git repository.
                     In the OpenEmbedded build system, the default Board Support Packages (BSPs)
-                    metadata is provided through
-                    the <filename>KMACHINE</filename> and <filename>KBRANCH</filename> variables.
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    is provided through
+                    the <link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>
+                    and <link linkend='var-KBRANCH'><filename>KBRANCH</filename></link> variables.
                     You can use the <filename>KERNEL_FEATURES</filename> variable to further
                     add metadata for all BSPs.</para>
                 <para>The metadata you add through this variable includes config fragments and
@@ -1637,7 +1720,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     Provides a short description of a configuration fragment.
                     You use this variable in the <filename>.scc</filename>
-                    file that describes a configuruation fragment file.
+                    file that describes a configuration fragment file.
                     Here is the variable used in a file named
                     <filename>smp.scc</filename> to describe SMP being
                     enabled:
@@ -1663,8 +1746,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
                 <para>
                     Kernel machine names are initially defined in the
-                    <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>Yocto Linux Kernel</ulink> in
-                    the <filename>meta</filename> branch.
+                    Yocto Linux Kernel's <filename>meta</filename> branch.
                     From the <filename>meta</filename> branch, look in
                     the <filename>meta/cfg/kernel-cache/bsp/&lt;bsp_name&gt;/&lt;bsp-name&gt;-&lt;kernel-type&gt;.scc</filename> file.
                     For example, from the <filename>meta</filename> branch in the
@@ -1681,13 +1763,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
      include cedartrail.scc
                     </literallayout>
-                    You can see that the kernel understands the machine name for the Cedar Trail BSP as
+                    You can see that the kernel understands the machine name for
+                    the Cedar Trail Board Support Package (BSP) as
                     <filename>cedartrail</filename>.
                 </para>
 
                 <para>
-                    If you look in the Cedar Trail BSP layer in the <filename>meta-intel</filename> source
-                    repository at <filename>meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>,
+                    If you look in the Cedar Trail BSP layer in the
+                    <filename>meta-intel</filename>
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>
+                    at <filename>meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>,
                     you will find the following statements among others:
                     <literallayout class='monospaced'>
      COMPATIBLE_MACHINE_cedartrail = "cedartrail"
@@ -1720,7 +1805,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     The second statement is a good example of why the <filename>KMACHINE</filename> variable
                     is needed.
                     In this example, the OpenEmbedded build system uses the <filename>cedartrail-nopvr</filename>
-                    machine name to refer to the Cedar Trail BSP that does not support the propriatory
+                    machine name to refer to the Cedar Trail BSP that does not support the proprietary
                     PowerVR driver.
                     The kernel, however, uses the machine name <filename>cedartrail</filename>.
                     Thus, the append file must map the <filename>cedartrail-nopvr</filename> machine name to
@@ -1770,7 +1855,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>Lists the layers that this recipe depends upon, separated by spaces.
                     Optionally, you can specify a specific layer version for a dependency
                     by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
-                    to be compared against <filename>LAYERVERSION_anotherlayer</filename> in this case).
+                    to be compared against
+                    <link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename>
+                    in this case).
                     An error will be produced if any dependency is missing or
                     the version numbers do not match exactly (if specified).
                     This variable is used in the <filename>conf/layer.conf</filename> file
@@ -1783,18 +1870,18 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             <glossdef>
                 <para>When used inside the <filename>layer.conf</filename> configuration
                     file, this variable provides the path of the current layer.
-                    This variable requires immediate expansion
-                    (see the BitBake manual) as lazy expansion can result in
-                    the expansion happening in the wrong directory and therefore
-                    giving the wrong value.</para>
+                    This variable is not available outside of <filename>layer.conf</filename>
+                    and references are expanded immediately when parsing of the file completes.</para>
             </glossdef>
         </glossentry>
 
         <glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
             <glossdef>
                 <para>Optionally specifies the version of a layer as a single number.
-                    You can use this within <filename>LAYERDEPENDS</filename> for another layer in order to
-                    depend on a specific version of the layer.
+                    You can use this within
+                    <link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
+                    for another layer in order to depend on a specific version
+                    of the layer.
                     This variable is used in the <filename>conf/layer.conf</filename> file
                     and must be suffixed with the name of the specific layer (e.g.
                     <filename>LAYERVERSION_mylayer</filename>).</para>
@@ -1810,7 +1897,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     failure, which gives the developer an opportunity to review any
                     license change.</para>
                 <para>
-                    This variable must be defined for all recipes (unless <filename>LICENSE</filename>
+                    This variable must be defined for all recipes (unless
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>
                     is set to "CLOSED")</para>
                 <para>For more information, see the
                     <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
@@ -1891,8 +1979,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     the <filename>LINUX_KERNEL_TYPE</filename> variable
                     defines the search
                     arguments used by the kernel tools to find the appropriate
-                    description within the kernel Metadata with which to build
-                    out the sources and configuration.
+                    description within the kernel
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    with which to build out the sources and configuration.
                     </para>
             </glossdef>
         </glossentry>
@@ -1902,7 +1991,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>The Linux version from <filename>kernel.org</filename>
                     on which the Linux kernel image being built using the
                     OpenEmbedded build system is based.
-                    You define this varible in the kernel recipe.
+                    You define this variable in the kernel recipe.
                     For example, the <filename>linux-yocto-3.4.bb</filename>
                     kernel recipe found in
                     <filename>meta/recipes-kernel/linux</filename>
@@ -2096,8 +2185,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     In other words, the image will not build if a file in this list is not found.
                 </para>
                 <para>
-                    An example is a machine that has WiFi capability but is not essential
-                    For the machine to boot the image.
+                    An example is a machine that has WiFi capability but is not
+                    essential for the machine to boot the image.
                     However, if you are building a more fully-featured image, you want to enable
                     the WiFi.
                     The package containing the firmware for the WiFi hardware is always
@@ -2185,7 +2274,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     It is not intended to be user-configurable.
                     It is best to just reference the variable to see which machine features are
                     being backfilled for all machine configurations.
-                    See the <link linkend='ref-features-backfill'>Feature backfilling</link> section for
+                    See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
                     more information.
                 </para>
             </glossdef>
@@ -2198,7 +2287,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     that should not be backfilled (i.e. added to
                     <filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>)
                     during the build.
-                    See the <link linkend='ref-features-backfill'>Feature backfilling</link> section for
+                    See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
                     more information.
                     </para>
             </glossdef>
@@ -2240,7 +2329,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     Specifies a prefix has been added to
                     <link linkend='var-PN'><filename>PN</filename></link> to create a special version
-                    of a recipe or package, such as a multilib version.
+                    of a recipe or package, such as a Multilib version.
                     The variable is used in places where the prefix needs to be
                     added to or removed from a the name (e.g. the
                     <link linkend='var-BPN'><filename>BPN</filename></link> variable).
@@ -2322,8 +2411,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             <glossdef>
                 <para>Enables easily adding packages to
                 <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
-                before <filename>${PN}</filename> so that the packages can pick
-                up files that would normally be included in the default package.</para>
+                before <filename>${<link linkend='var-PN'>PN</link>}</filename>
+                so that the packages can pick up files that would normally be
+                included in the default package.</para>
             </glossdef>
         </glossentry>
 
@@ -2434,18 +2524,22 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     does not actually satisfy the dependencies, it only states that
                     they should be satisfied.
                     For example, if a hard, runtime dependency
-                    (<filename>RDEPENDS</filename>) of another package is satisfied
+                    (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
+                    of another package is satisfied
                     at build time through the <filename>PACKAGES_DYNAMIC</filename>
                     variable, but a package with the module name is never actually
                     produced, then the other package will be broken.
                     Thus, if you attempt to include that package in an image,
                     you will get a dependency failure from the packaging system
                     during <filename>do_rootfs</filename>.
+                </para>
+                <para>
                     Typically, if there is a chance that such a situation can
                     occur and the package that is not created is valid
                     without the dependency being satisfied, then you should use
-                    <filename>RRECOMMENDS</filename> (a soft runtime dependency)
-                    instead of <filename>RDEPENDS</filename>.
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
+                    (a soft runtime dependency) instead of
+                    <filename>RDEPENDS</filename>.
                 </para>
 
                 <para>
@@ -2475,7 +2569,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <filename>bash-4.2-r1/</filename>).
                     This variable is comprised of the following:
                     <literallayout class='monospaced'>
-     ${PN}-${EXTENDPE}${PV}-${PR}
+     ${<link linkend='var-PN'>PN</link>}-${<link linkend='var-EXTENDPE'>EXTENDPE</link>}${<link linkend='var-PV'>PV</link>}-${<link linkend='var-PR'>PR</link>}
                     </literallayout></para>
             </glossdef>
         </glossentry>
@@ -2559,8 +2653,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-PRINC'><glossterm>PRINC</glossterm>
             <glossdef>
-                <para>Causes the <filename>PR</filename> variable of
-                    <filename>.bbappend</filename> files to dynamically increment.
+                <para>Causes the <link linkend='var-PR'><filename>PR</filename></link>
+                    variable of <filename>.bbappend</filename> files to
+                    dynamically increment.
                     This increment minimizes the impact of layer ordering.</para>
                 <para>In order to ensure multiple <filename>.bbappend</filename> files can co-exist,
                     <filename>PRINC</filename> should be self referencing.
@@ -2569,9 +2664,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <literallayout class='monospaced'>
      PRINC := "${@int(PRINC) + 2}"
                     </literallayout>
-                    It is adviseable not to use strings such as ".= '.1'" with the variable because
+                    It is advisable not to use strings such as ".= '.1'" with the variable because
                     this usage is very sensitive to layer ordering.
-                    Explicit assignments should be avoided as they cannot adequately represent multiple
+                    You should avoid explicit assignments as they cannot
+                    adequately represent multiple
                     <filename>.bbappend</filename> files.</para>
             </glossdef>
         </glossentry>
@@ -2606,10 +2702,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     If multiple recipes provide an item, this variable
                     determines which recipe should be given preference.
-                    The variable must always be suffixed with the name of the
-                    provided item, and should be set to the
-                    <filename>PN</filename> of the recipe
-                    to which you want to give precedence.
+                    You should always suffix the variable with the name of the
+                    provided item, and you should set it to the
+                    <link linkend='var-PN'><filename>PN</filename></link>
+                    of the recipe to which you want to give precedence.
                     Here is an example:
                     <literallayout class='monospaced'>
      PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
@@ -2623,9 +2719,11 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     If there are multiple versions of recipes available, this
                     variable determines which recipe should be given preference.
-                    The variable must always be suffixed with the <filename>PN</filename>
-                    for which to select, and should be set to the
-                    <filename>PV</filename> to which you want to give precedence.
+                    You must always suffix the variable with the
+                    <link linkend='var-PN'><filename>PN</filename></link>
+                    you want to select, and you should set to the
+                    <link linkend='var-PV'><filename>PV</filename></link>
+                    accordingly for precedence.
                     You can use the "<filename>%</filename>" character as a wildcard
                     to match any number of characters, which can be useful when
                     specifying versions that contain long revision number that could
@@ -2648,7 +2746,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-RCONFLICTS'><glossterm>RCONFLICTS</glossterm>
             <glossdef>
-                <para>The list of packages that conflict with a package.
+                <para>The list of packages that conflict with another package.
                     Note that the package will not be installed if the conflicting packages are not
                     first removed.</para>
                 <para>
@@ -2679,7 +2777,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     packages as listed in the
                     <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
                     variable.
-                    You should not list recipe names (<filename>PN</filename>).
+                    You should not list recipe names
+                    (<link linkend='var-PN'><filename>PN</filename></link>).
                 </para>
 
                 <para>
@@ -2729,7 +2828,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
             <glossdef>
                 <para>
-                    A list of packages that extend the usability of a package being
+                    A list of packages that extends the usability of a package being
                     built.
                     The package being built does not depend on this list of packages in
                     order to successfully build, but needs them for the extended usability.
@@ -2754,8 +2853,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <literallayout class='monospaced'>
      RRECOMMENDS_${PN}-dev += "&lt;wireless_package_name&gt;"
                     </literallayout>
-                    In the example, the package name (<filename>${PN}-dev</filename>) must
-                    appear as it would in the
+                    In the example, the package name
+                    (<filename>${<link linkend='var-PN'>PN</link>}-dev</filename>)
+                    must appear as it would in the
                     <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> namespace before any
                     renaming of the output package by classes like <filename>debian.bbclass</filename>.
                 </para>
@@ -2764,7 +2864,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm>
             <glossdef>
-                <para>The list of packages that are replaced with this package.</para>
+                <para>The list of packages replaced by the package in which
+                    <filename>RREPLACES</filename> appears.</para>
             </glossdef>
         </glossentry>
 
@@ -2789,9 +2890,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     </literallayout>
                     As an example, assume a
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> top-level
-                    folder named <filename>poky</filename>
-                    and a default <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-                    at <filename>poky/build</filename>.
+                    folder named <filename>poky</filename> and a default Build
+                    Directory at <filename>poky/build</filename>.
                     In this case, the working directory the build system uses to build
                     the <filename>db</filename> package is the following:
                     <literallayout class='monospaced'>
@@ -2804,9 +2904,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-SDKIMAGE_FEATURES'><glossterm>SDKIMAGE_FEATURES</glossterm>
             <glossdef>
                 <para>Equivalent to
-                <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>.
-                However, this variable applies to the SDK generated from an image using
-                <filename>bitbake -c populate_sdk imagename</filename>).
+                    <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>.
+                    However, this variable applies to the SDK generated from an
+                    image using the following command:
+                    <literallayout class='monospaced'>
+     $ bitbake -c populate_sdk imagename
+                    </literallayout>
                 </para>
             </glossdef>
         </glossentry>
@@ -2875,14 +2978,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     This variable tells the OpenEmbedded build system which bits to pull
                     in for the build and how to pull them in.
                     For example, if the recipe only needs to fetch a tarball from the
-                    internet, the recipe uses a single <filename>SRC_URI</filename> entry.
+                    Internet, the recipe uses a single <filename>SRC_URI</filename> entry.
                     On the other hand, if the recipe needs to fetch a tarball, apply
                     two patches, and include a custom file, the recipe would include four
                     instances of the variable.</para>
                 <para>The following list explains the available URI protocols:
                     <itemizedlist>
                         <listitem><para><emphasis><filename>file://</filename> -</emphasis> Fetches files, which is usually
-                            a file shipped with the metadata, from the local machine.
+                            a file shipped with the
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+                            from the local machine.
                             The path is relative to the
                             <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
                             variable.
@@ -2895,11 +3000,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                                     For example, using <filename>bash</filename> to build for the native
                                     machine, <filename>PN</filename> is <filename>bash-native</filename>.
                                     Using <filename>bash</filename> to build for the target and for Multilib,
-                                    <filename>PN</filename> would be <filename>bash</filename> and
+                                    <link linkend='var-PN'><filename>PN</filename></link>
+                                    would be <filename>bash</filename> and
                                     <filename>lib64-bash</filename>, respectively.
                                     </para></listitem>
                                 <listitem><para><emphasis><filename>${PF}</filename> - </emphasis>
-                                    <filename>${PN}-${EXTENDPE}${PV}-${PR}</filename>.
+                                    <filename>${PN}-${EXTENDPE}${<link linkend='var-PV'>PV</link>}-${<link linkend='var-PR'>PR</link>}</filename>.
                                     The recipe name including all version and revision numbers
                                     (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
                                     <filename>bash-4.2-r1/</filename>).</para></listitem>
@@ -2911,7 +3017,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                                     base recipe name without any special suffix or version numbers.
                                     </para></listitem>
                                 <listitem><para><emphasis><filename>${BP}</filename> -</emphasis>
-                                    <filename>${BPN}-${PV}</filename>.
+                                    <filename>${<link linkend='var-BPN'>BPN</link>}-${PV}</filename>.
                                     The base recipe name and version but without any special
                                     package name suffix.</para></listitem>
                                 <listitem><para><emphasis>Files -</emphasis> Files beneath the directory in which the recipe
@@ -2924,7 +3030,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                         <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
                             Git revision control repository.</para></listitem>
                         <listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from
-                            an OSC (OpenSuse Build service) revision control repository.</para></listitem>
+                            an OSC (OpenSUSE Build service) revision control repository.</para></listitem>
                         <listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from
                             a repo (Git) repository.</para></listitem>
                         <listitem><para><emphasis><filename>svk://</filename> -</emphasis> Fetches files from
@@ -2960,36 +3066,43 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 </para>
                 <para>Here are options specific to recipes building code from a revision control system:
                     <itemizedlist>
-                        <listitem><para><emphasis><filename>mindate</filename> -</emphasis> Only applies
-                            the patch if <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
-                            is equal to or greater than <filename>mindate</filename>.</para></listitem>
-                        <listitem><para><emphasis><filename>maxdate</filename> -</emphasis> Only applies
-                            the patch if <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
-                            is not later than <filename>mindate</filename>.</para></listitem>
-                        <listitem><para><emphasis><filename>minrev</filename> -</emphasis> Only applies
-                            the patch if <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
-                            is equal to or greater than <filename>minrev</filename>.</para></listitem>
-                        <listitem><para><emphasis><filename>maxrev</filename> -</emphasis> Only applies
-                            the patch if <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
-                            is not later than <filename>maxrev</filename>.</para></listitem>
-                        <listitem><para><emphasis><filename>rev</filename> -</emphasis> Only applies the
-                            patch if <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
-                            is equal to <filename>rev</filename>.</para></listitem>
-                        <listitem><para><emphasis><filename>notrev</filename> -</emphasis> Only applies
-                            the patch if <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
-                            is not equal to <filename>rev</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>mindate</filename> -</emphasis>
+                            Apply the patch only if
+                            <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
+                            is equal to or greater than <filename>mindate</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>maxdate</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCDATE</filename>
+                            is not later than <filename>mindate</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>minrev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is equal to or greater than <filename>minrev</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>maxrev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is not later than <filename>maxrev</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>rev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is equal to <filename>rev</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>notrev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is not equal to <filename>rev</filename>.
+                            </para></listitem>
                     </itemizedlist>
                 </para>
                 <para>Here are some additional options worth mentioning:
                     <itemizedlist>
                         <listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls
                             whether or not to unpack the file if it is an archive.
-                            The default action is to upack the file.</para></listitem>
+                            The default action is to unpack the file.</para></listitem>
                         <listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
                             (or extracts its contents) into the specified
                             subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
                             This option is useful for unusual tarballs or other archives that
-                            don't have their files already in a subdirectory within the archive.
+                            do not have their files already in a subdirectory within the archive.
                             </para></listitem>
                         <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a
                             name to be used for association with <filename>SRC_URI</filename> checksums
@@ -3075,7 +3188,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-SSTATE_DIR'><glossterm>SSTATE_DIR</glossterm>
             <glossdef>
-                <para>The directory for the shared state.</para>
+                <para>The directory for the shared state cache.</para>
             </glossdef>
         </glossentry>
 
@@ -3086,7 +3199,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     mirror locations for prebuilt cache data objects before
                     building out the data.
                     This variable works like fetcher
-                    <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>/<link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
+                    <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+                    and <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
                     and points to the cache locations to check for the shared
                     objects.
                 </para>
@@ -3105,7 +3219,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
                     you need to add
                     "PATH" at the end as shown in the examples below.
-                    The build system substitues the correct path within the
+                    The build system substitutes the correct path within the
                     directory structure.
                     <literallayout class='monospaced'>
      SSTATE_MIRRORS ?= "\
@@ -3167,18 +3281,18 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-T'><glossterm>T</glossterm>
             <glossdef>
-                <para>This variable points to a directory were Bitbake places temporary
+                <para>This variable points to a directory were BitBake places temporary
                     files when building a particular package.
                     It is typically set as follows:
                     <literallayout class='monospaced'>
      T = ${WORKDIR}/temp
                     </literallayout>
                     The <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
-                    is the directory into which Bitbake unpacks and builds the package.
+                    is the directory into which BitBake unpacks and builds the package.
                     The default <filename>bitbake.conf</filename> file sets this variable.</para>
                     <para>The <filename>T</filename> variable is not to be confused with
                     the <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> variable,
-                    which points to the root of the directory tree where Bitbake
+                    which points to the root of the directory tree where BitBake
                     places the output of an entire build.
                 </para>
             </glossdef>
@@ -3187,8 +3301,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm>
             <glossdef>
                 <para>The architecture of the device being built.
-                While a number of values are possible, the OpenEmbedded build system primarily supports
-                <filename>arm</filename> and <filename>i586</filename>.</para>
+                    The OpenEmbedded build system supports the following
+                    architectures:
+                    <literallayout class='monospaced'>
+     arm
+     mips
+     ppc
+     x86
+     x86-64
+                    </literallayout>
+                </para>
             </glossdef>
         </glossentry>
 

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>

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,7 +368,9 @@
             </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.
@@ -399,7 +406,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 +491,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 +531,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 +561,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 +580,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 +602,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 +632,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 +639,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 +654,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 +662,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 +677,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'>
@@ -773,7 +756,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 +878,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 +992,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 +1016,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.
@@ -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'>

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

@@ -10,7 +10,7 @@ MACHINE_FEATURES = "screen keyboard pci usbhost ext2 ext3 x86 wifi acpi alsa"
 KERNEL_IMAGETYPE = "bzImage"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "3.4%"
+PREFERRED_VERSION_linux-yocto ?= "3.8%"
 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 XSERVER ?= "xserver-xorg \
            xserver-xorg-extension-glx \
@@ -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

@@ -8,6 +8,7 @@ MACHINE_FEATURES = "screen keyboard pci usbhost ext2 ext3 serial"
 
 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/conf/conf-notes.txt

@@ -0,0 +1,9 @@
+Common targets are:
+    core-image-minimal
+    core-image-sato
+    meta-toolchain
+    meta-toolchain-sdk
+    adt-installer
+    meta-ide-support
+
+You can also run generated qemu images with a command like 'runqemu qemux86'

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

@@ -48,6 +48,7 @@ REGEX_URI_pn-nativesdk-db = "http://www.oracle.com/technetwork/products/berkeley
 REGEX_pn-nativesdk-db = "[hH][rR][eE][fF]=\"http://download.oracle.com/otn/berkeley-db/db-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz\""
 REGEX_URI_pn-e2fsprogs = "http://sourceforge.net/projects/e2fsprogs/files/e2fsprogs/"
 REGEX_pn-e2fsprogs = "[hH][rR][eE][fF]=\"/projects/e2fsprogs/files/e2fsprogs/v(?P<pver>((\d+[\.\-_]*)+))/\""
+REGEX_pn-elfutils = "[hH][rR][eE][fF]=\"(elfutils\-)?(?P<pver>((\d+[\.\-_]*)+))(/|\.tar\.bz2)\""
 REGEX_URI_pn-expat = "http://sourceforge.net/projects/expat/files/expat/"
 REGEX_pn-expat-native = "[hH][rR][eE][fF]=\"/projects/expat/files/expat/(?P<pver>((\d+[\.\-_]*)+))/\""
 REGEX_URI_pn-expat-native = "http://sourceforge.net/projects/expat/files/expat/"
@@ -59,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/"
@@ -83,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\""
@@ -104,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/"
@@ -127,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"
@@ -135,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"
@@ -163,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-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,8 +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 (Yocto Project 1.4 Reference Distro)"
+DISTRO_VERSION = "1.4"
+DISTRO_CODENAME = "dylan"
 SDK_VENDOR = "-pokysdk"
-SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
+SDK_VERSION := "${@'${DISTRO_VERSION}'}"
 
 MAINTAINER = "Poky <poky@yoctoproject.org>"
 
@@ -11,7 +12,7 @@ TARGET_VENDOR = "-poky"
 LOCALCONF_VERSION = "1"
 LAYER_CONF_VERSION ?= "6"
 
-DISTRO_FEATURES_append = " largefile opengl multiarch"
+DISTRO_FEATURES_append = " largefile opengl multiarch wayland"
 
 PREFERRED_VERSION_linux-yocto ?= "3.4%"
 PREFERRED_VERSION_linux-yocto_qemux86 ?= "3.8%"
@@ -44,7 +45,7 @@ TCLIBCAPPEND = ""
 QEMU_TARGETS ?= "arm i386 mips mipsel ppc x86_64"
 # Other QEMU_TARGETS "mips64 mips64el sh4"
 
-PREMIRRORS ?= "\
+PREMIRRORS ??= "\
 bzr://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
 cvs://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
 git://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
@@ -69,6 +70,7 @@ 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 \
@@ -88,6 +90,7 @@ SANITY_TESTED_DISTROS ?= " \
             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-yocto/conf/local.conf.sample.extended

@@ -211,7 +211,3 @@
 # Put the following two lines in the conf file with intact.
 #ARCHIVER_CLASS = "${@'archive-${ARCHIVER_MODE}-source' if ARCHIVER_MODE != 'none' else ''}"
 #INHERIT += "${ARCHIVER_CLASS}"
-#
-# set init manager: sysvinit or systemd
-# sysvinit is the default choice
-#DISTRO_FEATURES_INITMAN ?= "sysvinit"

meta/classes/archive-configured-source.bbclass

@@ -24,24 +24,17 @@ python () {
         return
 
     d.appendVarFlag('do_dumpdata_create_diff_gz', 'depends', ' %s:do_package_write_' %pn + packaging)
+    build_deps = ' %s:do_dumpdata_create_diff_gz' %pn
 
-    if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True) != 'srpm':
-        """
-        If package type is not 'srpm' then add tasks to move archive packages of
-        configured sources and scripts/logs in ${DEPLOY_DIR}/sources.
-        """
+    if d.getVar('SOURCE_ARCHIVE_LOG_WITH_SCRIPTS', True) == 'logs_with_scripts':
+        d.appendVarFlag('do_archive_scripts_logs', 'depends', ' %s:do_package_write_' %pn + packaging)
+        build_deps += ' %s:do_archive_scripts_logs' %pn
+
+    if not not_tarball(d):
         d.appendVarFlag('do_compile', 'depends', ' %s:do_archive_configured_sources' %pn)
-        build_deps = ' %s:do_dumpdata_create_diff_gz' %pn
-        if not not_tarball(d):
-            build_deps += ' %s:do_archive_configured_sources' %pn
-        if d.getVar('SOURCE_ARCHIVE_LOG_WITH_SCRIPTS', True) == 'logs_with_scripts':
-            build_deps += ' %s:do_archive_scripts_logs' %pn
-            d.appendVarFlag('do_archive_scripts_logs', 'depends', ' %s:do_package_write_' %pn + packaging)
-        d.appendVarFlag('do_build', 'depends', build_deps)
+        build_deps += ' %s:do_archive_configured_sources' %pn
 
-    else:
-        d.prependVarFlag('do_configure', 'postfuncs', "do_archive_configured_sources")
-        d.prependVarFlag('do_package_write_rpm', 'prefuncs', "do_archive_scripts_logs")
+    d.appendVarFlag('do_build', 'depends', build_deps)
 }
 
 ARCHIVE_SSTATE_OUTDIR = "${DEPLOY_DIR}/sources/"

meta/classes/archive-original-source.bbclass

@@ -24,24 +24,17 @@ python () {
         return
 
     d.appendVarFlag('do_dumpdata_create_diff_gz', 'depends', ' %s:do_package_write_' %pn + packaging)
+    build_deps = ' %s:do_dumpdata_create_diff_gz' %pn
 
-    if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True) != 'srpm':
-        """
-        If package type is not 'srpm' then add tasks to move archive packages of
-        original sources and scripts/logs in ${DEPLOY_DIR}/sources.
-        """
+    if d.getVar('SOURCE_ARCHIVE_LOG_WITH_SCRIPTS', True) == 'logs_with_scripts':
+        d.appendVarFlag('do_archive_scripts_logs', 'depends', ' %s:do_package_write_' %pn + packaging)
+        build_deps += ' %s:do_archive_scripts_logs' %pn
+
+    if not not_tarball(d):
         d.appendVarFlag('do_patch', 'depends', ' %s:do_archive_original_sources_patches' %pn)
-        build_deps = ' %s:do_dumpdata_create_diff_gz' %pn
-        if not not_tarball(d):
-            build_deps += ' %s:do_archive_original_sources_patches' %pn
-        if d.getVar('SOURCE_ARCHIVE_LOG_WITH_SCRIPTS', True) == 'logs_with_scripts':
-            build_deps += ' %s:do_archive_scripts_logs' %pn
-            d.appendVarFlag('do_archive_scripts_logs', 'depends', ' %s:do_package_write_' %pn + packaging)
-        d.appendVarFlag('do_build', 'depends', build_deps)
+        build_deps += ' %s:do_archive_original_sources_patches' %pn
 
-    else:
-        d.prependVarFlag('do_unpack', 'postfuncs', "do_archive_original_sources_patches")
-        d.prependVarFlag('do_package_write_rpm', 'prefuncs', "do_archive_scripts_logs")
+    d.appendVarFlag('do_build', 'depends', build_deps)
 }
 
 ARCHIVE_SSTATE_OUTDIR = "${DEPLOY_DIR}/sources/"

meta/classes/archive-patched-source.bbclass

@@ -24,24 +24,17 @@ python () {
         return
 
     d.appendVarFlag('do_dumpdata_create_diff_gz', 'depends', ' %s:do_package_write_' %pn + packaging)
+    build_deps = ' %s:do_dumpdata_create_diff_gz' %pn
 
-    if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True) != 'srpm':
-        """
-        If package type is not 'srpm' then add tasks to move archive packages of
-        patched sources and scripts/logs in ${DEPLOY_DIR}/sources.
-        """
+    if d.getVar('SOURCE_ARCHIVE_LOG_WITH_SCRIPTS', True) == 'logs_with_scripts':
+        d.appendVarFlag('do_archive_scripts_logs', 'depends', ' %s:do_package_write_' %pn + packaging)
+        build_deps += ' %s:do_archive_scripts_logs' %pn
+
+    if not not_tarball(d):
         d.appendVarFlag('do_configure', 'depends', ' %s:do_archive_patched_sources' %pn)
-        build_deps = ' %s:do_dumpdata_create_diff_gz' %pn
-        if not not_tarball(d):
-            build_deps += ' %s:do_archive_patched_sources' %pn
-        if d.getVar('SOURCE_ARCHIVE_LOG_WITH_SCRIPTS', True) == 'logs_with_scripts':
-            build_deps += ' %s:do_archive_scripts_logs' %pn
-            d.appendVarFlag('do_archive_scripts_logs', 'depends', ' %s:do_package_write_' %pn + packaging)
-        d.appendVarFlag('do_build', 'depends', build_deps)
+        build_deps += ' %s:do_archive_patched_sources' %pn
 
-    else:
-        d.prependVarFlag('do_patch', 'postfuncs', "do_archive_patched_sources")
-        d.prependVarFlag('do_package_write_rpm', 'prefuncs', "do_archive_scripts_logs")
+    d.appendVarFlag('do_build', 'depends', build_deps)
 }
 
 ARCHIVE_SSTATE_OUTDIR = "${DEPLOY_DIR}/sources/"

meta/classes/archiver.bbclass

@@ -440,10 +440,6 @@ def archive_scripts_logs(d):
     tarlog = archive_logs(d, logdir, True)
 
     if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True) == 'srpm':
-        if os.path.exists(work_dir+ '/' + tarlog):
-            os.remove(work_dir+ '/' + tarlog)
-        shutil.move(os.path.join(logdir, '..', tarlog), work_dir)
-        shutil.rmtree(os.path.join(work_dir,'script-logs'))
         store_package(d, tarlog)
 
 def dumpdata(d):

meta/classes/base.bbclass

@@ -162,7 +162,7 @@ def preferred_ml_updates(d):
             providers.append(v)
 
     for pkg, reason in blacklists.items():
-        if pkg.endswith(("-native", "-crosssdk")) or pkg.startswith("nativesdk-") or 'cross-canadian' in pkg:
+        if pkg.endswith(("-native", "-crosssdk")) or pkg.startswith(("nativesdk-", "virtual/nativesdk-")) or 'cross-canadian' in pkg:
             continue
         for p in prefixes:
             newpkg = p + "-" + pkg
@@ -172,7 +172,7 @@ def preferred_ml_updates(d):
     for v in versions:
         val = d.getVar(v, False)
         pkg = v.replace("PREFERRED_VERSION_", "")
-        if pkg.endswith(("-native", "-crosssdk")) or pkg.startswith("nativesdk-"):
+        if pkg.endswith(("-native", "-crosssdk")) or pkg.startswith(("nativesdk-", "virtual/nativesdk-")):
             continue
         if 'cross-canadian' in pkg:
             for p in prefixes:
@@ -182,8 +182,12 @@ def preferred_ml_updates(d):
                 bb.data.update_data(localdata)
                 newname = localdata.expand(v)
                 if newname != v:
-                    newval = localdata.getVar(v, True)
+                    newval = localdata.expand(val)
                     d.setVar(newname, newval)
+            # Avoid future variable key expansion
+            vexp = d.expand(v)
+            if v != vexp and d.getVar(v, False):
+                d.renameVar(v, vexp)
             continue
         for p in prefixes:
             newname = "PREFERRED_VERSION_" + p + "-" + pkg
@@ -193,7 +197,7 @@ def preferred_ml_updates(d):
     for prov in providers:
         val = d.getVar(prov, False)
         pkg = prov.replace("PREFERRED_PROVIDER_", "")
-        if pkg.endswith(("-native", "-crosssdk")) or pkg.startswith("nativesdk-"):
+        if pkg.endswith(("-native", "-crosssdk")) or pkg.startswith(("nativesdk-", "virtual/nativesdk-")):
             continue
         if 'cross-canadian' in pkg:
             for p in prefixes:
@@ -205,6 +209,10 @@ def preferred_ml_updates(d):
                 if newname != prov:
                     newval = localdata.expand(val)
                     d.setVar(newname, newval)
+            # Avoid future variable key expansion
+            provexp = d.expand(prov)
+            if prov != provexp and d.getVar(prov, False):
+                d.renameVar(prov, provexp)
             continue
         virt = ""
         if pkg.startswith("virtual/"):
@@ -220,19 +228,23 @@ def preferred_ml_updates(d):
             localdata.setVar("OVERRIDES", localdata.getVar("OVERRIDES", False) + override)
             bb.data.update_data(localdata)
             newname = localdata.expand(prov)
-            if newname != prov:
+            if newname != prov and not d.getVar(newname, False):
                 d.setVar(newname, localdata.expand(val))
 
             # implement alternative multilib name
             newname = localdata.expand("PREFERRED_PROVIDER_" + virt + p + "-" + pkg)
             if not d.getVar(newname, False):
                 d.setVar(newname, val)
+        # Avoid future variable key expansion
+        provexp = d.expand(prov)
+        if prov != provexp and d.getVar(prov, False):
+            d.renameVar(prov, provexp)
 
 
     mp = (d.getVar("MULTI_PROVIDER_WHITELIST", True) or "").split()
     extramp = []
     for p in mp:
-        if p.endswith(("-native", "-crosssdk")) or p.startswith("nativesdk-") or 'cross-canadian' in p:
+        if p.endswith(("-native", "-crosssdk")) or p.startswith(("nativesdk-", "virtual/nativesdk-")) or 'cross-canadian' in p:
             continue
         virt = ""
         if p.startswith("virtual/"):
@@ -489,6 +501,8 @@ python () {
         d.setVarFlag('do_package', 'fakeroot', 1)
         d.setVarFlag('do_package', 'umask', 022)
         d.setVarFlag('do_package_setscene', 'fakeroot', 1)
+        d.setVarFlag('do_devshell', 'fakeroot', 1)
+        d.appendVarFlag('do_devshell', 'depends', ' virtual/fakeroot-native:do_populate_sysroot')
     source_mirror_fetch = d.getVar('SOURCE_MIRROR_FETCH', 0)
     if not source_mirror_fetch:
         need_host = d.getVar('COMPATIBLE_HOST', True)
@@ -501,11 +515,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/buildhistory.bbclass

@@ -259,12 +259,6 @@ def write_recipehistory(rcpinfo, d):
         f.write("DEPENDS = %s\n" %  rcpinfo.depends)
         f.write("PACKAGES = %s\n" %  rcpinfo.packages)
 
-    if rcpinfo.srcrev:
-        srcrevfile = os.path.join(pkghistdir, "latest_srcrev")
-        with open(srcrevfile, "w") as f:
-            f.write(','.join([rcpinfo.bbfile, rcpinfo.src_uri, rcpinfo.srcrev,
-                        rcpinfo.srcrev_autorev]))
-
 
 def write_pkghistory(pkginfo, d):
     bb.debug(2, "Writing package history for package %s" % pkginfo.name)
@@ -439,8 +433,9 @@ ROOTFS_POSTPROCESS_COMMAND =+ "buildhistory_get_image_installed ; "
 
 IMAGE_POSTPROCESS_COMMAND += " buildhistory_get_imageinfo ; "
 
-POPULATE_SDK_POST_TARGET_COMMAND += "buildhistory_get_sdk_installed target ; "
-POPULATE_SDK_POST_HOST_COMMAND += "buildhistory_get_sdk_installed host ; "
+# We want these to be the last run so that we get called after complementary package installation
+POPULATE_SDK_POST_TARGET_COMMAND_append = "buildhistory_get_sdk_installed target ; "
+POPULATE_SDK_POST_HOST_COMMAND_append = "buildhistory_get_sdk_installed host ; "
 
 SDK_POSTPROCESS_COMMAND += "buildhistory_get_sdkinfo ; "
 
@@ -527,3 +522,75 @@ python buildhistory_eventhandler() {
 }
 
 addhandler buildhistory_eventhandler
+
+
+# FIXME this ought to be moved into the fetcher
+def _get_srcrev_values(d):
+    """
+    Return the version strings for the current recipe
+    """
+
+    scms = []
+    fetcher = bb.fetch.Fetch(d.getVar('SRC_URI', True).split(), d)
+    urldata = fetcher.ud
+    for u in urldata:
+        if urldata[u].method.supports_srcrev():
+            scms.append(u)
+
+    autoinc_templ = 'AUTOINC+'
+    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_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)
+
+do_fetch[postfuncs] += "write_srcrev"
+python write_srcrev() {
+    pkghistdir = d.getVar('BUILDHISTORY_DIR_PACKAGE', True)
+    srcrevfile = os.path.join(pkghistdir, 'latest_srcrev')
+
+    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':
+                f.write('# SRCREV = "%s"\n' % orig_srcrev)
+            if len(srcrevs) > 1:
+                for name, srcrev in srcrevs.items():
+                    orig_srcrev = d.getVar('SRCREV_%s' % name, False)
+                    if orig_srcrev:
+                        f.write('# SRCREV_%s = "%s"\n' % (name, orig_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)
+}

meta/classes/fontcache.bbclass

@@ -15,7 +15,8 @@ FONT_PACKAGES ??= "${PN}"
 #
 fontcache_common() {
 if [ "x$D" != "x" ] ; then
-	$INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} bindir=${bindir}
+	$INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} bindir=${bindir} \
+		libdir=${libdir} base_libdir=${base_libdir}
 	exit 1
 fi
 

meta/classes/gtk-icon-cache.bbclass

@@ -1,6 +1,6 @@
 FILES_${PN} += "${datadir}/icons/hicolor"
 
-DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} virtual/gtk-update-icon-cache-native"
+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
@@ -9,7 +9,8 @@ DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} vir
 #
 gtk_icon_cache_postinst() {
 if [ "x$D" != "x" ]; then
-    $INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG}
+    $INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} libdir=${libdir} \
+        base_libdir=${base_libdir}
     exit 1
 fi
 
@@ -25,7 +26,9 @@ done
 
 gtk_icon_cache_postrm() {
 if [ "x$D" != "x" ]; then
-    $INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG}
+    $INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} libdir=${libdir} \
+        base_libdir=${base_libdir}
+
     exit 1
 fi
 

meta/classes/image.bbclass

@@ -186,7 +186,7 @@ run_intercept_scriptlets () {
 			[ "$script" = "*" ] && break
 			[ "$script" = "postinst_intercept" ] || [ ! -x "$script" ] && continue
 			echo "> Executing $script"
-			./$script || (echo "WARNING: intercept script \"$script\" failed, falling back to running postinstalls at first boot" && continue)
+			./$script || { echo "WARNING: intercept script \"$script\" failed, falling back to running postinstalls at first boot" && continue; };
 			#
 			# If we got here, than the intercept was successful. Next, we must
 			# mark the postinstalls as "installed". For rpm is a little bit

meta/classes/image_types.bbclass

@@ -171,7 +171,7 @@ IMAGE_CMD_btrfs () {
 }
 
 IMAGE_CMD_squashfs = "mksquashfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs ${EXTRA_IMAGECMD} -noappend"
-IMAGE_CMD_squashfs-lzma = "mksquashfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs-lzma ${EXTRA_IMAGECMD} -noappend -comp lzma"
+IMAGE_CMD_squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs-xz ${EXTRA_IMAGECMD} -noappend -comp xz"
 IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar ."
 
 CPIO_TOUCH_INIT () {
@@ -230,13 +230,13 @@ IMAGE_DEPENDS_ext3 = "genext2fs-native e2fsprogs-native"
 IMAGE_DEPENDS_ext4 = "genext2fs-native e2fsprogs-native"
 IMAGE_DEPENDS_btrfs = "btrfs-tools-native"
 IMAGE_DEPENDS_squashfs = "squashfs-tools-native"
-IMAGE_DEPENDS_squashfs-lzma = "squashfs-tools-native"
+IMAGE_DEPENDS_squashfs-xz = "squashfs-tools-native"
 IMAGE_DEPENDS_elf = "virtual/kernel mkelfimage-native"
 IMAGE_DEPENDS_ubi = "mtd-utils-native"
 IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 
 # This variable is available to request which values are suitable for IMAGE_FSTYPES
-IMAGE_TYPES = "jffs2 sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 ext3.gz ext2.lzma btrfs live squashfs squashfs-lzma ubi tar tar.gz tar.bz2 tar.xz cpio cpio.gz cpio.xz cpio.lzma vmdk elf"
+IMAGE_TYPES = "jffs2 sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 ext3.gz ext2.lzma btrfs live squashfs squashfs-xz ubi tar tar.gz tar.bz2 tar.xz cpio cpio.gz cpio.xz cpio.lzma vmdk elf"
 
 COMPRESSIONTYPES = "gz bz2 lzma xz"
 COMPRESS_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}.rootfs.${type}"

meta/classes/insane.bbclass

@@ -60,6 +60,8 @@ def package_qa_get_machine_dict():
                         "s390":       (22,     0,    0,          False,         32),
                         "sh4":        (42,     0,    0,          True,          32),
                         "sparc":      ( 2,     0,    0,          False,         32),
+                        "microblaze":  (189,   0,    0,          False,         32),
+                        "microblazeel":(189,   0,    0,          True,          32),
                       },
             "linux-uclibc" : { 
                         "arm" :       (  40,    97,    0,          True,          32),
@@ -97,8 +99,6 @@ def package_qa_get_machine_dict():
                       },
             "linux-gnu" :       {
                         "powerpc":    (20,     0,    0,          False,         32),
-                        "microblaze":   (47787,  0,    0,          False,         32),
-                        "microblazeel": (47787,  0,    0,          True,          32),
                         "sh4":        (42,     0,    0,          True,          32),
                       },
             "linux-gnux32" :       {
@@ -216,7 +216,7 @@ def package_qa_check_dev(path, name, d, elf, messages):
     Check for ".so" library symlinks in non-dev packages
     """
 
-    if not name.endswith("-dev") and not name.endswith("-dbg") and not name.startswith("nativesdk-") and path.endswith(".so") and os.path.islink(path):
+    if not name.endswith("-dev") and not name.endswith("-dbg") and not name.endswith("-ptest") and not name.startswith("nativesdk-") and path.endswith(".so") and os.path.islink(path):
         messages.append("non -dev/-dbg/-nativesdk package contains symlink .so: %s path '%s'" % \
                  (name, package_qa_clean_path(path,d)))
 
@@ -229,7 +229,7 @@ def package_qa_check_staticdev(path, name, d, elf, messages):
     libgcc.a, libgcov.a will be skipped in their packages
     """
 
-    if not name.endswith("-pic") and not name.endswith("-staticdev") and path.endswith(".a") and not path.endswith("_nonshared.a"):
+    if not name.endswith("-pic") and not name.endswith("-staticdev") and not name.endswith("-ptest") and path.endswith(".a") and not path.endswith("_nonshared.a"):
         messages.append("non -staticdev package contains static .a library: %s path '%s'" % \
                  (name, package_qa_clean_path(path,d)))
 
@@ -273,7 +273,7 @@ def package_qa_check_dbg(path, name, d, elf, messages):
     Check for ".debug" files or directories outside of the dbg package
     """
 
-    if not "-dbg" in name:
+    if not "-dbg" in name and not "-ptest" in name:
         if '.debug' in path.split(os.path.sep):
             messages.append("non debug package contains .debug directory: %s path %s" % \
                      (name, package_qa_clean_path(path,d)))

meta/classes/kernel-yocto.bbclass

@@ -46,7 +46,7 @@ def find_kernel_feature_dirs(d):
 
 # find the master/machine source branch. In the same way that the fetcher proceses
 # git repositories in the SRC_URI we take the first repo found, first branch.
-def get_machine_branch(d):
+def get_machine_branch(d, default):
     fetch = bb.fetch2.Fetch([], d)
     for url in fetch.urls:
         urldata = fetch.ud[url]
@@ -55,7 +55,7 @@ def get_machine_branch(d):
             branches = urldata.parm.get("branch").split(',')
             return branches[0]
 	    
-    return "master"
+    return default
 
 do_patch() {
 	cd ${S}
@@ -70,7 +70,7 @@ do_patch() {
 		fi
 	fi
 
-	machine_branch="${@ get_machine_branch(d)}"
+	machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
 
 	# if we have a defined/set meta branch we should not be generating
 	# any meta data. The passed branch has what we need.
@@ -195,7 +195,8 @@ do_kernel_checkout() {
 		fi
 	fi
 	
-	machine_branch="${@ get_machine_branch(d)}"
+	machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
+
 	if [ "${KBRANCH}" != "${machine_branch}" ]; then
 		echo "WARNING: The SRC_URI machine branch and KBRANCH are not the same."
 		echo "	       KBRANCH will be adjusted to match, but this typically is a"
@@ -280,7 +281,7 @@ do_validate_branches() {
 	cd ${S}
 	export KMETA=${KMETA}
 
-	machine_branch="${@ get_machine_branch(d)}"
+	machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
 
 	set +e
 	# if SRCREV is AUTOREV it shows up as AUTOINC there's nothing to

meta/classes/kernel.bbclass

@@ -88,7 +88,7 @@ do_compile_kernelmodules() {
 		bbnote "no modules to compile"
 	fi
 }
-addtask compile_kernelmodules after do_compile before do_install
+addtask compile_kernelmodules after do_compile before do_strip
 
 kernel_do_install() {
 	#
@@ -289,19 +289,49 @@ python split_kernel_packages () {
     do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
 }
 
+do_strip() {
+	if [ -n "${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}" ]; then
+		if [[ "${KERNEL_IMAGETYPE}" != "vmlinux" ]]; then
+			bbwarn "image type will not be stripped (not supported): ${KERNEL_IMAGETYPE}"
+			return
+		fi
+
+		cd ${B}
+		headers=`"$CROSS_COMPILE"readelf -S ${KERNEL_OUTPUT} | \
+			  grep "^ \{1,\}\[[0-9 ]\{1,\}\] [^ ]" | \
+			  sed "s/^ \{1,\}\[[0-9 ]\{1,\}\] //" | \
+			  gawk '{print $1}'`
+
+		for str in ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}; do {
+			if [[ "$headers" != *"$str"* ]]; then
+				bbwarn "Section not found: $str";
+			fi
+
+			"$CROSS_COMPILE"strip -s -R $str ${KERNEL_OUTPUT}
+		}; done
+
+		bbnote "KERNEL_IMAGE_STRIP_EXTRA_SECTIONS is set, stripping sections:" \
+			"${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}"
+	fi;
+}
+do_strip[dirs] = "${B}"
+
+addtask do_strip before do_sizecheck after do_kernel_link_vmlinux
+
 # Support checking the kernel size since some kernels need to reside in partitions
 # with a fixed length or there is a limit in transferring the kernel to memory
 do_sizecheck() {
 	if [ ! -z "${KERNEL_IMAGE_MAXSIZE}" ]; then
-		size=`ls -l ${KERNEL_OUTPUT} | awk '{ print $5}'`
+		cd ${B}
+		size=`ls -lL ${KERNEL_OUTPUT} | awk '{ print $5}'`
 		if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
-			rm ${KERNEL_OUTPUT}
 			die "This kernel (size=$size > ${KERNEL_IMAGE_MAXSIZE}) is too big for your device. Please reduce the size of the kernel by making more of it modular."
 		fi
 	fi
 }
+do_sizecheck[dirs] = "${B}"
 
-addtask sizecheck before do_install after do_compile
+addtask sizecheck before do_install after do_strip
 
 KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
 # Don't include the DATETIME variable in the sstate package signatures

meta/classes/license.bbclass

@@ -26,7 +26,6 @@ license_create_manifest() {
 	if [ -f ${LICENSE_MANIFEST} ]; then
 		rm ${LICENSE_MANIFEST}
 	fi
-	# list of installed packages is broken for deb
 	touch ${LICENSE_MANIFEST}
 	for pkg in ${INSTALLED_PKGS}; do
 		# not the best way to do this but licenses are not arch dependant iirc

meta/classes/native.bbclass

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

meta/classes/package.bbclass

@@ -1130,6 +1130,13 @@ python emit_pkgdata() {
     workdir = d.getVar('WORKDIR', True)
 
     for pkg in packages.split():
+        items = {}
+        for files_list in pkgfiles[pkg]:
+             item_name = os.path.basename(files_list)
+             item_path = os.path.dirname(files_list)
+             if item_path not in items:
+                 items[item_path] = []
+             items[item_path].append(item_name)
         subdata_file = pkgdatadir + "/runtime/%s" % pkg
 
         pkgval = d.getVar('PKG_%s' % pkg, True)
@@ -1137,6 +1144,8 @@ python emit_pkgdata() {
             pkgval = pkg
             d.setVar('PKG_%s' % pkg, pkg)
 
+        d.setVar('FILES_INFO', str(items))
+
         sf = open(subdata_file, 'w')
         write_if_exists(sf, pkg, 'PN')
         write_if_exists(sf, pkg, 'PV')
@@ -1161,6 +1170,7 @@ python emit_pkgdata() {
         write_if_exists(sf, pkg, 'pkg_preinst')
         write_if_exists(sf, pkg, 'pkg_prerm')
         write_if_exists(sf, pkg, 'FILERPROVIDESFLIST')
+        write_if_exists(sf, pkg, 'FILES_INFO')
         for dfile in (d.getVar('FILERPROVIDESFLIST_' + pkg, True) or "").split():
             write_if_exists(sf, pkg, 'FILERPROVIDES_' + dfile)
 

meta/classes/package_deb.bbclass

@@ -7,7 +7,6 @@ inherit package
 IMAGE_PKGTYPE ?= "deb"
 
 DPKG_ARCH ?= "${TARGET_ARCH}" 
-DPKG_ARCH_arm ?= "armel"
 
 PKGWRITEDIRDEB = "${WORKDIR}/deploy-debs"
 
@@ -406,8 +405,11 @@ python () {
         d.setVarFlag('do_package_write_deb_setscene', 'fakeroot', "1")
 
     # Map TARGET_ARCH to Debian's ideas about architectures
-    if d.getVar('DPKG_ARCH', True) in ["x86", "i486", "i586", "i686", "pentium"]:
-        d.setVar('DPKG_ARCH', 'i386')
+    darch = d.getVar('DPKG_ARCH', True)
+    if darch in ["x86", "i486", "i586", "i686", "pentium"]:
+         d.setVar('DPKG_ARCH', 'i386')
+    elif darch == "arm":
+         d.setVar('DPKG_ARCH', 'armel')
 }
 
 python do_package_write_deb () {

meta/classes/packageinfo.bbclass

@@ -8,6 +8,7 @@ python packageinfo_handler () {
         package_archs = e.data.getVar('PACKAGE_ARCHS', True)
         packaging = e.data.getVar('PACKAGE_CLASSES', True).split()[0].split('_')[1]
         deploy_dir = e.data.getVar('DEPLOY_DIR', True) + '/' + packaging
+                                           
         for arch in package_archs.split():
             pkgdata_dir = tmpdir + '/pkgdata/' + arch + target_vendor + '-' + target_os + '/runtime/'
             if os.path.exists(pkgdata_dir):

meta/classes/pixbufcache.bbclass

@@ -15,7 +15,8 @@ PIXBUF_PACKAGES ??= "${PN}"
 #
 pixbufcache_common() {
 if [ "x$D" != "x" ]; then
-	$INTERCEPT_DIR/postinst_intercept update_pixbuf_cache ${PKG} libdir=${libdir} bindir=${bindir}
+	$INTERCEPT_DIR/postinst_intercept update_pixbuf_cache ${PKG} libdir=${libdir} \
+		bindir=${bindir} base_libdir=${base_libdir}
 	exit 1
 fi
 

meta/classes/ptest.bbclass

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

meta/classes/qemu.bbclass

@@ -29,10 +29,9 @@ def qemu_run_binary(data, rootfs_path, binary):
     if qemu_binary == "qemu-allarch":
         qemu_binary = "qemuwrapper"
 
-    dynamic_loader = rootfs_path + '$(readelf -l ' + rootfs_path + \
-                     binary + '| grep "Requesting program interpreter"|sed -e \'s/^.*\[.*: \(.*\)\]/\\1/\')'
-    library_path = rootfs_path + data.getVar("base_libdir", True) + ":" + \
-                   rootfs_path + data.getVar("libdir", True)
+    libdir = rootfs_path + data.getVar("libdir", False)
+    base_libdir = rootfs_path + data.getVar("base_libdir", False)
 
-    return "PSEUDO_UNLOAD=1 " + qemu_binary + " " + dynamic_loader + " --library-path " + library_path \
-           + " " + rootfs_path + binary
+    return "PSEUDO_UNLOAD=1 " + qemu_binary + " -L " + rootfs_path\
+            + " -E LD_LIBRARY_PATH=" + libdir + ":" + base_libdir + " "\
+            + rootfs_path + binary

meta/classes/rootfs_rpm.bbclass

@@ -3,6 +3,7 @@
 #
 
 ROOTFS_PKGMANAGE = "rpm smartpm"
+ROOTFS_PKGMANAGE_BOOTSTRAP = "rpm-postinsts"
 
 # Add 50Meg of extra space for Smart
 IMAGE_ROOTFS_EXTRA_SPACE_append = "${@base_contains("PACKAGE_INSTALL", "smartpm", " + 51200", "" ,d)}"
@@ -10,9 +11,6 @@ IMAGE_ROOTFS_EXTRA_SPACE_append = "${@base_contains("PACKAGE_INSTALL", "smartpm"
 # Smart is python based, so be sure python-native is available to us.
 EXTRANATIVEPATH += "python-native"
 
-# Postinstalls on device are handled within this class at present
-ROOTFS_PKGMANAGE_BOOTSTRAP = ""
-
 do_rootfs[depends] += "rpm-native:do_populate_sysroot"
 do_rootfs[depends] += "rpmresolve-native:do_populate_sysroot"
 do_rootfs[depends] += "python-smartpm-native:do_populate_sysroot"

meta/classes/sstate.bbclass

@@ -197,7 +197,8 @@ def sstate_install(ss, d):
 
     # Run the actual file install
     for state in ss['dirs']:
-        oe.path.copytree(state[1], state[2])
+        if os.path.exists(state[1]):
+            oe.path.copytree(state[1], state[2])
 
     for postinst in (d.getVar('SSTATEPOSTINSTFUNCS', True) or '').split():
         bb.build.exec_func(postinst, d)
@@ -448,6 +449,8 @@ def sstate_package(ss, d):
     bb.mkdirhier(sstatebuild)
     bb.mkdirhier(os.path.dirname(sstatepkg))
     for state in ss['dirs']:
+        if not os.path.exists(state[1]):
+            continue
         srcbase = state[0].rstrip("/").rsplit('/', 1)[0]
         for walkroot, dirs, files in os.walk(state[1]):
             for file in files:
@@ -547,7 +550,7 @@ sstate_create_package () {
 		tar -cz --file=$TFILE --files-from=/dev/null
 	fi
 	chmod 0664 $TFILE 
-	mv $TFILE ${SSTATE_PKG}
+	mv -f $TFILE ${SSTATE_PKG}
 
 	cd ${WORKDIR}
 	rm -rf ${SSTATE_BUILDDIR}
@@ -641,7 +644,7 @@ def setscene_depvalid(task, taskdependees, notneeded, d):
             return True
         return False
     def isPostInstDep(x):
-        if x in ["qemu-native", "gdk-pixbuf-native", "gtk+-native", "qemuwrapper-cross", "depmodwrapper-cross", "systemd-systemctl-native", "gtk-update-icon-cache-native"]:
+        if x in ["qemu-native", "gdk-pixbuf-native", "qemuwrapper-cross", "depmodwrapper-cross", "systemd-systemctl-native", "gtk-update-icon-cache-native"]:
             return True
         return False
 

meta/classes/systemd.bbclass

@@ -10,11 +10,14 @@ SYSTEMD_AUTO_ENABLE ??= "enable"
 # even if the systemd DISTRO_FEATURE isn't enabled.  As such don't make any
 # changes directly but check the DISTRO_FEATURES first.
 python __anonymous() {
-    if "systemd" in d.getVar("DISTRO_FEATURES", True).split():
+    features = d.getVar("DISTRO_FEATURES", True).split()
+    # If the distro features have systemd but not sysvinit, inhibit update-rcd
+    # from doing any work so that pure-systemd images don't have redundant init
+    # files.
+    if "systemd" in features:
         d.appendVar("DEPENDS", " systemd-systemctl-native")
-        # Set a variable so that update-rcd.bbclass knows we're active and can
-        # disable itself.
-        d.setVar("SYSTEMD_BBCLASS_ENABLED", "1")
+        if "sysvinit" not in features:
+            d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
 }
 
 systemd_postinst() {
@@ -24,19 +27,23 @@ if [ -n "$D" ]; then
     OPTS="--root=$D"
 fi
 
-systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
+if type systemctl >/dev/null 2>/dev/null; then
+	systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
 
-if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
-    systemctl start ${SYSTEMD_SERVICE}
+	if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
+		systemctl restart ${SYSTEMD_SERVICE}
+	fi
 fi
 }
 
 systemd_prerm() {
-if [ -z "$D" ]; then
-    systemctl stop ${SYSTEMD_SERVICE}
-fi
+if type systemctl >/dev/null 2>/dev/null; then
+	if [ -z "$D" ]; then
+		systemctl stop ${SYSTEMD_SERVICE}
+	fi
 
-systemctl disable ${SYSTEMD_SERVICE}
+	systemctl disable ${SYSTEMD_SERVICE}
+fi
 }
 
 python systemd_populate_packages() {
@@ -56,14 +63,6 @@ python systemd_populate_packages() {
             bb.error('%s does not appear in package list, please add it' % pkg_systemd)
 
 
-    # Add a runtime dependency on systemd to pkg
-    def systemd_add_rdepends(pkg):
-        rdepends = d.getVar('RDEPENDS_' + pkg, True) or ""
-        if not 'systemd' in rdepends.split():
-            rdepends = '%s %s' % (rdepends, 'systemd')
-        d.setVar('RDEPENDS_' + pkg, rdepends)
-
-
     def systemd_generate_package_scripts(pkg):
         bb.debug(1, 'adding systemd calls to postinst/postrm for %s' % pkg)
 
@@ -156,7 +155,6 @@ python systemd_populate_packages() {
             systemd_check_package(pkg)
             if d.getVar('SYSTEMD_SERVICE_' + pkg, True):
                 systemd_generate_package_scripts(pkg)
-                systemd_add_rdepends(pkg)
         systemd_check_services()
 }
 

meta/classes/update-rc.d.bbclass

@@ -6,7 +6,7 @@ UPDATERCD_virtclass-cross = ""
 UPDATERCD_class-native = ""
 UPDATERCD_class-nativesdk = ""
 
-RDEPENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
+RRECOMMENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
 
 INITSCRIPT_PARAMS ?= "defaults"
 
@@ -18,7 +18,9 @@ if test "x$D" != "x"; then
 else
 	OPT="-s"
 fi
-update-rc.d $OPT ${INITSCRIPT_NAME} ${INITSCRIPT_PARAMS}
+if type update-rc.d >/dev/null 2>/dev/null; then
+	update-rc.d $OPT ${INITSCRIPT_NAME} ${INITSCRIPT_PARAMS}
+fi
 }
 
 updatercd_prerm() {
@@ -28,10 +30,13 @@ fi
 }
 
 updatercd_postrm() {
-if [ "$D" != "" ]; then
-	update-rc.d -f -r $D ${INITSCRIPT_NAME} remove
+if test "$D" != ""; then
+	OPT="-f -r $D"
 else
-	update-rc.d ${INITSCRIPT_NAME} remove
+	OPT=""
+fi
+if type update-rc.d >/dev/null 2>/dev/null; then
+	update-rc.d $OPT ${INITSCRIPT_NAME} remove
 fi
 }
 
@@ -57,27 +62,34 @@ python populate_packages_updatercd () {
         execute on the target. Not doing so may cause update_rc.d postinst invoked
         twice to cause unwanted warnings.
         """ 
+
+        localdata = bb.data.createCopy(d)
+        overrides = localdata.getVar("OVERRIDES", True)
+        localdata.setVar("OVERRIDES", "%s:%s" % (pkg, overrides))
+        bb.data.update_data(localdata)
+
         postinst = d.getVar('pkg_postinst_%s' % pkg, True)
         if not postinst:
             postinst = '#!/bin/sh\n'
-        postinst += d.getVar('updatercd_postinst', True)
+        postinst += localdata.getVar('updatercd_postinst', True)
         d.setVar('pkg_postinst_%s' % pkg, postinst)
 
         prerm = d.getVar('pkg_prerm_%s' % pkg, True)
         if not prerm:
             prerm = '#!/bin/sh\n'
-        prerm += d.getVar('updatercd_prerm', True)
+        prerm += localdata.getVar('updatercd_prerm', True)
         d.setVar('pkg_prerm_%s' % pkg, prerm)
 
         postrm = d.getVar('pkg_postrm_%s' % pkg, True)
         if not postrm:
                 postrm = '#!/bin/sh\n'
-        postrm += d.getVar('updatercd_postrm', True)
+        postrm += localdata.getVar('updatercd_postrm', True)
         d.setVar('pkg_postrm_%s' % pkg, postrm)
 
-    # If the systemd class has also been inherited, then don't do anything as
-    # the systemd units will override anything created by update-rc.d.
-    if not d.getVar("SYSTEMD_BBCLASS_ENABLED", True):
+    # Check that this class isn't being inhibited (generally, by
+    # systemd.bbclass) before doing any work.
+    if "sysvinit" in d.getVar("DISTRO_FEATURES").split() or \
+       not d.getVar("INHIBIT_UPDATERCD_BBCLASS", True):
         pkgs = d.getVar('INITSCRIPT_PACKAGES', True)
         if pkgs == None:
             pkgs = d.getVar('UPDATERCPN', True)

meta/conf/bitbake.conf

@@ -730,7 +730,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?= ""
 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= ""
 IMAGE_FEATURES += "${EXTRA_IMAGE_FEATURES}"
 
-DISTRO_FEATURES_BACKFILL = "pulseaudio ${DISTRO_FEATURES_INITMAN}"
+DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit"
 MACHINE_FEATURES_BACKFILL = "rtc"
 
 COMBINED_FEATURES = "\

meta/conf/conf-notes.txt

@@ -0,0 +1,9 @@
+Common targets are:
+    core-image-minimal
+    core-image-sato
+    meta-toolchain
+    meta-toolchain-sdk
+    adt-installer
+    meta-ide-support
+
+You can also run generated qemu images with a command like 'runqemu qemux86'

meta/conf/distro/include/default-distrovars.inc

@@ -17,8 +17,7 @@ DISTRO_FEATURES_LIBC_DEFAULT ?= "ipv4 ipv6 libc-backtrace libc-big-macros libc-b
 					libc-posix-wchar-io"
 DISTRO_FEATURES_LIBC ?= "${DISTRO_FEATURES_LIBC_DEFAULT}"
 DISTRO_FEATURES_LIBC_class-nativesdk = "${DISTRO_FEATURES_LIBC_DEFAULT}"
-DISTRO_FEATURES_INITMAN ?= "sysvinit"
-DISTRO_FEATURES ?= "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 ${DISTRO_FEATURES_LIBC} ${DISTRO_FEATURES_INITMAN}"
+DISTRO_FEATURES ?= "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 ${DISTRO_FEATURES_LIBC}"
 
 IMAGE_FEATURES ?= ""
 

meta/conf/distro/include/default-providers.inc

@@ -12,7 +12,6 @@ PREFERRED_PROVIDER_virtual/update-alternatives ?= "opkg"
 PREFERRED_PROVIDER_virtual/update-alternatives-native ?= "opkg-native"
 PREFERRED_PROVIDER_virtual/libx11 ?= "libx11"
 PREFERRED_PROVIDER_xf86-video-intel ?= "xf86-video-intel"
-PREFERRED_PROVIDER_virtual/gtk-update-icon-cache-native ?= "gtk-update-icon-cache-native"
 
 #
 # Default virtual runtime providers
@@ -38,4 +37,4 @@ PREFERRED_PROVIDER_nativesdk-opkg ?= "nativesdk-opkg"
 PREFERRED_PROVIDER_console-tools ?= "kbd"
 PREFERRED_PROVIDER_gzip-native ?= "pigz-native"
 PREFERRED_PROVIDER_make ?= "make"
-PREFERRED_PROVIDER_udev ?= "${@base_contains('DISTRO_FEATURES','sysvinit','udev','',d)}${@base_contains('DISTRO_FEATURES','systemd','systemd','',d)}"
+PREFERRED_PROVIDER_udev ?= "${@base_contains('DISTRO_FEATURES','systemd','systemd','udev',d)}"

meta/conf/distro/include/seperatebuilddir.inc

@@ -222,7 +222,6 @@ B_pn-gtk+3 = "${SEPB}"
 B_pn-gtk-doc-stub = "${SEPB}"
 B_pn-gtk-doc-stub-native = "${SEPB}"
 B_pn-gtk-engines = "${SEPB}"
-B_pn-gtk+-native = "${SEPB}"
 ##make[1]: *** No rule to make target `data/gtkrc', needed by `all-am'.  Stop
 ##B_pn-gtk-sato-engine = "${SEPB}"
 B_pn-guile = "${SEPB}"

meta/conf/layer.conf

@@ -1,6 +1,6 @@
 # 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 += "core"
@@ -31,4 +31,5 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += " \
   keymaps \
   udev-extraconf \
   packagegroup-x11-xserver \
+  systemd-serialgetty \
 "

meta/conf/machine/qemux86-64.conf

@@ -14,7 +14,7 @@ KERNEL_IMAGETYPE = "bzImage"
 
 SERIAL_CONSOLE = "115200 ttyS0"
 
-XSERVER ?= "xserver-xorg \
+XSERVER = "xserver-xorg \
            mesa-driver-swrast \
            xf86-input-vmmouse \
            xf86-input-keyboard \

meta/conf/machine/qemux86.conf

@@ -14,7 +14,7 @@ KERNEL_IMAGETYPE = "bzImage"
 
 SERIAL_CONSOLE = "115200 ttyS0"
 
-XSERVER ?= "xserver-xorg \
+XSERVER = "xserver-xorg \
            mesa-driver-swrast \
            xf86-input-vmmouse \
            xf86-input-keyboard \

meta/lib/oe/classextend.py

@@ -5,7 +5,7 @@ class ClassExtender(object):
         self.pkgs_mapping = []
 
     def extend_name(self, name):
-        if name.startswith("kernel-module") or name == "virtual/kernel":
+        if name.startswith("kernel-") or name == "virtual/kernel":
             return name
         if name.startswith("rtld"):
             return name

meta/lib/oe/lsb.py

@@ -1,9 +1,9 @@
 def release_dict():
-    """Return the output of lsb_release -a as a dictionary"""
+    """Return the output of lsb_release -ir as a dictionary"""
     from subprocess import PIPE
 
     try:
-        output, err = bb.process.run(['lsb_release', '-a'], stderr=PIPE)
+        output, err = bb.process.run(['lsb_release', '-ir'], stderr=PIPE)
     except bb.process.CmdError as exc:
         return None
 
@@ -26,7 +26,7 @@ def release_dict_file():
             with open('/etc/lsb-release') as f:
                 for line in f:
                     key, value = line.split("=", 1)
-                    data[key] = value
+                    data[key] = value.strip()
         elif os.path.exists('/etc/redhat-release'):
             data = {}
             with open('/etc/redhat-release') as f:

meta/lib/oe/terminal.py

@@ -105,6 +105,43 @@ class Screen(Terminal):
         else:
             logger.warn(msg)
 
+class TmuxRunning(Terminal):
+    """Open a new pane in the current running tmux window"""
+    command = 'tmux split-window {command}'
+    priority = 2.75
+
+    def __init__(self, sh_cmd, title=None, env=None, d=None):
+        if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+            raise UnsupportedTerminal('tmux is not installed')
+
+        if not os.getenv('TMUX'):
+            raise UnsupportedTerminal('tmux is not running')
+
+        Terminal.__init__(self, sh_cmd, title, env, d)
+
+class TmuxNewSession(Terminal):
+    """Start a new tmux session and window"""
+    command = 'tmux new -d -s devshell -n devshell {command}'
+    priority = 0.75
+
+    def __init__(self, sh_cmd, title=None, env=None, d=None):
+        if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+            raise UnsupportedTerminal('tmux is not installed')
+
+        # TODO: consider using a 'devshell' session shared amongst all
+        # devshells, if it's already there, add a new window to it.
+        window_name = 'devshell-%i' % os.getpid()
+
+        self.command = 'tmux new -d -s {0} -n {0} {{command}}'.format(window_name)
+        Terminal.__init__(self, sh_cmd, title, env, d)
+
+        attach_cmd = 'tmux att -t {0}'.format(window_name)
+        msg = 'Tmux started. Please connect in another terminal with `tmux att -t {0}`'.format(window_name)
+        if d:
+            bb.event.fire(bb.event.LogExecTTY(msg, attach_cmd, 0.5, 10), d)
+        else:
+            logger.warn(msg)
+
 class Custom(Terminal):
     command = 'false' # This is a placeholder
     priority = 3

meta/lib/oe/tests/test_utils.py

@@ -0,0 +1,27 @@
+import unittest
+import bb, oe.utils
+
+class TestPackagesFilterOutSystem(unittest.TestCase):
+    def test_filter(self):
+        """
+        Test that oe.utils.packages_filter_out_system works.
+        """
+
+        d = bb.data_smart.DataSmart()
+        d.setVar("PN", "foo")
+
+        d.setVar("PACKAGES", "foo foo-doc foo-dev")
+        pkgs = oe.utils.packages_filter_out_system(d)
+        self.assertEqual(pkgs, [])
+
+        d.setVar("PACKAGES", "foo foo-doc foo-data foo-dev")
+        pkgs = oe.utils.packages_filter_out_system(d)
+        self.assertEqual(pkgs, ["foo-data"])
+
+        d.setVar("PACKAGES", "foo foo-locale-en-gb")
+        pkgs = oe.utils.packages_filter_out_system(d)
+        self.assertEqual(pkgs, [])
+
+        d.setVar("PACKAGES", "foo foo-data foo-locale-en-gb")
+        pkgs = oe.utils.packages_filter_out_system(d)
+        self.assertEqual(pkgs, ["foo-data"])

meta/lib/oe/utils.py

@@ -107,3 +107,19 @@ def features_backfill(var,d):
 
     if addfeatures:
         d.appendVar(var, " " + " ".join(addfeatures))
+
+
+def packages_filter_out_system(d):
+    """
+    Return a list of packages from PACKAGES with the "system" packages such as
+    PN-dbg PN-doc PN-locale-eb-gb removed.
+    """
+    pn = d.getVar('PN', True)
+    blacklist = map(lambda suffix: pn + suffix, ('', '-dbg', '-dev', '-doc', '-locale', '-staticdev'))
+    localepkg = pn + "-locale-"
+    pkgs = []
+
+    for pkg in d.getVar('PACKAGES', True).split():
+        if pkg not in blacklist and localepkg not in pkg:
+            pkgs.append(pkg)
+    return pkgs

meta/recipes-bsp/pcmciautils/pcmciautils.inc

@@ -21,7 +21,7 @@ export udevrulesdir = "${nonarch_base_libdir}/udev/rules.d"
 export UDEV = "1"
 LD = "${CC}"
 CFLAGS =+ "-I${S}/src"
-CFLAGS =+ "-DPCMCIAUTILS_VERSION=\'${PV}\'"
+CFLAGS =+ "-DPCMCIAUTILS_VERSION=\\"${PV}\\""
 
 PARALLEL_MAKE = ""
 EXTRA_OEMAKE = "-e 'STRIP=echo' 'LIB_OBJS=-lc -lsysfs' 'LEX=flex'"