build-appliance: Update to latest dylan revision for release

(From OE-Core rev: 94e3f18214e2e35076c52ed27252073f788ec01f)

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

README.hardware

@@ -308,9 +308,9 @@ Load the kernel and dtb (device tree blob), and boot the system as follows:
 
  5. Download the kernel and dtb, and boot:
 
- => tftp 800000 uImage-mpc8315e-rdb.bin
- => tftp 780000 uImage-mpc8315e-rdb.dtb
- => bootm 800000 - 780000
+ => tftp 1000000 uImage-mpc8315e-rdb.bin
+ => tftp 2000000 uImage-mpc8315e-rdb.dtb
+ => bootm 1000000 - 2000000
 
 
 Ubiquiti Networks RouterStation Pro (routerstationpro)

bitbake/lib/bb/data.py

@@ -158,9 +158,9 @@ def expandKeys(alterdata, readdata = None):
 
     for key in todolist:
         ekey = todolist[key]
-        if ekey in keys(alterdata):
+        newval = alterdata.getVar(ekey, 0)
+        if newval:
             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)

bitbake/lib/bb/fetch2/__init__.py

@@ -74,6 +74,9 @@ class FetchError(BBFetchException):
 
 class ChecksumError(FetchError):
     """Exception when mismatched checksum encountered"""
+    def __init__(self, message, url = None, checksum = None):
+        self.checksum = checksum
+        FetchError.__init__(self, message, url)
 
 class NoChecksumError(FetchError):
     """Exception when no checksum is specified, but BB_STRICT_CHECKSUM is set"""
@@ -561,7 +564,7 @@ def verify_checksum(u, ud, d):
         msg = msg + '\nIf this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:\nSRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"\nOtherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.\n' % (ud.md5_name, md5data, ud.sha256_name, sha256data)
 
     if len(msg):
-        raise ChecksumError('Checksum mismatch!%s' % msg, u)
+        raise ChecksumError('Checksum mismatch!%s' % msg, u, md5data)
 
 
 def update_stamp(u, ud, d):
@@ -804,6 +807,7 @@ def try_mirror_url(newuri, origud, ud, ld, check = False):
         if isinstance(e, ChecksumError):
             logger.warn("Mirror checksum failure for url %s (original url: %s)\nCleaning and trying again." % (newuri, origud.url))
             logger.warn(str(e))
+            self.rename_bad_checksum(ud, e.checksum)
         elif isinstance(e, NoChecksumError):
             raise
         else:
@@ -1388,6 +1392,7 @@ class Fetch(object):
                         if isinstance(e, ChecksumError):
                             logger.warn("Checksum failure encountered with download of %s - will attempt other sources if available" % u)
                             logger.debug(1, str(e))
+                            self.rename_bad_checksum(ud, e.checksum)
                         elif isinstance(e, NoChecksumError):
                             raise
                         else:
@@ -1495,6 +1500,18 @@ class Fetch(object):
             if ud.lockfile:
                 bb.utils.unlockfile(lf)
 
+    def rename_bad_checksum(self, ud, suffix):
+        """
+        Renames files to have suffix from parameter
+        """
+
+        if ud.localpath is None:
+            return
+
+        new_localpath = "%s_bad-checksum_%s" % (ud.localpath, suffix)
+        bb.warn("Renaming %s to %s" % (ud.localpath, new_localpath))
+        bb.utils.movefile(ud.localpath, new_localpath)
+
 from . import cvs
 from . import git
 from . import gitsm

bitbake/lib/bb/monitordisk.py

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

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

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

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

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

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

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

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

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

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

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

documentation/adt-manual/adt-command.xml

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

documentation/adt-manual/adt-intro.xml

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

documentation/adt-manual/adt-package.xml

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

documentation/adt-manual/adt-prepare.xml

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

documentation/bsp-guide/bsp.xml

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

documentation/dev-manual/dev-manual-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.
@@ -159,12 +160,12 @@
                     <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
                     The recipes and configurations for these four BSPs are located and dispersed
                     within the <link linkend='source-directory'>Source Directory</link>.
-                    On the other hand, BSP layers for Cedar Trail, Chief River, Crown Bay,
-                    Crystal Forest, Emenlow, Fish River, Fish River 2, Jasper Forest, N450,
+                    On the other hand, BSP layers for Chief River, Crown Bay,
+                    Crystal Forest, Emenlow, Fish River Island 2, Jasper Forest, N450, NUC DC3217IYE,
                     Romley, sys940x, Sugar Bay, and tlk exist in their own separate layers
                     within the larger <filename>meta-intel</filename> layer.</note>
                     <para>When you set up a layer for a new BSP, you should follow a standard layout.
-                    This layout is described in the section
+                    This layout is described in the 
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
                     section of the Board Support Package (BSP) Development Guide.
                     In the standard layout, you will notice a suggested structure for recipes and
@@ -178,7 +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.8</filename></emphasis> - The
+                    stable Yocto Project kernel to use with the Yocto Project Release 1.4. This kernel
+                    is based on the Linux 3.8 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
                     kernel based on the latest upstream release candidate available.</para></listitem>
                 </itemizedlist>
@@ -292,8 +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

@@ -1088,9 +1088,11 @@
         The "master" branch is the “upstream” repository where the final builds of the project occur.
         The maintainer is responsible for allowing changes in from other developers and for
         organizing the underlying branch structure to reflect release strategies and so forth.
-        <note>You can see who is the maintainer for Yocto Project files by examining the
-        <filename>maintainers.inc</filename> file in the Yocto Project
-        <filename>meta-yocto/conf/distro/include</filename> directory.</note>
+        <note>For information on finding out who is responsible (maintains) 
+            for a particular area of code, see the 
+            "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+            section.
+        </note>
     </para>
 
     <para>
@@ -1251,6 +1253,11 @@
                 and so forth that surrounds the issue.
                 You can even attach supporting files for output from logs by 
                 using the "Add an attachment" button.</para></listitem>
+            <listitem><para>Be sure to copy the appropriate people in the 
+                "CC List" for the bug.  
+                See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                section for information about finding out who is responsible
+                for code.</para></listitem>
             <listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
         </orderedlist>
     </para>
@@ -1265,6 +1272,46 @@
         will want to extend, configure or optimize it for their specific uses.
         You should send patches to the appropriate mailing list so that they
         can be reviewed and merged by the appropriate maintainer.
+    </para>
+
+    <para>
+        Before submitting any change, be sure to find out who you should be
+        notifying.
+        Several methods exist through which you find out who you should be copying
+        or notifying:
+        <itemizedlist>
+            <listitem><para><emphasis>Maintenance File:</emphasis>
+                Examine the <filename>maintainers.inc</filename> file, which is 
+                located in the 
+                <link linkend='source-directory'>Source Directory</link>
+                at <filename>meta-yocto/conf/distro/include</filename>, to 
+                see who is responsible for code.
+                </para></listitem>
+            <listitem><para><emphasis>Board Support Package (BSP) README Files:</emphasis>
+                For BSP maintainers of supported BSPs, you can examine 
+                individual BSP <filename>README</filename> files.
+                Alternatively, you can examine the 
+                <filename>MAINTAINERS</filename> file, which is found in the 
+                <filename>meta-intel</filename>, for a list of all supported
+                BSP maintainers.
+                </para></listitem>
+            <listitem><para><emphasis>Search by File:</emphasis>
+                Using <link linkend='git'>Git</link>, you can enter the 
+                following command to bring up a short list of all commits 
+                against a specific file:
+                <literallayout class='monospaced'>
+     git shortlog -- &lt;filename&gt;
+                </literallayout>
+                Just provide the name of the file for which you are interested.
+                The information returned is not ordered by history but does 
+                include a list of all committers grouped by name. 
+                From the list, you can see who is responsible for the bulk of
+                the changes against the file.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>                
         For a list of the Yocto Project and related mailing lists, see the
         "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in
         the Yocto Project Reference Manual.

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

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

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

@@ -34,7 +34,7 @@
             <itemizedlist>
                 <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" for
                     general information on layers and how to create layers.</para></listitem>
-                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#get-your-layer-setup-for-the-build'>Get Your Layer Setup for the Build</ulink>" for
+                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" for
                     specific instructions on setting up a layer for kernel
                     development.</para></listitem>
             </itemizedlist>
@@ -69,7 +69,7 @@
             See the "<link linkend='creating-and-preparing-a-layer'>Creating and Preparing a Layer</link>"
             section for some general resources.
             You can also see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#get-your-layer-setup-for-the-build'>Get Your Layer Setup for the Build</ulink>" section
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" section
             of the Yocto Project Development Manual for a detailed
             example.
         </para>
@@ -149,19 +149,31 @@
                 You can make wholesale or incremental changes to the Linux
                 kernel <filename>.config</filename> file by including a
                 <filename>defconfig</filename> or by specifying
-                configuration fragments in the <filename>SRC_URI</filename>.
+                configuration fragments in the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
             </para>
 
             <para>
                 If you have a complete Linux kernel <filename>.config</filename>
-                file you want to use, copy it to the
-                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink><filename>}</filename>
-                directory within your layer and name it "defconfig".
-                Then, add the following line to your linux-yocto
+                file you want to use, copy it to a directory named 
+                <filename>files</filename>, which must be in 
+                your layer's <filename>recipes-kernel/linux</filename> 
+                directory, and name the file "defconfig".
+                Then, add the following lines to your linux-yocto
                 <filename>.bbappend</filename> file in your layer:
                 <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
      SRC_URI += "file://defconfig"
                 </literallayout>
+                The 
+                <filename>SRC_URI</filename> tells the build system how to 
+                search for the file, while the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                extends the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+                variable (search directories) to include the 
+                <filename>files</filename> directory you created for the
+                configuration changes.
             </para>
 
             <para>
@@ -170,7 +182,7 @@
                 configuration fragment.
                 For example, if you want to add support for a basic serial
                 console, create a file named <filename>8250.cfg</filename> in the
-                <filename>${FILES}</filename> directory with the following
+                <filename>files</filename> directory with the following
                 content (without indentation):
                 <literallayout class='monospaced'>
      CONFIG_SERIAL_8250=y
@@ -181,10 +193,11 @@
      CONFIG_SERIAL_CORE=y
      CONFIG_SERIAL_CORE_CONSOLE=y
                 </literallayout>
-                Next, include this configuration fragment in a
-                <filename>SRC_URI</filename> statement in your
+                Next, include this configuration fragment and extend the 
+                <filename>FILESPATH</filename> variable in your 
                 <filename>.bbappend</filename> file:
                 <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
      SRC_URI += "file://8250.cfg"
                 </literallayout>
                 The next time you run BitBake to build the Linux kernel, BitBake
@@ -371,7 +384,7 @@
 
      WARNING: There were 2 hardware options requested that do not
               have a corresponding value present in the final ".config" file.
-              This probably means you aren't getting the config you wanted.
+              This probably means you are not't getting the config you wanted.
               The full list can be found in your kernel src dir at:
               meta/cfg/standard/mybsp/mismatch.cfg
                 </literallayout>
@@ -725,7 +738,7 @@
             "What changes have been applied to this tree?"
             Rather than using "grep" across directories to see what has
             changed, you can use Git to inspect or search the kernel tree.
-            Using Git is an efficent way to see what has changed in the tree.
+            Using Git is an efficient way to see what has changed in the tree.
         </para>
 
         <section id='what-changed-in-a-kernel'>
@@ -766,7 +779,7 @@
             </para>
 
             <para>
-                To see short, oneline summaries of changes use the
+                To see short, one line summaries of changes use the
                 <filename>git log</filename> command:
                 <literallayout class='monospaced'>
      $ git log --oneline origin/standard/base..origin/standard/emenlow

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

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

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

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

documentation/ref-manual/faq.xml

@@ -173,7 +173,8 @@
                 (<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.
+                Ubuntu or Fedora. 
+                However, package management on the target is entirely optional.
             </para>
         </answer>
     </qandaentry>
@@ -364,7 +365,7 @@
                 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.
+                or virtualization issues.
             </para>
         </answer>
     </qandaentry>

documentation/ref-manual/introduction.xml

@@ -103,10 +103,8 @@
         <para>
             Currently, the Yocto Project is supported on the following distributions:
             <itemizedlist>
-                <listitem><para>Ubuntu 10.04.4 LTS</para></listitem>
+                <listitem><para>Ubuntu 10.04</para></listitem>
                 <listitem><para>Ubuntu 11.10</para></listitem>
-                <listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
-                <listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
                 <listitem><para>Ubuntu 12.10</para></listitem>
                 <listitem><para>Fedora release 16 (Verne)</para></listitem>
                 <listitem><para>Fedora release 17 (Beefy Miracle)</para></listitem>
@@ -115,10 +113,13 @@
                 <listitem><para>CentOS release 5.7 (Final)</para></listitem>
                 <listitem><para>CentOS release 5.8 (Final)</para></listitem>
                 <listitem><para>CentOS release 6.3 (Final)</para></listitem>
-                <listitem><para>Debian GNU/Linux 6.0.6 (squeeze)</para></listitem>
+                <listitem><para>CentOS release 6.4 (Final)</para></listitem>
+                <listitem><para>Debian GNU/Linux 6.0 (squeeze)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.0</para></listitem>
                 <listitem><para>openSUSE 11.4</para></listitem>
                 <listitem><para>openSUSE 12.1</para></listitem>
                 <listitem><para>openSUSE 12.2</para></listitem>
+                <listitem><para>openSUSE 12.3</para></listitem>
             </itemizedlist>
         </para>
 

documentation/ref-manual/migration.xml

@@ -258,8 +258,8 @@
                     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-RSUGGESTS'><filename>RSUGGESTS</filename></link>, 
+                    <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
                     <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
                     <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
                     <link linkend='var-FILES'><filename>FILES</filename></link>,
@@ -310,9 +310,13 @@
                     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.
+                    adding it through the 
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link> 
+                    or <link linkend='var-DISTROOVERRIDES'><filename>DISTROOVERRIDES</filename></link>
+                    variables, as appropriate.
+                    For more related changes, see the
+                    "<link linkend='migration-1.4-variables'>Variables</link>"
+                    section.
                     </para></listitem>
             </itemizedlist>
         </para>
@@ -350,14 +354,54 @@
         <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 "".
+            The following variables have changed:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>SANITY_TESTED_DISTROS</filename>:</emphasis>
+                    This variable now uses a distribution ID, which is composed 
+                    of the host distributor ID followed by the release.
+                    Previously, 
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    was composed of the description field.
+                    For example, "Ubuntu 12.10" becomes "Ubuntu-12.10". 
+                    You do not need to worry about this change if you are not 
+                    specifically setting this variable, or if you are
+                    specifically setting it to "".
+                    </para></listitem>
+                <listitem><para><emphasis><filename>SRC_URI</filename>:</emphasis>
+                    The <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>, 
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>, 
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>, 
+                    and <filename>FILE_DIRNAME</filename> directories have been 
+                    dropped from the default value of the 
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable, which is used as the search path for finding files 
+                    referred to in 
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>. 
+                    If you have a recipe that relied upon these directories, 
+                    which would be unusual, then you will need to add the 
+                    appropriate paths within the recipe or, alternatively,
+                    rearrange the files. 
+                    The most common locations are still covered by 
+                    <filename>${BP}</filename>, <filename>${BPN}</filename>,
+                    and "files", which all remain in the default value of
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>. 
+                    </para></listitem>
+            </itemizedlist>           
+        </para>
+    </section>
+
+    <section id='migration-target-package-management-with-rpm'>
+        <title>Target Package Management with RPM</title>
+
+        <para>
+            If runtime package management is enabled and the RPM backend 
+            is selected, Smart is now installed for package download, dependency 
+            resolution, and upgrades instead of Zypper.
+            For more information on how to use Smart, run the following command 
+            on the target:
+            <literallayout class='monospaced'>
+     smart --help
+            </literallayout>
         </para>
     </section>
 

documentation/ref-manual/ref-classes.xml

@@ -17,7 +17,7 @@
     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
     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
+    (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.
@@ -171,7 +171,7 @@
     <para>
         This class renames packages so that they follow the Debian naming
         policy (i.e. <filename>eglibc</filename> becomes <filename>libc6</filename>
-        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.
+        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.)
     </para>
 </section>
 
@@ -179,9 +179,10 @@
     <title>Pkg-config - <filename>pkgconfig.bbclass</filename></title>
 
     <para>
-        <filename>pkg-config</filename> brought standardization and this class
-        aims to smooth integration of <filename>pkg-config</filename>
-        into libraries that use it.
+        <filename>pkg-config</filename> provides a standard way to get 
+        header and library information.
+        This class aims to smooth integration of
+        <filename>pkg-config</filename> into libraries that use it.
     </para>
 
     <para>
@@ -192,37 +193,26 @@
     </para>
 </section>
 
-<section id='ref-classes-src-distribute'>
-    <title>Distribution of Sources - <filename>src_distribute_local.bbclass</filename></title>
+<section id='ref-classes-archiver'>
+    <title>Archiving Sources - <filename>archive*.bbclass</filename></title>
 
     <para>
-        Many software licenses require that source files be provided along with the binaries.
-        To simplify this process, two classes were created:
-        <filename>src_distribute.bbclass</filename> and
-        <filename>src_distribute_local.bbclass</filename>.
-    </para>
-
-    <para>
-        The results of these classes are <filename>tmp/deploy/source/</filename>
-        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.
-    </para>
-
-    <para>
-        This class operates using three modes:
+        Many software licenses require that source code and other materials be
+        released with the binaries. 
+        To help with that task, the following classes are provided:
         <itemizedlist>
-            <listitem><para><emphasis>copy:</emphasis> Copies the files to the
-                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>
+            <listitem><filename>archive-original-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-patched-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-configured-sources.bbclass</filename></listitem>
+            <listitem><filename>archiver.bbclass</filename></listitem>
         </itemizedlist>
     </para>
+
+    <para>
+        For more details on the source archiver, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
 </section>
 
 <section id='ref-classes-perl'>
@@ -435,8 +425,8 @@
     <title>Host System Sanity Checks - <filename>sanity.bbclass</filename></title>
 
     <para>
-        This class checks to see if prerequisite software is present so that
-        users can be notified of potential problems that might affect their build.
+        This class checks to see if prerequisite software is present on the host system
+        so that users can be notified of potential problems that might affect their build.
         The class also performs basic user configuration checks from
         the <filename>local.conf</filename> configuration file to
         prevent common mistakes that cause build failures.
@@ -524,6 +514,54 @@
                 Any <filename>.pc</filename> file containing these paths is incorrect
                 since <filename>pkg-config</filename> itself adds the correct sysroot prefix
                 when the files are accessed.</para></listitem>
+            <listitem><para><emphasis><filename>textrel:</filename></emphasis>
+                Checks for ELF binaries that contain relocations in their 
+                <filename>.text</filename> sections, which can result in a 
+                performance impact at runtime.</para></listitem>
+            <listitem><para><emphasis><filename>pkgvarcheck:</filename></emphasis>
+                Checks through the variables 
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>, 
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>, 
+                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
+                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>, 
+                <link linkend='var-FILES'><filename>FILES</filename></link>,
+                <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
+                <filename>pkg_preinst</filename>, 
+                <filename>pkg_postinst</filename>, 
+                <filename>pkg_prerm</filename>
+                and <filename>pkg_postrm</filename>, and reports if there are 
+                variable sets that are not package-specific.
+                Using these variables without a package suffix is bad practice,
+                and might unnecessarily complicate dependencies of other packages
+                within the same recipe or have other unintended consequences.
+                </para></listitem>
+            <listitem><para><emphasis><filename>xorg-driver-abi:</filename></emphasis>
+                Checks that all packages containing Xorg drivers have ABI 
+                dependencies.
+                The <filename>xserver-xorg</filename> recipe provides driver 
+                ABI names.
+                All drivers should depend on the ABI versions that they have 
+                been built against. 
+                Driver recipes that include 
+                <filename>xorg-driver-input.inc</filename>
+                or <filename>xorg-driver-video.inc</filename> will 
+                automatically get these versions.
+                Consequently, you should only need to explicitly add 
+                dependencies to binary driver recipes.
+                </para></listitem>
+            <listitem><para><emphasis><filename>libexec:</filename></emphasis>
+                Checks if a package contains files in 
+                <filename>/usr/libexec</filename>.
+                This check is not performed if the 
+                <filename>libexecdir</filename> variable has been set 
+                explicitly to <filename>/usr/libexec</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>staticdev:</filename></emphasis>
+                Checks for static library files (<filename>*.a</filename>) in
+                non-<filename>staticdev</filename> packages.
+                </para></listitem>
             <listitem><para><emphasis><filename>la:</filename></emphasis>
                 Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
                 paths.
@@ -536,8 +574,63 @@
                 the specification for <filename>.desktop</filename> files.</para></listitem>
         </itemizedlist>
     </para>
+    <note>
+        You can use the <filename>WARN_QA</filename> and 
+        <filename>ERROR_QA</filename> variables to control the behavior of 
+        these checks at the global level (i.e. in your custom distro 
+        configuration).
+        However, to skip one or more checks in recipes, you should use 
+        <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>. 
+        For example, to skip the check for symbolic link 
+        <filename>.so</filename> files in the main package of a recipe, 
+        add the following to the recipe.
+        You need to realize that the package name override, in this example
+        <filename>${PN}</filename>, must be used:
+        <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+        </literallayout>
+        Please keep in mind that the QA checks exist in order to detect real 
+        or potential problems in the packaged output.
+        So exercise caution when disabling these checks.
+    </note>
 </section>
 
+<section id='ref-classes-rm-work'>
+    <title>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></title>
+
+    <para>
+        The OpenEmbedded build system can use a substantial amount of disk 
+        space during the build process.
+        A portion of this space is the work files under the 
+        <filename>${TMPDIR}/work</filename> directory for each recipe. 
+        Once the build system generates the packages for a recipe, the work 
+        files for that recipe are no longer needed.
+        However, by default, the build system preserves these files
+        for inspection and possible debugging purposes.
+        If you would rather have these files deleted to save disk space 
+        as the build progresses, you can enable <filename>rm_work</filename>
+        by adding the following to your <filename>local.conf</filename> file,
+        which is found in the 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        <literallayout class='monospaced'>
+    INHERIT += "rm_work"
+        </literallayout>
+        If you are modifying and building source code out of the work directory 
+        for a recipe, enabling <filename>rm_work</filename> will potentially 
+        result in your changes to the source being lost. 
+        To exclude some recipes from having their work directories deleted by
+        <filename>rm_work</filename>, you can add the names of the recipe or 
+        recipes you are working on to the <filename>RM_WORK_EXCLUDE</filename> 
+        variable, which can also be set in your <filename>local.conf</filename>
+        file.
+        Here is an example:
+        <literallayout class='monospaced'>
+    RM_WORK_EXCLUDE += "busybox eglibc"
+        </literallayout>
+    </para>
+</section>
+
+
 <section id='ref-classes-siteinfo'>
     <title>Autotools Configuration Data Cache - <filename>siteinfo.bbclass</filename></title>
 
@@ -681,12 +774,16 @@
         deploy.bbclass
         distrodata.bbclass
         dummy.bbclass
+        fontcache.bbclass
         gconf.bbclass
         gettext.bbclass
         gnomebase.bbclass
         gnome.bbclass
+        grub-efi.bbclass
+        gsettings.bbclass
         gtk-doc.bbclass
         gtk-icon-cache.bbclass
+        gtk-immodules-cache.bbclass
         gzipnative.bbclass
         icecc.bbclass
         image-empty.bbclass
@@ -708,6 +805,7 @@
         logging.bbclass
         meta.bbclass
         metadata_scm.bbclass
+        migrate_localcount.bbclass
         mime.bbclass
         mirrors.bbclass
         multilib*.bbclass
@@ -719,12 +817,14 @@
         packageinfo.bbclass
         patch.bbclass
         perlnative.bbclass
+        pixbufcache.bbclass
         pkg_distribute.bbclass
         pkg_metainfo.bbclass
         populate_sdk*.bbclass
         prexport.bbclass
         primport.bbclass
         prserv.bbclass
+        ptest.bbclass
         python-dir.bbclass
         pythonnative.bbclass
         qemu.bbclass
@@ -732,7 +832,6 @@
         qt4*.bbclass
         recipe_sanity.bbclass
         relocatable.bbclass
-        rm_work.bbclass
         scons.bbclass
         sdl.bbclass
         setuptools.bbclass
@@ -742,6 +841,7 @@
         sstate.bbclass
         staging.bbclass
         syslinux.bbclass
+        systemd.bbclass
         terminal.bbclass
         tinderclient.bbclass
         toolchain-scripts.bbclass

documentation/ref-manual/ref-variables.xml

@@ -100,7 +100,7 @@
                     By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
                     directory:
                     <literallayout class='monospaced'>
-     B = ${WORKDIR}/${BPN}/{PV}/
+     B = "${WORKDIR}/${BPN}/{PV}/"
                     </literallayout>
                     You can separate the (<filename>S</filename>) directory and the directory pointed to
                     by the <filename>B</filename> variable.
@@ -598,16 +598,35 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-COMPATIBLE_HOST'><glossterm>COMPATIBLE_HOST</glossterm>
+            <glossdef>
+                <para>A regular expression that resolves to one or more hosts 
+                    (when the recipe is native) or one or more targets (when 
+                    the recipe is non-native) with which a recipe is compatible.
+                    The regular expression is matched against
+                    <link linkend="var-HOST_SYS"><filename>HOST_SYS</filename></link>.
+                    You can use the variable to stop recipes from being built
+                    for classes of systems with which the recipes are not 
+                    compatible.
+                    Stopping these builds is particularly useful with kernels.
+                    The variable also helps to increase parsing speed 
+                    since the build system skips parsing recipes not 
+                    compatible with the current system.</para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
             <glossdef>
-                <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.
-                    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>
+                <para>A regular expression that resolves to one or more 
+                    target machines with which a recipe is compatible.
+                    The regular expression is matched against
+                    <link linkend="var-MACHINEOVERRIDES"><filename>MACHINEOVERRIDES</filename></link>.
+                    You can use the variable to stop recipes from being built
+                    for machines with which the recipes are not compatible.
+                    Stopping these builds is particularly useful with kernels.
+                    The variable also helps to increase parsing speed 
+                    since the build system skips parsing recipes not
+                    compatible with the current machine.</para>
             </glossdef>
         </glossentry>
 
@@ -723,7 +742,25 @@ Core layer for images cannot be removed
 
         <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
             <glossdef>
-                <para>Specifies the priority of recipes.</para>
+                <para>
+                    Specifies a weak bias for recipe selection priority.
+                </para>
+                <para>
+                    The most common usage of this is variable is to set 
+                    it to "-1" within a recipe for a development version of a 
+                    piece of software.
+                    Using the variable in this way causes the stable version
+                    of the recipe to build by default in the absence of
+                    <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
+                    being used to build the development version.
+                </para>
+                <note>
+                    The bias provided by <filename>DEFAULT_PREFERENCE</filename> 
+                    is weak and is overridden by 
+                    <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
+                    if the that variable is different between two layers 
+                    that contain different versions of the same recipe.
+                </note>
             </glossdef>
         </glossentry>
 
@@ -869,6 +906,22 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-DISTROOVERRIDES'><glossterm>DISTROOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    This variable lists overrides specific to the current 
+                    distribution. 
+                    By default, the variable list includes the value of the 
+                    <filename><link linkend='var-DISTRO'>DISTRO</link></filename>
+                    variable.
+                    You can extend the variable to apply any variable overrides 
+                    you want as part of the distribution and are not
+                    already in <filename>OVERRIDES</filename> through
+                    some other means.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
             <glossdef>
                 <para>
@@ -1103,42 +1156,52 @@ Core layer for images cannot be removed
             <glossdef>
                 <para>
                     Extends the search path the OpenEmbedded build system uses
-                    when looking for files and patches as it processes recipes.
-                    The directories BitBake uses when it processes recipes are
-                    defined by the
-                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> variable.
-                    You can add directories to the search path by defining the
-                    <filename>FILESEXTRAPATHS</filename> variable.
+                    when looking for files and patches as it processes recipes
+                    and append files.
+                    The directories BitBake uses when it processes recipes 
+                    are defined by the 
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable, and can be extended using 
+                    <filename>FILESEXTRAPATHS</filename>.
                 </para>
 
                 <para>
-                    To add paths to the front of the search order, prepend
-                    them and use the immediate expansion
-                    (<filename>:=</filename>) operator.
-                    Provide a list of directories and separate
-                    each path using a colon character as follows:
-                    <literallayout class='monospaced'>
-     FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
-                    </literallayout>
-                    You can add paths to the end of the search order by simply
-                    adding them as follows:
-                    <literallayout class='monospaced'>
-     FILESEXTRAPATHS := "path_1:path_2:path_3:"
-                    </literallayout>
-                    To maintain the integrity of the
-                    <filename>FILESPATH</filename> variable, you must include
-                    the appropriate beginning or ending (as needed) colon
-                    character.
-                </para>
-
-                <para>
-                    The <filename>FILESEXTRAPATHS</filename> variable is
-                    intended for use in <filename>.bbappend</filename> files
-                    to include any additional files provided in that layer.
-                    You typically accomplish this with the following:
+                    Best practices dictate that you accomplish this by using the 
+                    variable from within a <filename>.bbappend</filename> file 
+                    and that you prepend paths as follows:
                     <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
                     </literallayout>
+                    In the above example, the build system looks for files in
+                    a directory that has the same name as the corresponding
+                    append file.
+                    Here is another common use:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+                    </literallayout>
+                    In this example, the build system extends the 
+                    <filename>FILESPATH</filename> variable to include a
+                    directory named <filename>files</filename> that is in the 
+                    same directory as the corresponding append file.
+                </para>
+
+                <para>
+                    Here is a final example that specifically adds three paths:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
+                    </literallayout>
+                </para>
+
+                <para>
+                    By prepending paths in <filename>.bbappend</filename>
+                    files, you allow multiple append files that reside in
+                    different layers but are used for the same recipe to 
+                    correctly extend the path.
+                    <note>
+                        Be sure to use the immediate expansion
+                        (<filename>:=</filename>) operator and include 
+                        the trailing separating colon character.
+                    </note>
                 </para>
             </glossdef>
         </glossentry>
@@ -1146,26 +1209,37 @@ Core layer for images cannot be removed
         <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
             <glossdef>
                 <para>
-                    The default set of directories the OpenEmbedded build system uses
-                    when searching for patches and files.
+                    The default set of directories the OpenEmbedded build system 
+                    uses when searching for patches and files.
                     During the build process, BitBake searches each directory in
-                    <filename>FILESPATH</filename> in the specified order when looking for
-                    files and patches specified by each <filename>file://</filename> URI in a recipe.
+                    <filename>FILESPATH</filename> in the specified order when 
+                    looking for files and patches specified by each 
+                    <filename>file://</filename> URI in a recipe.
                 </para>
 
                 <para>
-                    The default value for the <filename>FILESPATH</filename> variable is defined
-                    in the <filename>base.bbclass</filename> class found in
-                    <filename>meta/classes</filename> in the
+                    The default value for the <filename>FILESPATH</filename> 
+                    variable is defined in the <filename>base.bbclass</filename> 
+                    class found in <filename>meta/classes</filename> in the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
                     <literallayout class='monospaced'>
      FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
         "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
                     </literallayout>
-                    Do not hand-edit the <filename>FILESPATH</filename> variable.
-                    If you want to extend the set of pathnames that BitBake uses when searching for
-                    files and patches, use the
-                    <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link> variable.
+                    <note>
+                        Do not hand-edit the <filename>FILESPATH</filename> 
+                        variable.
+                    </note>
+                    Be aware that the default <filename>FILESPATH</filename>
+                    directories do not map to directories in custom layers
+                    where append files (<filename>.bbappend</filename>) 
+                    are used.
+                    If you want the build system to find patches or files
+                    that reside with your append files, you need to extend
+                    the <filename>FILESPATH</filename> variable by using 
+                    the 
+                    <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link> 
+                    variable.
                 </para>
             </glossdef>
         </glossentry>
@@ -1229,6 +1303,34 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-HOST_SYS'><glossterm>HOST_SYS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the system, including the architecture and the 
+                    operating system, for with the build is occurring
+                    in the context of the current
+                    recipe. 
+                    The OpenEmbedded build system automatically sets this
+                    variable.
+                    You do not need to set the variable yourself.
+                </para>
+
+                <para>
+                    Here are two examples:
+                    <itemizedlist>
+                        <listitem><para>Given a native recipe on a 32-bit
+                            x86 machine running Linux, the value is 
+                            "i686-linux".
+                            </para></listitem>
+                        <listitem><para>Given a recipe being built for a 
+                            little-endian MIPS target running Linux,
+                            the value might be "mipsel-linux". 
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-i'><title>I</title>
@@ -1312,6 +1414,35 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-IMAGE_LINGUAS'><glossterm>IMAGE_LINGUAS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the list of locales to install into the image
+                    during the root filesystem construction process.
+                    The OpenEmbedded build system automatically splits locale 
+                    files, which are used for localization, into separate 
+                    packages. 
+                    Setting the <filename>IMAGE_LINGUAS</filename> variable
+                    ensures that any locale packages that correspond to packages 
+                    already selected for installation into the image are also 
+                    installed. 
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     IMAGE_LINGUAS = "pt-br de-de"
+                    </literallayout>
+                    In this example, the build system ensures any Brazilian 
+                    Portuguese and German locale files that correspond to 
+                    packages in the image are installed (i.e. 
+                    <filename>*-locale-pt-br</filename>
+                    and <filename>*-locale-de-de</filename> as well as 
+                    <filename>*-locale-pt</filename>
+                    and <filename>*-locale-de</filename>, since some software 
+                    packages only provide locale files by language and not by
+                    country-specific language).
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-IMAGE_OVERHEAD_FACTOR'><glossterm>IMAGE_OVERHEAD_FACTOR</glossterm>
             <glossdef>
                 <para>
@@ -1476,7 +1607,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-INHIBIT_PACKAGE_STRIP'><glossterm>INHIBIT_PACKAGE_STRIP</glossterm>
             <glossdef>
                 <para>
-                    Causes the build to not strip binaries in resulting packages.
+                    If set to "1", causes the build to not strip binaries in resulting packages.
                 </para>
             </glossdef>
         </glossentry>
@@ -1538,6 +1669,28 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-INSANE_SKIP'><glossterm>INSANE_SKIP</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the QA checks to skip for a specific package 
+                    within a recipe.
+                    For example, to skip the check for symbolic link 
+                    <filename>.so</filename> files in the main package of a 
+                    recipe, add the following to the recipe.
+                    The package name override must be used, which in this 
+                    example is <filename>${PN}</filename>:
+                    <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+                    </literallayout>
+                </para>
+                <para>
+                    See the "<link linkend='ref-classes-insane'>Generated Output Quality Assurance Checks - <filename>insane.bbclass</filename></link>"
+                    section for a list of the valid QA checks you can 
+                    specify using this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
 
     </glossdiv>
 
@@ -1635,6 +1788,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-KERNEL_EXTRA_ARGS'><glossterm>KERNEL_EXTRA_ARGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional <filename>make</filename>
+                    command-line arguments the OpenEmbedded build system
+                    passes on when compiling the kernel.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
             <glossdef>
                 <para>Includes additional metadata from the Yocto Project kernel Git repository.
@@ -2033,6 +2196,21 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-LOG_DIR'><glossterm>LOG_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the directory to which the OpenEmbedded build 
+                    system writes overall log files.
+                    The default directory is <filename>${TMPDIR}/log</filename>.
+                </para>
+                <para>
+                    For the directory containing logs specific to each task,
+                    see the <link linkend='var-T'><filename>T</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-m'><title>M</title>
@@ -2293,6 +2471,35 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-MACHINEOVERRIDES'><glossterm>MACHINEOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    Lists overrides specific to the current machine. 
+                    By default, this list includes the value
+                    of <filename><link linkend='var-MACHINE'>MACHINE</link></filename>. 
+                    You can extend the list to apply variable overrides for 
+                    classes of machines.
+                    For example, all QEMU emulated machines (e.g. qemuarm, 
+                    qemux86, and so forth) include a common file named
+                    <filename>meta/conf/machine/include/qemu.inc</filename>
+                    that prepends <filename>MACHINEOVERRIDES</filename> with 
+                    the following variable override:
+                    <literallayout class='monospaced'>
+    MACHINEOVERRIDES =. "qemuall:"
+                    </literallayout>
+                    Applying an override like <filename>qemuall</filename>
+                    affects all QEMU emulated machines elsewhere.
+                    Here is an example from the 
+                    <filename>connman-conf</filename> recipe:
+                    <literallayout class='monospaced'>
+    SRC_URI_append_qemuall = "file://wired.config \
+                              file://wired-setup \
+                             "
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-MAINTAINER'><glossterm>MAINTAINER</glossterm>
             <glossdef>
                 <para>The email address of the distribution maintainer.</para>
@@ -2339,6 +2546,18 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-MODULE_TARBALL_DEPLOY'><glossterm>MODULE_TARBALL_DEPLOY</glossterm>
+            <glossdef>
+                <para>
+                    Controls creation of the <filename>modules-*.tgz</filename>
+                    file.
+                    Set this variable to "0" to disable creation of this
+                    file, which contains all of the kernel modules resulting
+                    from a kernel build.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-MULTIMACH_TARGET_SYS'><glossterm>MULTIMACH_TARGET_SYS</glossterm>
             <glossdef>
                 <para>
@@ -2352,8 +2571,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
     </glossdiv>
 
-<!--            <glossdiv id='var-glossary-n'><title>N</title>-->
-<!--            </glossdiv>-->
+    <glossdiv id='var-glossary-n'><title>N</title>
+
+        <glossentry id='var-NATIVELSBSTRING'><glossterm>NATIVELSBSTRING</glossterm>
+            <glossdef>
+                <para>
+                    A string identifying the host distribution.
+                    Strings consist of the host distributor ID
+                    followed by the release, as reported by the 
+                    <filename>lsb_release</filename> tool
+                    or as read from <filename>/etc/lsb-release</filename>. 
+                    For example, when running a build on Ubuntu 12.10, the value 
+                    is "Ubuntu-12.10". 
+                    If this information is unable to be determined, the value 
+                    resolves to "Unknown".
+                </para>
+                <para>
+                    This variable is used by default to isolate native shared 
+                    state packages for different distributions (e.g. to avoid 
+                    problems with <filename>glibc</filename> version 
+                    incompatibilities).
+                    Additionally, the variable is checked against
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    if that variable is set.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
 
     <glossdiv id='var-glossary-o'><title>O</title>
 
@@ -2672,6 +2917,23 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
+            <glossdef>
+                <para>
+                    A list of aliases that a recipe also provides. 
+                    These aliases are useful for satisfying dependencies of 
+                    other recipes during the build (as specified by 
+                    <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
+                    <note>
+                        A recipe's own 
+                        <filename><link linkend='var-PN'>PN</link></filename>
+                        is implicitly already in its 
+                        <filename>PROVIDES</filename> list. 
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-PV'><glossterm>PV</glossterm>
             <glossdef>
                 <para>The version of the recipe.
@@ -2825,6 +3087,42 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-RM_WORK_EXCLUDE'><glossterm>RM_WORK_EXCLUDE</glossterm>
+            <glossdef>
+                <para>
+                    With <filename>rm_work</filename> enabled, this 
+                    variable specifies a list of packages whose work directories 
+                    should not be removed.
+                    See the "<link linkend='ref-classes-rm-work'>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></link>"
+                    section for more details.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
+            <glossdef>
+                <para>
+                    A list of package name aliases that a package also provides. 
+                    These aliases are useful for satisfying runtime dependencies 
+                    of other packages both during the build and on the target 
+                    (as specified by
+                    <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
+                    <note>
+                        A package's own name is implicitly already in its
+                        <filename>RPROVIDES</filename> list.
+                    </note>
+                </para>
+                <para>
+                   As with all package-controlling variables, you must always 
+                   use the variable in conjunction with a package name override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RPROVIDES_${PN} = "widget-abi-2"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
             <glossdef>
                 <para>
@@ -2864,8 +3162,45 @@ 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 replaced by the package in which
-                    <filename>RREPLACES</filename> appears.</para>
+                <para>
+                    A list of packages replaced by a package. 
+                    The package manager uses this variable to determine which 
+                    package should be installed to replace other package(s) 
+                    during an upgrade.
+                    In order to also have the other package(s) removed at the 
+                    same time, you must add the name of the other 
+                    package to the
+                    <filename><link linkend='var-RCONFLICTS'>RCONFLICTS</link></filename> variable.
+                </para>
+                <para>
+                   As with all package-controlling variables, you must use
+                   this variable in conjunction with a package name 
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RREPLACES_${PN} = "other-package-being-replaced"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RSUGGESTS'><glossterm>RSUGGESTS</glossterm>
+            <glossdef>
+                <para>
+                    A list of additional packages that you can suggest for 
+                    installation by the package manager at the time a package 
+                    is installed.
+                    Not all package managers support this functionality.
+                </para>
+                <para>
+                   As with all package-controlling variables, you must always
+                   use this variable in conjunction with a package name 
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RSUGGESTS_${PN} = "useful-package another-package"
+                   </literallayout>
+                </para>
             </glossdef>
         </glossentry>
 
@@ -2901,6 +3236,27 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SANITY_TESTED_DISTROS'><glossterm>SANITY_TESTED_DISTROS</glossterm>
+            <glossdef>
+                <para>
+                    A list of the host distribution identifiers that the 
+                    build system has been tested against.
+                    Identifiers consist of the host distributor ID
+                    followed by the release, 
+                    as reported by the <filename>lsb_release</filename> tool
+                    or as read from <filename>/etc/lsb-release</filename>. 
+                    Separate the list items with explicit newline 
+                    characters (<filename>\n</filename>).
+                    If <filename>SANITY_TESTED_DISTROS</filename> is not empty 
+                    and the current value of 
+                    <link linkend='var-NATIVELSBSTRING'><filename>NATIVELSBSTRING</filename></link>
+                    does not appear in the list, then the build system reports        
+                    a warning that indicates the current host distribution has 
+                    not been tested as a build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDKIMAGE_FEATURES'><glossterm>SDKIMAGE_FEATURES</glossterm>
             <glossdef>
                 <para>Equivalent to
@@ -2943,6 +3299,54 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SIGGEN_EXCLUDERECIPES_ABISAFE'><glossterm>SIGGEN_EXCLUDERECIPES_ABISAFE</glossterm>
+            <glossdef>
+                <para>
+                    A list of recipes that are completely stable and will 
+                    never change.
+                    The ABI for the recipes in the list are presented by
+                    output from the tasks run to build the recipe.
+                    Use of this variable is one way to remove dependencies from 
+                    one recipe on another that affect task signatures and
+                    thus force rebuilds when the recipe changes. 
+                    <caution>
+                        If you add an inappropriate variable to this list,
+                        the software might break at runtime if the 
+                        interface of the recipe was changed after the other 
+                        had been built.
+                    </caution>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS'><glossterm>SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS</glossterm>
+            <glossdef>
+                <para>
+                    A list of recipe dependencies that should not be used to 
+                    determine signatures of tasks from one recipe when they
+                    depend on tasks from another recipe. 
+                    For example:
+                    <literallayout class='monospaced'>
+    SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2"
+                    </literallayout>
+                    In this example, <filename>intone</filename> depends on 
+                    <filename>mplayer2</filename>.
+                </para>
+
+                <para>
+                    Use of this variable is one mechanism to remove dependencies 
+                    that affect task signatures and thus force rebuilds when a 
+                    recipe changes. 
+                    <caution>
+                        If you add an inappropriate dependency for a recipe
+                        relationship, the software might break during 
+                        runtime if the interface of the second recipe was 
+                        changed after the first recipe had been built.
+                    </caution>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SITEINFO_ENDIANNESS'><glossterm>SITEINFO_ENDIANNESS</glossterm>
             <glossdef>
                 <para>
@@ -2961,6 +3365,24 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SOC_FAMILY'><glossterm>SOC_FAMILY</glossterm>
+            <glossdef>
+                <para>
+                    Groups together machines based upon the same family
+                    of SOC (System On Chip). 
+                    You typically set this variable in a common
+                    <filename>.inc</filename> file that you include in the 
+                    configuration files of all the machines. 
+                    <note>
+                        You must include 
+                        <filename>conf/machine/include/soc-family.inc</filename>
+                        for this variable to appear in
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SPECIAL_PKGSUFFIX'><glossterm>SPECIAL_PKGSUFFIX</glossterm>
             <glossdef>
                 <para>
@@ -2975,56 +3397,60 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
             <glossdef>
                 <para>The list of source files - local or remote.
-                    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.
-                    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
+                    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 or append file only needs to 
+                    fetch a tarball from the Internet, the recipe or 
+                    append file uses a single <filename>SRC_URI</filename> 
+                    entry.
+                    On the other hand, if the recipe or append file needs to 
+                    fetch a tarball, apply two patches, and include a custom 
+                    file, the recipe or append file 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
+                        <listitem><para><emphasis><filename>file://</filename> -</emphasis>
+                            Fetches files, which are usually files 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.
-                            Thus, the build system searches, in order, from the following directories,
-                            which are assumed to be a subdirectories of the directory in which the
-                            recipe file resides:
+                            Thus, the build system searches, in order, from the 
+                            following directories, which are assumed to be a 
+                            subdirectories of the directory in which the
+                            recipe file (<filename>.bb</filename>) or 
+                            append file (<filename>.bbappend</filename>) 
+                            resides:
                             <itemizedlist>
-                                <listitem><para><emphasis><filename>${PN}</filename> -</emphasis> The recipe name
-                                    with any special suffix or prefix, if applicable.
-                                    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,
-                                    <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}${<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>
-                                <listitem><para><emphasis><filename>${P}</filename> -</emphasis>
-                                    <filename>${PN}-${PV}</filename>.
-                                    The recipe name and version (i.e. <filename>bash-4.2</filename>).
-                                    </para></listitem>
-                                <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis> The
-                                    base recipe name without any special suffix or version numbers.
+                                <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis>
+                                    The base recipe name without any special 
+                                    suffix or version numbers.
                                     </para></listitem>
                                 <listitem><para><emphasis><filename>${BP}</filename> -</emphasis>
                                     <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
-                                    resides.</para></listitem>
-                                <listitem><para><emphasis>Directory -</emphasis> The directory itself in which the recipe
-                                    resides.</para></listitem>
-                            </itemizedlist></para></listitem>
+                                    The base recipe name and version but without 
+                                    any special package name suffix.
+                                    </para></listitem>
+                                <listitem><para><emphasis>files -</emphasis> 
+                                    Files within a directory, which is named 
+                                    <filename>files</filename> and is also 
+                                    alongside the recipe or append file.
+                                    </para></listitem>
+                            </itemizedlist>
+                            <note>
+                                If you want the build system to pick up files 
+                                specified through a 
+                                <filename>SRC_URI</filename>
+                                statement from your append file, you need to be
+                                sure to extend the 
+                                <filename>FILESPATH</filename>
+                                variable by also using the 
+                                <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                                variable from within your append file.
+                            </note>
+                            </para></listitem>
                         <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
                             Bazaar revision control repository.</para></listitem>
                         <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
@@ -3249,9 +3675,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     as set in the <filename>meta/conf/bitbake.conf</filename> file
                     is:
                     <literallayout class='monospaced'>
-     STAMP = "${TMPDIR}/stamps/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
+     STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
                     </literallayout>
-                    See <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
+                    See <link linkend='var-STAMPS_DIR'><filename>STAMPS_DIR</filename></link>,
                     <link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>,
                     <link linkend='var-PN'><filename>PN</filename></link>,
                     <link linkend='var-EXTENDPE'><filename>EXTENDPE</filename></link>,
@@ -3262,6 +3688,17 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-STAMPS_DIR'><glossterm>STAMPS_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the base directory in which the OpenEmbedded 
+                    build system places stamps.
+                    The default directory is 
+                    <filename>${TMPDIR}/stamps</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
             <glossdef>
                 <para>The short (72 characters or less) summary of the binary package for packaging
@@ -3275,20 +3712,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SYSROOT_PREPROCESS_FUNCS'><glossterm>SYSROOT_PREPROCESS_FUNCS</glossterm>
+            <glossdef>
+                <para>
+                    A list of functions to execute after files are staged into 
+                    the sysroot.
+                    These functions are usually used to apply additional 
+                    processing on the staged files, or to stage additional 
+                    files.
+                </para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-t'><title>T</title>
 
         <glossentry id='var-T'><glossterm>T</glossterm>
             <glossdef>
-                <para>This variable points to a directory were BitBake places temporary
-                    files when building a particular package.
-                    It is typically set as follows:
+                <para>This variable points to a directory were BitBake places 
+                    temporary files, which consist mostly of task logs and 
+                    scripts, when building a particular recipe. 
+                    The variable is typically set as follows:
                     <literallayout class='monospaced'>
-     T = ${WORKDIR}/temp
+     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 
+                    recipe.
                     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,

documentation/ref-manual/resources.xml

@@ -112,9 +112,11 @@
 
     <para>
         The Yocto Project gladly accepts contributions.
-        You can submit changes to the project either by creating and sending pull requests,
+        You can submit changes to the project either by creating and sending 
+        pull requests,
         or by submitting patches through email.
-        For information on how to do both, see the
+        For information on how to do both as well as information on how
+        to find out who is the maintainer for areas of code, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
         section in the Yocto Project Development Manual.
     </para>

documentation/ref-manual/technical-details.xml

@@ -373,9 +373,7 @@
             change that changes the task hash, automatically
             causing the task to be run again.
             This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
-            values and changes to metadata automatically ripple across the build.
-            Currently, this behavior is not the default behavior for <filename>OE-Core</filename>
-            but is the default in <filename>poky</filename>.
+            values and changes to Metadata automatically ripple across the build.
         </para>
 
         <para>

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

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

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

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

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

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

meta-yocto/classes/poky-sanity.bbclass

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

meta-yocto/conf/distro/poky.conf

@@ -1,9 +1,9 @@
 DISTRO = "poky"
-DISTRO_NAME = "Poky 8.0 (Yocto Project 1.3 Reference Distro)"
-DISTRO_VERSION = "1.3+snapshot-${DATE}"
+DISTRO_NAME = "Poky 9.0 (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>"
 
@@ -70,9 +70,11 @@ CONNECTIVITY_CHECK_URIS ?= " \
              http://bugzilla.yoctoproject.org/report.cgi"
 
 SANITY_TESTED_DISTROS ?= " \
+            Yocto-1.3 \n \
             Yocto-1.2 \n \
             Poky-1.2 \n \
             Poky-1.3 \n \
+            Poky-1.4 \n \
             Ubuntu-10.04 \n \
             Ubuntu-11.10 \n \
             Ubuntu-12.04 \n \
@@ -84,11 +86,13 @@ SANITY_TESTED_DISTROS ?= " \
             CentOS-5.7 \n \
             CentOS-5.8 \n \
             CentOS-6.3 \n \
+            CentOS-6.4 \n \
             Debian-6.0 \n \
             Debian-7.0 \n \
             SUSE-LINUX-11.4 \n \
             SUSE-LINUX-12.1 \n \
             SUSE-LINUX-12.2 \n \
+            openSUSE-project-12.3 \n \
 	    "
 
 # Default hash policy for distro

meta/classes/icecc.bbclass

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

meta/classes/image.bbclass

@@ -116,8 +116,9 @@ python () {
     d.setVar('IMAGE_FEATURES', ' '.join(list(remain_features)))
 
     if d.getVar('BB_WORKERCONTEXT', True) is not None:
-        runtime_mapping_rename("PACKAGE_INSTALL", d)
-        runtime_mapping_rename("PACKAGE_INSTALL_ATTEMPTONLY", d)
+        pn = d.getVar('PN', True)
+        runtime_mapping_rename("PACKAGE_INSTALL", pn, d)
+        runtime_mapping_rename("PACKAGE_INSTALL_ATTEMPTONLY", pn, d)
 
     # Ensure we have the vendor list for complementary package handling
     ml_vendor_list = ""

meta/classes/insane.bbclass

@@ -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.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() {
 	#
@@ -200,6 +200,7 @@ kernel_do_install() {
 		sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g' $kerneldir/tools/perf/Makefile
 	fi
 }
+do_install[prefuncs] += "package_get_auto_pr"
 
 sysroot_stage_all_append() {
 	sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
@@ -289,6 +290,35 @@ 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() {
@@ -302,13 +332,13 @@ do_sizecheck() {
 }
 do_sizecheck[dirs] = "${B}"
 
-addtask sizecheck before do_install after do_kernel_link_vmlinux
+addtask sizecheck before do_install after do_strip
 
-KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
+KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
 # Don't include the DATETIME variable in the sstate package signatures
 KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
 KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}"
-MODULE_IMAGE_BASE_NAME ?= "modules-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
+MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
 MODULE_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
 MODULE_TARBALL_BASE_NAME ?= "${MODULE_IMAGE_BASE_NAME}.tgz"
 # Don't include the DATETIME variable in the sstate package signatures
@@ -343,6 +373,7 @@ addtask uboot_mkimage before do_install after do_compile
 kernel_do_deploy() {
 	install -m 0644 ${KERNEL_OUTPUT} ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
 	if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
+		mkdir -p ${D}/lib
 		tar -cvzf ${DEPLOYDIR}/${MODULE_TARBALL_BASE_NAME} -C ${D} lib
 		ln -sf ${MODULE_TARBALL_BASE_NAME}.bin ${MODULE_TARBALL_SYMLINK_NAME}
 	fi
@@ -356,6 +387,7 @@ kernel_do_deploy() {
 	cd -
 }
 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
+do_deploy[prefuncs] += "package_get_auto_pr"
 
 addtask deploy before do_build after do_install
 

meta/classes/multilib.bbclass

@@ -100,6 +100,7 @@ python __anonymous () {
     clsextend.map_regexp_variable("PACKAGES_DYNAMIC")
     clsextend.map_variable("PACKAGE_INSTALL")
     clsextend.map_variable("INITSCRIPT_PACKAGES")
+    clsextend.map_variable("USERADD_PACKAGES")
 }
 
 PACKAGEFUNCS_append = "do_package_qa_multilib"

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

@@ -332,24 +332,27 @@ def copydebugsources(debugsrcdir, d):
 # Package data handling routines
 #
 
-def get_package_mapping (pkg, d):
+def get_package_mapping (pkg, basepkg, d):
     import oe.packagedata
 
     data = oe.packagedata.read_subpkgdata(pkg, d)
     key = "PKG_%s" % pkg
 
     if key in data:
+        # Have to avoid undoing the write_extra_pkgs(global_variants...)
+        if bb.data.inherits_class('allarch', d) and data[key] == basepkg:
+            return pkg
         return data[key]
 
     return pkg
 
-def runtime_mapping_rename (varname, d):
+def runtime_mapping_rename (varname, pkg, d):
     #bb.note("%s before: %s" % (varname, d.getVar(varname, True)))
 
     new_depends = {}
     deps = bb.utils.explode_dep_versions2(d.getVar(varname, True) or "")
     for depend in deps:
-        new_depend = get_package_mapping(depend, d)
+        new_depend = get_package_mapping(depend, pkg, d)
         new_depends[new_depend] = deps[depend]
 
     d.setVar(varname, bb.utils.join_deps(new_depends, commasep=False))
@@ -943,6 +946,8 @@ python populate_packages () {
         for file in files:
             if os.path.isabs(file):
                 file = '.' + file
+            if not file.startswith("./"):
+                file = './' + file
             if not cpath.islink(file):
                 if cpath.isdir(file):
                     newfiles =  [ os.path.join(file,x) for x in os.listdir(file) ]
@@ -1775,7 +1780,7 @@ python package_depchains() {
 
 # Since bitbake can't determine which variables are accessed during package
 # iteration, we need to list them here:
-PACKAGEVARS = "FILES RDEPENDS RRECOMMENDS SUMMARY DESCRIPTION RSUGGESTS RPROVIDES RCONFLICTS PKG ALLOW_EMPTY pkg_postinst pkg_postrm INITSCRIPT_NAME INITSCRIPT_PARAMS DEBIAN_NOAUTONAME ALTERNATIVE PKGE PKGV PKGR"
+PACKAGEVARS = "FILES RDEPENDS RRECOMMENDS SUMMARY DESCRIPTION RSUGGESTS RPROVIDES RCONFLICTS PKG ALLOW_EMPTY pkg_postinst pkg_postrm INITSCRIPT_NAME INITSCRIPT_PARAMS DEBIAN_NOAUTONAME ALTERNATIVE PKGE PKGV PKGR USERADD_PARAM GROUPADD_PARAM"
 
 def gen_packagevar(d):
     ret = []
@@ -1942,10 +1947,11 @@ def mapping_rename_hook(d):
     Rewrite variables to account for package renaming in things
     like debian.bbclass or manual PKG variable name changes
     """
-    runtime_mapping_rename("RDEPENDS", d)
-    runtime_mapping_rename("RRECOMMENDS", d)
-    runtime_mapping_rename("RSUGGESTS", d)
-    runtime_mapping_rename("RPROVIDES", d)
-    runtime_mapping_rename("RREPLACES", d)
-    runtime_mapping_rename("RCONFLICTS", d)
+    pkg = d.getVar("PKG", True)
+    runtime_mapping_rename("RDEPENDS", pkg, d)
+    runtime_mapping_rename("RRECOMMENDS", pkg, d)
+    runtime_mapping_rename("RSUGGESTS", pkg, d)
+    runtime_mapping_rename("RPROVIDES", pkg, d)
+    runtime_mapping_rename("RREPLACES", pkg, d)
+    runtime_mapping_rename("RCONFLICTS", pkg, d)
 

meta/classes/package_ipk.bbclass

@@ -85,6 +85,7 @@ package_install_internal_ipk() {
 	local package_multilib="${INSTALL_PACKAGES_MULTILIB_IPK}"
 
 	mkdir -p ${target_rootfs}${OPKGLIBDIR}/opkg
+	touch ${target_rootfs}${OPKGLIBDIR}/opkg/status
 
 	local ipkg_args="${OPKG_ARGS}"
 

meta/classes/package_rpm.bbclass

@@ -605,7 +605,14 @@ python write_specfile () {
                             pv = subd['PV']
                             pkgv = subd['PKGV']
                             reppv = pkgv.replace('-', '+')
-                            verlist.append(ver.replace(pv, reppv).replace(pkgv, reppv))
+                            ver = ver.replace(pv, reppv).replace(pkgv, reppv)
+                        if 'PKGR' in subd:
+                            # Make sure PKGR rather than PR in ver
+                            pr = '-' + subd['PR']
+                            pkgr = '-' + subd['PKGR']
+                            if pkgr not in ver:
+                                ver = ver.replace(pr, pkgr)
+                        verlist.append(ver)
                     else:
                         verlist.append(ver)
                 newdeps_dict[dep] = verlist

meta/classes/packagegroup.bbclass

@@ -38,3 +38,10 @@ do_configure[noexec] = "1"
 do_compile[noexec] = "1"
 do_install[noexec] = "1"
 do_populate_sysroot[noexec] = "1"
+
+python () {
+    initman = d.getVar("VIRTUAL-RUNTIME_init_manager", True)
+    if initman and initman in ['sysvinit', 'systemd'] and not base_contains('DISTRO_FEATURES', initman, True, False, d):
+        bb.fatal("Please ensure that your setting of VIRTUAL-RUNTIME_init_manager (%s) matches the entries enabled in DISTRO_FEATURES" % initman)
+}
+

meta/classes/populate_sdk_base.bbclass

@@ -30,7 +30,8 @@ EXCLUDE_FROM_WORLD = "1"
 SDK_PACKAGING_FUNC ?= "create_shar"
 
 fakeroot python do_populate_sdk() {
-    runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", d)
+    pn = d.getVar('PN', True)
+    runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", pn, d)
 
     bb.build.exec_func("populate_sdk_image", d)
 

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/sanity.bbclass

@@ -4,8 +4,34 @@
 
 SANITY_REQUIRED_UTILITIES ?= "patch diffstat makeinfo git bzip2 tar gzip gawk chrpath wget cpio"
 
-python check_bblayers_conf() {
-    bblayers_fn = os.path.join(d.getVar('TOPDIR', True), 'conf/bblayers.conf')
+def bblayers_conf_file(d):
+    return os.path.join(d.getVar('TOPDIR', True), 'conf/bblayers.conf')
+
+def sanity_conf_read(fn):
+    with open(fn, 'r') as f:
+        lines = f.readlines()
+    return lines
+
+def sanity_conf_find_line(pattern, lines):
+    import re
+    return next(((index, line)
+        for index, line in enumerate(lines)
+        if re.search(pattern, line)), (None, None))
+
+def sanity_conf_update(fn, lines, version_var_name, new_version):
+    index, line = sanity_conf_find_line(version_var_name, lines)
+    lines[index] = '%s = "%d"\n' % (version_var_name, new_version)
+    with open(fn, "w") as f:
+        f.write(''.join(lines))
+
+EXPORT_FUNCTIONS bblayers_conf_file sanity_conf_read sanity_conf_find_line sanity_conf_update
+
+# Functions added to this variable MUST throw an exception (or sys.exit()) unless they
+# successfully changed LCONF_VERSION in bblayers.conf
+BBLAYERS_CONF_UPDATE_FUNCS += "oecore_update_bblayers"
+
+python oecore_update_bblayers() {
+    # bblayers.conf is out of date, so see if we can resolve that
 
     current_lconf = int(d.getVar('LCONF_VERSION', True))
     if not current_lconf:
@@ -13,21 +39,15 @@ python check_bblayers_conf() {
     lconf_version = int(d.getVar('LAYER_CONF_VERSION', True))
     lines = []
 
-    import re
-    def find_line(pattern, lines):
-        return next(((index, line)
-            for index, line in enumerate(lines)
-            if re.search(pattern, line)), (None, None))
-
     if current_lconf < 4:
         sys.exit()
 
-    with open(bblayers_fn, 'r') as f:
-        lines = f.readlines()
+    bblayers_fn = bblayers_conf_file(d)
+    lines = sanity_conf_read(bblayers_fn)
 
-    if current_lconf == 4:
+    if current_lconf == 4 and lconf_version > 4:
         topdir_var = '$' + '{TOPDIR}'
-        index, bbpath_line = find_line('BBPATH', lines)
+        index, bbpath_line = sanity_conf_find_line('BBPATH', lines)
         if bbpath_line:
             start = bbpath_line.find('"')
             if start != -1 and (len(bbpath_line) != (start + 1)):
@@ -41,17 +61,17 @@ python check_bblayers_conf() {
             else:
                 sys.exit()
         else:
-            index, bbfiles_line = find_line('BBFILES', lines)
+            index, bbfiles_line = sanity_conf_find_line('BBFILES', lines)
             if bbfiles_line:
                 lines.insert(index, 'BBPATH = "' + topdir_var + '"\n')
             else:
                 sys.exit()
 
-        index, line = find_line('LCONF_VERSION', lines)
         current_lconf += 1
-        lines[index] = 'LCONF_VERSION = "%d"\n' % current_lconf
-        with open(bblayers_fn, "w") as f:
-            f.write(''.join(lines))
+        sanity_conf_update(bblayers_fn, lines, 'LCONF_VERSION', current_lconf)
+        return
+
+    sys.exit()
 }
 
 def raise_sanity_error(msg, d, network_error=False):
@@ -387,18 +407,25 @@ def check_sanity(sanity_data):
     conf_version =  sanity_data.getVar('LOCALCONF_VERSION', True)
 
     if current_conf != conf_version:
-        messages = messages + "Your version of local.conf was generated from an older version of local.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/local.conf ${COREBASE}/meta*/conf/local.conf.sample\" is a good way to visualise the changes.\n"
+        messages = messages + "Your version of local.conf was generated from an older/newer version of local.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/local.conf ${COREBASE}/meta*/conf/local.conf.sample\" is a good way to visualise the changes.\n"
 
     # Check bblayers.conf is valid
     current_lconf = sanity_data.getVar('LCONF_VERSION', True)
     lconf_version = sanity_data.getVar('LAYER_CONF_VERSION', True)
     if current_lconf != lconf_version:
-        try:
-            bb.build.exec_func("check_bblayers_conf", sanity_data)
-            bb.note("Your conf/bblayers.conf has been automatically updated.")
-            reparse = True
-        except Exception:
-            messages = messages + "Your version of bblayers.conf was generated from an older version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/bblayers.conf ${COREBASE}/meta*/conf/bblayers.conf.sample\" is a good way to visualise the changes.\n"
+        funcs = sanity_data.getVar('BBLAYERS_CONF_UPDATE_FUNCS', True).split()
+        for func in funcs:
+            success = True
+            try:
+                bb.build.exec_func(func, sanity_data)
+            except Exception:
+                success = False
+            if success:
+                bb.note("Your conf/bblayers.conf has been automatically updated.")
+                reparse = True
+                break
+        if not reparse:
+            messages = messages + "Your version of bblayers.conf was generated from an older/newer version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/bblayers.conf ${COREBASE}/meta*/conf/bblayers.conf.sample\" is a good way to visualise the changes.\n"
 
     # If we have a site.conf, check it's valid
     if check_conf_exists("conf/site.conf", sanity_data):
@@ -454,7 +481,7 @@ def check_sanity(sanity_data):
         messages = messages + "Parsed PATH is " + str(paths) + "\n"
 
     bbpaths = sanity_data.getVar('BBPATH', True).split(":")
-    if "." in bbpaths or "" in bbpaths:
+    if ("." in bbpaths or "" in bbpaths) and not reparse:
         # TODO: change the following message to fatal when all BBPATH issues
         # are fixed
         bb.warn("BBPATH references the current directory, either through "    \

meta/classes/update-alternatives.bbclass

@@ -169,7 +169,7 @@ def gen_updatealternativesvardeps(d):
 
 def ua_extend_depends(d):
     if not 'virtual/update-alternatives' in d.getVar('PROVIDES', True):
-        d.appendVar('DEPENDS', ' virtual/update-alternatives')
+        d.appendVar('DEPENDS', ' virtual/${MLPREFIX}update-alternatives')
 
 python __anonymous() {
     # Update Alternatives only works on target packages...

meta/conf/distro/include/seperatebuilddir.inc

@@ -305,7 +305,8 @@ B_pn-libmad = "${SEPB}"
 B_pn-libmatchbox = "${SEPB}"
 B_pn-libmpc = "${SEPB}"
 B_pn-libmpc-native = "${SEPB}"
-B_pn-libmusicbrainz = "${SEPB}"
+# CMake Error: The source directory "[...]libmusicbrainz-5.0.1[...]/build" does not appear to contain CMakeLists.txt.
+#B_pn-libmusicbrainz = "${SEPB}"
 # Not automake and no support for out of tree
 #B_pn-libnewt = "${SEPB}"
 B_pn-libnfsidmap = "${SEPB}"
@@ -659,6 +660,7 @@ B_pn-sysfsutils = "${SEPB}"
 B_pn-sysprof = "${SEPB}"
 # No automake, no separate build support
 #B_pn-sysstat = "${SEPB}"
+B_pn-systemd = "${SEPB}"
 B_pn-systemtap = "${SEPB}"
 B_pn-systemtap-native = "${SEPB}"
 B_pn-tar = "${SEPB}"
@@ -773,4 +775,3 @@ B_pn-xz-native = "${SEPB}"
 B_pn-yasm = "${SEPB}"
 B_pn-yasm-native = "${SEPB}"
 B_pn-zaurusd = "${SEPB}"
-

meta/conf/multilib.conf

@@ -14,3 +14,5 @@ INHERIT += "multilib_global"
 BBCLASSEXTEND_append = " ${MULTILIBS}"
 
 MULTILIB_GLOBAL_VARIANTS  = "lib32 lib64 libx32"
+
+OPKG_ARGS_append = " --force-maintainer --force-overwrite"

meta/lib/oe/terminal.py

@@ -107,6 +107,7 @@ class Screen(Terminal):
 
 class TmuxRunning(Terminal):
     """Open a new pane in the current running tmux window"""
+    name = 'tmux-running'
     command = 'tmux split-window {command}'
     priority = 2.75
 
@@ -119,7 +120,7 @@ class TmuxRunning(Terminal):
 
         Terminal.__init__(self, sh_cmd, title, env, d)
 
-class TmuxNewSession(Terminal):
+class Tmux(Terminal):
     """Start a new tmux session and window"""
     command = 'tmux new -d -s devshell -n devshell {command}'
     priority = 0.75

meta/recipes-bsp/pcmciautils/pcmciautils.inc

@@ -5,7 +5,7 @@ SECTION = "kernel/userland"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
-DEPENDS = "sysfsutils flex-native"
+DEPENDS = "udev sysfsutils flex-native"
 RDEPENDS_${PN} = "udev module-init-tools"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/utils/kernel/pcmcia/pcmciautils-${PV}.tar.bz2"
@@ -16,8 +16,8 @@ export HOSTCC = "${BUILD_CC}"
 export etcdir = "${sysconfdir}"
 export sbindir = "${base_sbindir}"
 export pcmciaconfdir = "${sysconfdir}/pcmcia"
-export udevdir = "${base_libdir}/udev"
-export udevrulesdir = "${nonarch_base_libdir}/udev/rules.d"
+export udevdir = "`pkg-config --variable=udevdir udev`"
+export udevrulesdir = "`pkg-config --variable=udevdir udev`/rules.d"
 export UDEV = "1"
 LD = "${CC}"
 CFLAGS =+ "-I${S}/src"

meta/recipes-bsp/pcmciautils/pcmciautils_018.bb

@@ -7,5 +7,5 @@ SRC_URI[sha256sum] = "79e6ae441278e178c07501d492394ed2c0326fdb66894f6d040ec811b0
 
 PR = "r1"
 
-FILES_${PN}-dbg += "${base_libdir}/udev/.debug"
-FILES_${PN} += "${base_libdir}/udev ${nonarch_base_libdir}/udev"
+FILES_${PN}-dbg += "*/udev/.debug"
+FILES_${PN} += "*/udev"

meta/recipes-connectivity/avahi/avahi.inc

@@ -136,11 +136,7 @@ do_install() {
 
 pkg_postinst_avahi-daemon () {
 if [ -z "$D" ]; then
-	DBUSPID=`pidof dbus-daemon`
-
-	if [ "x$DBUSPID" != "x" ]; then
-		/etc/init.d/dbus-1 force-reload
-	fi
+	killall -q -HUP dbus-daemon || true
 fi
 }
 

meta/recipes-connectivity/bluez/bluez4.inc

@@ -39,7 +39,7 @@ EXTRA_OECONF = "\
   --disable-cups \
   --enable-test \
   --enable-datafiles \
-  --with-udevdir=${base_libdir}/udev \
-  --with-udevrulesdir=${nonarch_base_libdir}/udev/rules.d \
+  --with-udevdir=`pkg-config --variable=udevdir udev` \
+  --with-udevrulesdir=`pkg-config --variable=udevdir udev`/rules.d \
 "
 

meta/recipes-connectivity/bluez/bluez4_4.101.bb

@@ -34,5 +34,5 @@ FILES_${PN}-dev += "\
 FILES_${PN}-dbg += "\
   ${libdir}/bluetooth/plugins/.debug \
   ${libdir}/*/.debug \
-  ${base_libdir}/udev/.debug \
+  */udev/.debug \
   "

meta/recipes-connectivity/connman/connman.inc

@@ -20,7 +20,7 @@ DEPENDS  = "dbus glib-2.0 ppp iptables gnutls \
             ${@base_contains('DISTRO_FEATURES', '3g','ofono', '', d)} \
             "
 
-INC_PR = "r1"
+INC_PR = "r19"
 
 TIST = "--enable-tist"
 TIST_powerpc = ""

meta/recipes-connectivity/openssl/openssl-1.0.1e/debian/man-section.patch

@@ -4,7 +4,7 @@ Index: openssl-1.0.0c/Makefile.org
 ===================================================================
 --- openssl-1.0.0c.orig/Makefile.org	2010-12-12 16:11:37.000000000 +0100
 +++ openssl-1.0.0c/Makefile.org	2010-12-12 16:13:28.000000000 +0100
-@@ -134,7 +134,8 @@
+@@ -160,7 +160,8 @@
  MANDIR=/usr/share/man
  MAN1=1
  MAN3=3
@@ -14,7 +14,7 @@ Index: openssl-1.0.0c/Makefile.org
  HTMLSUFFIX=html
  HTMLDIR=$(OPENSSLDIR)/html
  SHELL=/bin/sh
-@@ -606,7 +607,7 @@
+@@ -651,7 +652,7 @@
  		echo "installing man$$sec/$$fn.$${sec}$(MANSUFFIX)"; \
  		(cd `$(PERL) util/dirname.pl $$i`; \
  		sh -c "$$pod2man \
@@ -23,7 +23,7 @@ Index: openssl-1.0.0c/Makefile.org
  			--release=$(VERSION) `basename $$i`") \
  			>  $(INSTALL_PREFIX)$(MANDIR)/man$$sec/$$fn.$${sec}$(MANSUFFIX); \
  		$(PERL) util/extract-names.pl < $$i | \
-@@ -623,7 +624,7 @@
+@@ -668,7 +669,7 @@
  		echo "installing man$$sec/$$fn.$${sec}$(MANSUFFIX)"; \
  		(cd `$(PERL) util/dirname.pl $$i`; \
  		sh -c "$$pod2man \

meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-2.0.inc

@@ -84,9 +84,5 @@ pkg_postinst_wpa-supplicant () {
 		exit 0
 	fi
 
-	DBUSPID=`pidof dbus-daemon`
-
-	if [ "x$DBUSPID" != "x" ]; then
-		/etc/init.d/dbus-1 reload || true
-	fi
+	killall -q -HUP dbus-daemon || true
 }

meta/recipes-core/busybox/busybox-1.20.2/fail_on_no_media.patch

@@ -23,7 +23,7 @@ Index: busybox-1.20.2/util-linux/mount.c
 +		 * Break if there is no media, no point retrying for all
 +		 * fs types since there is no media available
 +		 */
-+		if ((rc == -1) && (errno == ENOMEDIUM || errno == ENODEV)) {
++		if (rc == -1 && errno == ENOMEDIUM) {
 +			bb_perror_msg_and_die("mounting %s on %s failed", mp->mnt_fsname, mp->mnt_dir);
 +		}
  		if (!rc || (vfsflags & MS_RDONLY) || (errno != EACCES && errno != EROFS))

meta/recipes-core/busybox/busybox.inc

@@ -34,7 +34,7 @@ INITSCRIPT_NAME_${PN}-syslog = "syslog"
 INITSCRIPT_NAME_${PN}-udhcpd = "busybox-udhcpd" 
 
 SYSTEMD_PACKAGES = "${PN}-syslog"
-SYSTEMD_SERVICE_${PN}-syslog = "${PN}-syslog.service"
+SYSTEMD_SERVICE_${PN}-syslog = "busybox-syslog.service"
 
 CONFFILES_${PN}-syslog = "${sysconfdir}/syslog-startup.conf.${BPN}"
 CONFFILES_${PN}-mdev = "${sysconfdir}/mdev.conf"
@@ -153,14 +153,14 @@ do_install () {
 
 	install -d ${D}${sysconfdir}/init.d
 
-	if ! grep -q "CONFIG_FEATURE_INDIVIDUAL=y" ${WORKDIR}/defconfig; then
+	if ! grep -q "CONFIG_FEATURE_INDIVIDUAL=y" ${B}/.config; then
 		# Install /bin/busybox, and the /bin/sh link so the postinst script
 		# can run. Let update-alternatives handle the rest.
 		install -d ${D}${base_bindir}
-		if grep -q "CONFIG_FEATURE_SUID=y" ${WORKDIR}/defconfig; then
-			install -m 4755 ${S}/busybox ${D}${base_bindir}
+		if grep -q "CONFIG_FEATURE_SUID=y" ${B}/.config; then
+			install -m 4755 ${B}/busybox ${D}${base_bindir}
 		else
-			install -m 0755 ${S}/busybox ${D}${base_bindir}
+			install -m 0755 ${B}/busybox ${D}${base_bindir}
 		fi
 		ln -sf busybox ${D}${base_bindir}/sh
 	else
@@ -183,36 +183,37 @@ do_install () {
 		fi
 	fi
 
-	if grep -q "CONFIG_SYSLOGD=y" ${WORKDIR}/defconfig; then
+	if grep -q "CONFIG_SYSLOGD=y" ${B}/.config; then
 		install -m 0755 ${WORKDIR}/syslog ${D}${sysconfdir}/init.d/syslog.${BPN}
 		install -m 644 ${WORKDIR}/syslog-startup.conf ${D}${sysconfdir}/syslog-startup.conf.${BPN}
 	fi
-	if grep "CONFIG_CROND=y" ${WORKDIR}/defconfig; then
+	if grep "CONFIG_CROND=y" ${B}/.config; then
 		install -m 0755 ${WORKDIR}/busybox-cron ${D}${sysconfdir}/init.d/
 	fi
-	if grep "CONFIG_HTTPD=y" ${WORKDIR}/defconfig; then
+	if grep "CONFIG_HTTPD=y" ${B}/.config; then
 		install -m 0755 ${WORKDIR}/busybox-httpd ${D}${sysconfdir}/init.d/
 		install -d ${D}/srv/www
 	fi
-	if grep "CONFIG_UDHCPD=y" ${WORKDIR}/defconfig; then
+	if grep "CONFIG_UDHCPD=y" ${B}/.config; then
 		install -m 0755 ${WORKDIR}/busybox-udhcpd ${D}${sysconfdir}/init.d/
 	fi
-	if grep "CONFIG_HWCLOCK=y" ${WORKDIR}/defconfig; then
+	if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
 		install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
 	fi
-	if grep "CONFIG_UDHCPC=y" ${WORKDIR}/defconfig; then
+	if grep "CONFIG_UDHCPC=y" ${B}/.config; then
 		install -d ${D}${sysconfdir}/udhcpc.d
 		install -d ${D}${datadir}/udhcpc
                 install -m 0755 ${WORKDIR}/simple.script ${D}${sysconfdir}/udhcpc.d/50default
 		install -m 0755 ${WORKDIR}/default.script ${D}${datadir}/udhcpc/default.script
 	fi
-	if grep "CONFIG_INETD=y" ${WORKDIR}/defconfig; then
+	if grep "CONFIG_INETD=y" ${B}/.config; then
 		install -m 0755 ${WORKDIR}/inetd ${D}${sysconfdir}/init.d/inetd.${BPN}
+		sed -i "s:/usr/sbin/:${sbindir}/:" ${D}${sysconfdir}/init.d/inetd.${BPN}
 		install -m 0644 ${WORKDIR}/inetd.conf ${D}${sysconfdir}/
 	fi
-        if grep "CONFIG_MDEV=y" ${WORKDIR}/defconfig; then
+        if grep "CONFIG_MDEV=y" ${B}/.config; then
                install -m 0755 ${WORKDIR}/mdev ${D}${sysconfdir}/init.d/mdev
-               if grep "CONFIG_FEATURE_MDEV_CONF=y" ${WORKDIR}/defconfig; then
+               if grep "CONFIG_FEATURE_MDEV_CONF=y" ${B}/.config; then
                        install -m 644 ${WORKDIR}/mdev.conf ${D}${sysconfdir}/mdev.conf
                fi
 	fi

meta/recipes-core/busybox/busybox_1.20.2.bb

@@ -1,5 +1,5 @@
 require busybox.inc
-PR = "r5"
+PR = "r7"
 
 SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
            file://B921600.patch \
@@ -32,7 +32,9 @@ SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
            file://busybox-klogd.service.in \
            file://testsuite-du-du-k-works-fix-false-positive.patch \
            file://strict-atime.patch \
-           file://fail_on_no_media.patch"
+           file://fail_on_no_media.patch \
+           file://inetd.conf \
+           file://inetd"
 
 SRC_URI[tarball.md5sum] = "e025414bc6cd79579cc7a32a45d3ae1c"
 SRC_URI[tarball.sha256sum] = "eb13ff01dae5618ead2ef6f92ba879e9e0390f9583bd545d8789d27cf39b6882"

meta/recipes-core/busybox/files/inetd

@@ -0,0 +1,33 @@
+#!/bin/sh
+#
+# start/stop inetd super server.
+
+if ! [ -x /usr/sbin/inetd ]; then
+	exit 0
+fi
+
+case "$1" in
+    start)
+	echo -n "Starting internet superserver:"
+	echo -n " inetd" ; start-stop-daemon -S -x /usr/sbin/inetd > /dev/null
+	echo "."
+	;;
+    stop)
+	echo -n "Stopping internet superserver:"
+	echo -n " inetd" ; start-stop-daemon -K -x /usr/sbin/inetd > /dev/null
+	echo "."
+	;;
+    restart)
+	echo -n "Restarting internet superserver:"
+	echo -n " inetd "
+	killall -HUP inetd
+	echo "."
+	;;
+    *)
+	echo "Usage: /etc/init.d/inetd {start|stop|restart}"
+	exit 1
+	;;
+esac
+
+exit 0
+

meta/recipes-core/busybox/files/inetd.conf

@@ -0,0 +1,20 @@
+# /etc/inetd.conf:  see inetd(8) for further informations.
+#
+# Internet server configuration database
+#
+# If you want to disable an entry so it isn't touched during
+# package updates just comment it out with a single '#' character.
+#
+# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
+#
+#:INTERNAL: Internal services
+#echo		stream	tcp	nowait	root	internal
+#echo		dgram	udp	wait	root	internal
+#chargen	stream	tcp	nowait	root	internal
+#chargen	dgram	udp	wait	root	internal
+#discard		stream	tcp	nowait	root	internal
+#discard		dgram	udp	wait	root	internal
+#daytime		stream	tcp	nowait	root	internal
+#daytime	dgram	udp	wait	root	internal
+#time		stream	tcp	nowait	root	internal
+#time		dgram	udp	wait	root	internal

meta/recipes-core/coreutils/coreutils_8.21.bb

@@ -29,7 +29,7 @@ EXTRA_OECONF_class-native = "--disable-acl --without-gmp"
 bindir_progs = "basename chcon cksum comm csplit cut dir dircolors dirname du \
                 env expand expr factor fmt fold groups head hostid id install \
                 join link logname md5sum mkfifo nice nl nohup nproc od paste pathchk \
-                pinky pr printenv printf ptx readlink runcon seq sha1sum sha224sum sha256sum \
+                pinky pr printenv printf ptx readlink realpath runcon seq sha1sum sha224sum sha256sum \
                 sha384sum sha512sum shred shuf sort split stat stdbuf sum tac tail tee test timeout\
                 tr truncate tsort tty unexpand uniq unlink uptime users vdir wc who whoami yes"
 

meta/recipes-core/images/build-appliance-image.bb

@@ -19,7 +19,7 @@ IMAGE_FSTYPES = "vmdk"
 
 inherit core-image
 
-SRCREV ?= "d823759b4594143d522eae0b2a2498436a6dcb1e"
+SRCREV ?= "dc529e1f18975ff33a1686dc9804a38204fd1bd0"
 SRC_URI = "git://git.yoctoproject.org/poky;protocol=git \
            file://Yocto_Build_Appliance.vmx \
            file://Yocto_Build_Appliance.vmxf \

meta/recipes-core/initrdscripts/files/init-install-efi.sh

@@ -66,7 +66,6 @@ rm -f /etc/udev/scripts/mount*
 umount /dev/${device}* 2> /dev/null || /bin/true
 
 mkdir -p /tmp
-cat /proc/mounts > /etc/mtab
 
 disk_size=$(parted /dev/${device} unit mb print | grep Disk | cut -d" " -f 3 | sed -e "s/MB//")
 

meta/recipes-core/initrdscripts/files/init-install.sh

@@ -78,7 +78,6 @@ if [ ! -b /dev/loop0 ] ; then
 fi
 
 mkdir -p /tmp
-cat /proc/mounts > /etc/mtab
 
 disk_size=$(parted /dev/${device} unit mb print | grep Disk | cut -d" " -f 3 | sed -e "s/MB//")
 

meta/recipes-core/initrdscripts/files/init-live.sh

@@ -12,7 +12,7 @@ UNIONFS="no"
 # Copied from initramfs-framework. The core of this script probably should be
 # turned into initramfs-framework modules to reduce duplication.
 udev_daemon() {
-	OPTIONS="/sbin/udev/udevd /sbin/udevd /lib/udev/udevd /lib/systemd/systemd-udevd"
+	OPTIONS="/sbin/udev/udevd /sbin/udevd /lib/udev/udevd /sbin/systemd/systemd-udevd /lib/systemd/systemd-udevd"
 
 	for o in $OPTIONS; do
 		if [ -x "$o" ]; then

meta/recipes-core/initrdscripts/initramfs-framework/udev

@@ -11,7 +11,7 @@ udev_shutdown_hook_handler() {
 }
 
 udev_daemon() {
-	OPTIONS="/sbin/udev/udevd /sbin/udevd /lib/udev/udevd /lib/systemd/systemd-udevd"
+	OPTIONS="/sbin/udev/udevd /sbin/udevd /lib/udev/udevd /sbin/systemd/systemd-udevd /lib/systemd/systemd-udevd"
 
 	for o in $OPTIONS; do
 		if [ -x "$o" ]; then

meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb

@@ -2,7 +2,7 @@ DESCRIPTION = "A live image init script"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 DEPENDS = "virtual/kernel"
-RDEPENDS_${PN} = "udev"
+RDEPENDS_${PN} = "udev udev-extraconf"
 SRC_URI = "file://init-live.sh"
 
 PR = "r11"

meta/recipes-core/initrdscripts/initramfs-live-install-efi_1.0.bb

@@ -3,7 +3,7 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 SRC_URI = "file://init-install-efi.sh"
 
-PR = "r0"
+PR = "r1"
 
 RDEPENDS_${PN} = "parted e2fsprogs-mke2fs dosfstools"
 

meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb

@@ -3,7 +3,7 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 SRC_URI = "file://init-install.sh"
 
-PR = "r8"
+PR = "r9"
 
 RDEPENDS_${PN} = "grub parted e2fsprogs-mke2fs"
 

meta/recipes-core/initscripts/initscripts-1.0/read-only-rootfs-hook.sh

@@ -4,16 +4,10 @@
 
 [ "$ROOTFS_READ_ONLY" = "no" ] && exit 0
 
-# Make sure unionfs is in /proc/filesystems
-if ! grep -q unionfs /proc/filesystems; then
-    echo "ERROR: unionfs not supported by kernel!"
-    exit 1
+if [ "$1" = "start" ] ; then
+	grep -q "tmpfs /var/volatile" /proc/mounts || mount /var/volatile
+	mkdir -p /var/volatile/lib
+	cp -a /var/lib/* /var/volatile/lib
+	mount --bind /var/volatile/lib /var/lib
 fi
 
-mkdir -p /var/volatile/lib
-mount -t unionfs -o dirs=/var/volatile/lib:/var/lib=ro none /var/lib
-
-if [ $? != 0 ]; then
-    echo "ERROR: Union mount failed!"
-    exit 1
-fi

meta/recipes-core/initscripts/initscripts_1.0.bb

@@ -118,7 +118,7 @@ do_install () {
 	update-rc.d -r ${D} bootmisc.sh start 55 S .
 	update-rc.d -r ${D} sysfs.sh start 02 S .
 	update-rc.d -r ${D} populate-volatile.sh start 37 S .
-	update-rc.d -r ${D} read-only-rootfs-hook.sh start 41 S .
+	update-rc.d -r ${D} read-only-rootfs-hook.sh start 29 S .
 	update-rc.d -r ${D} devpts.sh start 38 S .
 	if [ "${TARGET_ARCH}" = "arm" ]; then
 	        update-rc.d -r ${D} alignment.sh start 06 S .

meta/recipes-core/psplash/psplash_git.bb

@@ -56,8 +56,8 @@ python __anonymous() {
         ep = '%s%s' % (mlprefix, p)
         epsplash = '%s%s' % (mlprefix, 'psplash')
         d.setVar("FILES_%s" % ep, "${bindir}/%s" % p)
-        d.setVar("ALTERNATIVE_%s" % ep, epsplash)
-        d.setVarFlag("ALTERNATIVE_TARGET_%s" % ep, epsplash, '${bindir}/%s' % p)
+        d.setVar("ALTERNATIVE_%s" % ep, 'psplash')
+        d.setVarFlag("ALTERNATIVE_TARGET_%s" % ep, 'psplash', '${bindir}/%s' % p)
         d.appendVar("RDEPENDS_%s" % ep, " %s" % pn)
         if p == "psplash-default":
             d.appendVar("RRECOMMENDS_%s" % pn, " %s" % ep)

meta/recipes-core/systemd/systemd/0001-configure-use-AC_CHECK_TOOL-for-objcopy-strings-and-.patch

@@ -0,0 +1,41 @@
+From d6f92bcbbae9a577adb9588c7b2783a5d0bf343d Mon Sep 17 00:00:00 2001
+From: Martin Jansa <Martin.Jansa@gmail.com>
+Date: Tue, 16 Apr 2013 14:20:41 +0200
+Subject: [PATCH] configure: use AC_CHECK_TOOL for objcopy, strings and gperf
+
+* using AC_PATH_TOOL does not allow to override it from shell environment
+  which is useful when cross-compiling
+* with external toolchain I have different HOST_PREFIX and HOST_SYS
+  AC_PATH_TOOL is using HOST_SYS as prefix and fails to find objcopy
+  which is available only as ${TARGET_PREFIX}objcopy then it tries
+  objcopy without prefix which is found on host, but that objcopy
+  does not work for !host (e.g. arm when building on x86) libs
+
+Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
+Upstream-Status: Submitted
+http://lists.freedesktop.org/archives/systemd-devel/2013-April/010468.html
+
+---
+ configure.ac | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 33b0ca9..519f1a9 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -86,9 +86,9 @@ GOBJECT_INTROSPECTION_CHECK([1.31.1])
+    AM_CONDITIONAL([HAVE_INTROSPECTION], [false])
+    enable_introspection=no])
+ 
+-AC_PATH_TOOL(OBJCOPY, objcopy)
+-AC_PATH_TOOL(STRINGS, strings)
+-AC_PATH_TOOL(GPERF, gperf)
++AC_CHECK_TOOL(OBJCOPY, objcopy)
++AC_CHECK_TOOL(STRINGS, strings)
++AC_CHECK_TOOL(GPERF, gperf)
+ if test -z "$GPERF" ; then
+         AC_MSG_ERROR([*** gperf not found])
+ fi
+-- 
+1.8.1.5
+

meta/recipes-core/systemd/systemd/init

@@ -15,7 +15,7 @@ export TZ=/etc/localtime
 
 [ -d /sys/class ] || exit 1
 [ -r /proc/mounts ] || exit 1
-[ -x /lib/systemd/systemd-udevd ] || exit 1
+[ -x @UDEVD@ ] || exit 1
 [ -f /etc/default/udev-cache ] && . /etc/default/udev-cache
 [ -f /etc/udev/udev.conf ] && . /etc/udev/udev.conf
 
@@ -43,6 +43,9 @@ case "$1" in
     [ -e /dev/shm ] || mkdir -m 1777 /dev/shm
     mount -a -t tmpfs 2>/dev/null
     mkdir -p /var/volatile/run
+    if [ ! -e /run ]; then
+        ln -s /var/run /run
+    fi
 
     # cache handling
     if [ "$DEVCACHE" != "" ]; then
@@ -71,15 +74,15 @@ case "$1" in
 
     # trigger the sorted events
     echo -e '\000\000\000\000' > /proc/sys/kernel/hotplug
-    /lib/systemd/systemd-udevd -d
+    @UDEVD@ -d
 
-    /usr/bin/udevadm control --env=STARTUP=1
+    udevadm control --env=STARTUP=1
     if [ "$not_first_boot" != "" ];then
-            /usr/bin/udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus  --subsystem-nomatch=graphics	 --subsystem-nomatch=backlight --subsystem-nomatch=video4linux	--subsystem-nomatch=platform
-            (/usr/bin/udevadm settle --timeout=3; /usr/bin/udevadm control --env=STARTUP=)&
+            udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus  --subsystem-nomatch=graphics	 --subsystem-nomatch=backlight --subsystem-nomatch=video4linux	--subsystem-nomatch=platform
+            (udevadm settle --timeout=3; udevadm control --env=STARTUP=)&
     else
-            /usr/bin/udevadm trigger --action=add
-            /usr/bin/udevadm settle
+            udevadm trigger --action=add
+            udevadm settle
     fi
     ;;
   stop)

meta/recipes-core/systemd/systemd_199.bb

@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
 PROVIDES = "udev"
 
 PE = "1"
-PR = "r2"
+PR = "r3"
 
 DEPENDS = "kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl readline dbus libcap libcgroup tcp-wrappers glib-2.0"
 DEPENDS += "${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
@@ -27,6 +27,7 @@ SRC_URI = "http://www.freedesktop.org/software/systemd/systemd-${PV}.tar.xz \
            file://0002-readahead-chunk-on-spinning-media.patch \
            file://0003-readahead-cleanups.patch \
            file://0013-systemd-sysctl-Handle-missing-etc-sysctl.conf-proper.patch \
+           file://0001-configure-use-AC_CHECK_TOOL-for-objcopy-strings-and-.patch \
            file://199-firmware.patch \
            file://init \
           "
@@ -49,16 +50,23 @@ GTKDOC_DOCDIR = "${S}/docs/"
 PACKAGECONFIG ??= "xz"
 # Sign the journal for anti-tampering
 PACKAGECONFIG[gcrypt] = "--enable-gcrypt,--disable-gcrypt,libgcrypt"
+# regardless of PACKAGECONFIG, libgcrypt is always required to expand
+# the AM_PATH_LIBGCRYPT autoconf macro
+DEPENDS += "libgcrypt"
 # Compress the journal
 PACKAGECONFIG[xz] = "--enable-xz,--disable-xz,xz"
 
 CACHED_CONFIGUREVARS = "ac_cv_path_KILL=${base_bindir}/kill"
 
+# Helper variables to clarify locations.  This mirrors the logic in systemd's
+# build system.
+rootprefix ?= "${base_prefix}"
+rootlibdir ?= "${base_libdir}"
+rootlibexecdir = "${rootprefix}/lib"
+
 # The gtk+ tools should get built as a separate recipe e.g. systemd-tools
-EXTRA_OECONF = " --with-rootprefix=${base_prefix} \
-                 --with-rootlibdir=${base_libdir} \
-                 --sbindir=${base_sbindir} \
-                 --libexecdir=${base_libdir} \
+EXTRA_OECONF = " --with-rootprefix=${rootprefix} \
+                 --with-rootlibdir=${rootlibdir} \
                  ${@base_contains('DISTRO_FEATURES', 'pam', '--enable-pam', '--disable-pam', d)} \
                  --enable-xz \
                  --disable-manpages \
@@ -75,27 +83,29 @@ EXTRA_OECONF = " --with-rootprefix=${base_prefix} \
 # uclibc does not have NSS
 EXTRA_OECONF_append_libc-uclibc = " --disable-myhostname "
 
-# There's no docbook-xsl-native, so for the xsltproc check to false
 do_configure_prepend() {
 	export CPP="${HOST_PREFIX}cpp ${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
 
-	sed -i -e 's:=/root:=${ROOT_HOME}:g' units/*.service*
+	export STRINGS="${HOST_PREFIX}strings"
+	export GPERF="${HOST_PREFIX}gperf"
+
+	sed -i -e 's:=/root:=${ROOT_HOME}:g' ${S}/units/*.service*
 }
 
 do_install() {
 	autotools_do_install
 	install -d ${D}/${base_sbindir}
-	# provided by a seperate recipe
+	# Provided by a separate recipe
 	rm ${D}${systemd_unitdir}/system/serial-getty* -f
 
-	# provide support for initramfs
-	ln -s ${systemd_unitdir}/systemd ${D}/init
-	ln -s ${systemd_unitdir}/systemd-udevd ${D}/${base_sbindir}/udevd
+	# Provide support for initramfs
+	ln -s ${rootlibexecdir}/systemd/systemd ${D}/init
+	ln -s ${rootlibexecdir}/systemd/systemd-udevd ${D}/${base_sbindir}/udevd
 
-	# create dir for journal
+	# Create dir for journal
 	install -d ${D}${localstatedir}/log/journal
 
-	# create machine-id
+	# Create machine-id
 	# 20:12 < mezcalero> koen: you have three options: a) run systemd-machine-id-setup at install time, b) have / read-only and an empty file there (for stateless) and c) boot with / writable
 	touch ${D}${sysconfdir}/machine-id
 
@@ -108,11 +118,12 @@ do_install() {
 	if ${@base_contains('DISTRO_FEATURES','sysvinit','true','false',d)}; then
 		install -d ${D}${sysconfdir}/init.d
 		install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/systemd-udevd
+		sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd% ${D}${sysconfdir}/init.d/systemd-udevd
 	fi
 }
 
 python populate_packages_prepend (){
-    systemdlibdir = d.getVar("base_libdir", True)
+    systemdlibdir = d.getVar("rootlibdir", True)
     do_split_packages(d, systemdlibdir, '^lib(.*)\.so\.*', 'lib%s', 'Systemd %s library', extra_depends='', allow_links=True)
 }
 PACKAGES_DYNAMIC += "^lib(udev|gudev|systemd).*"
@@ -122,14 +133,14 @@ PACKAGES =+ "${PN}-gui ${PN}-vconsole-setup ${PN}-initramfs ${PN}-analyze ${PN}-
 USERADD_PACKAGES = "${PN}"
 GROUPADD_PARAM_${PN} = "-r lock; -r systemd-journal"
 
-FILES_${PN}-analyze = "${base_bindir}/systemd-analyze"
+FILES_${PN}-analyze = "${bindir}/systemd-analyze"
 
 FILES_${PN}-initramfs = "/init"
 RDEPENDS_${PN}-initramfs = "${PN}"
 
 FILES_${PN}-gui = "${bindir}/systemadm"
 
-FILES_${PN}-vconsole-setup = "${systemd_unitdir}/systemd-vconsole-setup \
+FILES_${PN}-vconsole-setup = "${rootlibexecdir}/systemd/systemd-vconsole-setup \
                               ${systemd_unitdir}/system/systemd-vconsole-setup.service \
                               ${systemd_unitdir}/system/sysinit.target.wants/systemd-vconsole-setup.service"
 
@@ -149,7 +160,7 @@ FILES_${PN} = " ${base_bindir}/* \
                 ${datadir}/dbus-1/services \
                 ${datadir}/dbus-1/system-services \
                 ${datadir}/polkit-1 \
-                ${datadir}/${PN} \
+                ${datadir}/${BPN} \
                 ${sysconfdir}/bash_completion.d/ \
                 ${sysconfdir}/binfmt.d/ \
                 ${sysconfdir}/dbus-1/ \
@@ -160,9 +171,8 @@ FILES_${PN} = " ${base_bindir}/* \
                 ${sysconfdir}/tmpfiles.d/ \
                 ${sysconfdir}/xdg/ \
                 ${sysconfdir}/init.d/README \
+                ${rootlibexecdir}/systemd/* \
                 ${systemd_unitdir}/* \
-                ${systemd_unitdir}/system/* \
-                /lib/udev/rules.d/99-systemd.rules \
                 ${base_libdir}/security/*.so \
                 ${libdir}/libnss_myhostname.so.2 \
                 /cgroup \
@@ -178,17 +188,16 @@ FILES_${PN} = " ${base_bindir}/* \
                 ${exec_prefix}/lib/modules-load.d \
                 ${exec_prefix}/lib/sysctl.d \
                 ${localstatedir} \
-                ${libexecdir} \
                 /lib/udev/rules.d/70-uaccess.rules \
                 /lib/udev/rules.d/71-seat.rules \
                 /lib/udev/rules.d/73-seat-late.rules \
                 /lib/udev/rules.d/99-systemd.rules \
                "
 
-FILES_${PN}-dbg += "${systemd_unitdir}/.debug ${systemd_unitdir}/*/.debug ${base_libdir}/security/.debug/"
+FILES_${PN}-dbg += "${rootlibdir}/.debug ${systemd_unitdir}/.debug ${systemd_unitdir}/*/.debug ${base_libdir}/security/.debug/"
 FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/ ${sysconfdir}/rpm/macros.systemd"
 
-RDEPENDS_${PN} += "dbus"
+RDEPENDS_${PN} += "dbus util-linux-mount"
 
 RRECOMMENDS_${PN} += "systemd-serialgetty systemd-compat-units \
                       util-linux-agetty \
@@ -196,7 +205,7 @@ RRECOMMENDS_${PN} += "systemd-serialgetty systemd-compat-units \
                       kernel-module-autofs4 kernel-module-unix kernel-module-ipv6 \
 "
 
-PACKAGES =+ "udev-dbg udev udev-consolekit udev-utils udev-hwdb"
+PACKAGES =+ "udev-dbg udev udev-utils udev-hwdb"
 
 FILES_udev-dbg += "/lib/udev/.debug"
 
@@ -205,38 +214,35 @@ RPROVIDES_udev = "hotplug"
 RRECOMMENDS_udev += "udev-extraconf udev-hwdb"
 
 FILES_udev += "${base_sbindir}/udevd \
-               ${base_libdir}/systemd/systemd-udevd \
-               /lib/udev/accelerometer \
-               /lib/udev/ata_id \
-               /lib/udev/cdrom_id \
-               /lib/udev/collect \
-               /lib/udev/findkeyboards \
-               /lib/udev/keyboard-force-release.sh \
-               /lib/udev/keymap \
-               /lib/udev/mtd_probe \
-               /lib/udev/scsi_id \
-               /lib/udev/v4l_id \
-               /lib/udev/keymaps \
-               /lib/udev/rules.d/4*.rules \
-               /lib/udev/rules.d/5*.rules \
-               /lib/udev/rules.d/6*.rules \
-               /lib/udev/rules.d/70-power-switch.rules \
-               /lib/udev/rules.d/75*.rules \
-               /lib/udev/rules.d/78*.rules \
-               /lib/udev/rules.d/8*.rules \
-               /lib/udev/rules.d/95*.rules \
+               ${rootlibexecdir}/systemd/systemd-udevd \
+               ${rootlibexecdir}/udev/accelerometer \
+               ${rootlibexecdir}/udev/ata_id \
+               ${rootlibexecdir}/udev/cdrom_id \
+               ${rootlibexecdir}/udev/collect \
+               ${rootlibexecdir}/udev/findkeyboards \
+               ${rootlibexecdir}/udev/keyboard-force-release.sh \
+               ${rootlibexecdir}/udev/keymap \
+               ${rootlibexecdir}/udev/mtd_probe \
+               ${rootlibexecdir}/udev/scsi_id \
+               ${rootlibexecdir}/udev/v4l_id \
+               ${rootlibexecdir}/udev/keymaps \
+               ${rootlibexecdir}/udev/rules.d/4*.rules \
+               ${rootlibexecdir}/udev/rules.d/5*.rules \
+               ${rootlibexecdir}/udev/rules.d/6*.rules \
+               ${rootlibexecdir}/udev/rules.d/70-power-switch.rules \
+               ${rootlibexecdir}/udev/rules.d/75*.rules \
+               ${rootlibexecdir}/udev/rules.d/78*.rules \
+               ${rootlibexecdir}/udev/rules.d/8*.rules \
+               ${rootlibexecdir}/udev/rules.d/95*.rules \
                ${sysconfdir}/udev \
                ${sysconfdir}/init.d/systemd-udevd \
                ${systemd_unitdir}/system/*udev* \
                ${systemd_unitdir}/system/*.wants/*udev* \
               "
 
-FILES_udev-consolekit += "/lib/ConsoleKit"
-RDEPENDS_udev-consolekit += "${@base_contains('DISTRO_FEATURES', 'x11', 'consolekit', '', d)}"
-
 FILES_udev-utils = "${base_bindir}/udevadm ${datadir}/bash-completion/completions/udevadm"
 
-FILES_udev-hwdb = "${base_libdir}/udev/hwdb.d"
+FILES_udev-hwdb = "${rootlibexecdir}/udev/hwdb.d"
 
 INITSCRIPT_PACKAGES = "udev"
 INITSCRIPT_NAME_udev = "systemd-udevd"
@@ -253,7 +259,7 @@ python __anonymous() {
 
 ALTERNATIVE_${PN} = "init halt reboot shutdown poweroff"
 
-ALTERNATIVE_TARGET[init] = "${systemd_unitdir}/systemd"
+ALTERNATIVE_TARGET[init] = "${rootlibexecdir}/systemd/systemd"
 ALTERNATIVE_LINK_NAME[init] = "${base_sbindir}/init"
 ALTERNATIVE_PRIORITY[init] ?= "300"
 

meta/recipes-core/udev/udev-extraconf/mount.sh

@@ -21,6 +21,11 @@ automount() {
 	name="`basename "$DEVNAME"`"
 
 	! test -d "/media/$name" && mkdir -p "/media/$name"
+	# Silent util-linux's version of mounting auto
+	if [ "x`readlink $MOUNT`" = "x/bin/mount.util-linux" ] ;
+	then
+		MOUNT="$MOUNT -o silent"
+	fi
 	
 	if ! $MOUNT -t auto $DEVNAME "/media/$name"
 	then

meta/recipes-core/udev/udev-extraconf_1.0.bb

@@ -4,8 +4,6 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
                     file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 
-inherit allarch
-
 PR = "r8"
 
 SRC_URI = " \

meta/recipes-core/udev/udev.inc

@@ -15,7 +15,6 @@ LDFLAGS += "-lrt"
 DEPENDS = "acl glib-2.0 libusb usbutils pciutils gperf-native libxslt-native util-linux"
 RPROVIDES_${PN} = "hotplug"
 RRECOMMENDS_${PN} += "udev-extraconf usbutils-ids pciutils-ids"
-RDEPENDS_libudev = "${PN} (= ${EXTENDPKGV})"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/utils/kernel/hotplug/udev-${PV}.tar.gz \
            file://0001-Fixing-keyboard_force_release.sh-shell-script-path.patch \
@@ -40,9 +39,10 @@ EXTRA_OECONF = "--disable-introspection \
                 ac_cv_file__usr_share_hwdata_pci_ids=no \
                 ac_cv_file__usr_share_misc_pci_ids=yes \
                 --sbindir=${base_sbindir} \
-                --libexecdir=${base_sbindir} \
+                --libexecdir=${nonarch_base_libdir} \
                 --with-rootlibdir=${base_libdir} \
                 --with-rootprefix= \
+                --without-systemdsystemunitdir \
                "
 
 PACKAGES =+ "udev-utils udev-cache"
@@ -55,13 +55,13 @@ INITSCRIPT_PARAMS_udev = "start 03 S ."
 INITSCRIPT_NAME_udev-cache = "udev-cache"
 INITSCRIPT_PARAMS_udev-cache = "start 36 S ."
 
-FILES_${PN} += "${libexecdir} ${libdir}/ConsoleKit"
+FILES_${PN} += "${libexecdir} ${libdir}/ConsoleKit ${nonarch_base_libdir}/udev"
 RRECOMMENDS_${PN} += "udev-utils"
 
 FILES_${PN}-dbg += "${libexecdir}/.debug"
 FILES_${PN}-dbg += "${base_libdir}/udev/.debug/"
 FILES_${PN}-dbg += "${base_libdir}/udev/.debug/*"
-FILES_${PN}-dbg += "${base_sbindir}/udev/.debug/*"
+FILES_${PN}-dbg += "${nonarch_base_libdir}/udev/.debug/*"
 FILES_${PN}-dev = "${datadir}/pkgconfig/udev.pc"
 FILES_libudev = "${base_libdir}/libudev.so.*"
 FILES_libudev-dbg = "${base_libdir}/.debug/libudev.so.*"
@@ -79,8 +79,8 @@ do_install_append () {
 	install -d ${D}${sysconfdir}/init.d
 	install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
 	install -m 0755 ${WORKDIR}/udev-cache ${D}${sysconfdir}/init.d/udev-cache
-	sed -i s%@UDEVD@%${base_sbindir}/udev/udevd% ${D}${sysconfdir}/init.d/udev
-	sed -i s%@UDEVD@%${base_sbindir}/udev/udevd% ${D}${sysconfdir}/init.d/udev-cache
+	sed -i s%@UDEVD@%${nonarch_base_libdir}/udev/udevd% ${D}${sysconfdir}/init.d/udev
+	sed -i s%@UDEVD@%${nonarch_base_libdir}/udev/udevd% ${D}${sysconfdir}/init.d/udev-cache
 
 	install -d ${D}${sysconfdir}/default
 	install -m 0755 ${WORKDIR}/udev-cache.default ${D}${sysconfdir}/default/udev-cache

meta/recipes-core/udev/udev/init

@@ -35,6 +35,14 @@ case "$1" in
     # propagate /dev from /sys
     echo "Starting udev"
 
+    # Check for requireed devtmpfs before trying to start udev and
+    # mount a no-existant fs.
+    if ! grep -q devtmpfs /proc/filesystems
+    then
+        echo "Missing devtmpfs, which is required for udev to run";
+        echo "Halting..."
+        halt
+    fi
     # mount the tmpfs on /dev, if not already done
     LANG=C awk '$2 == "/dev" && ($3 == "tmpfs" || $3 == "devtmpfs") { exit 1 }' /proc/mounts && {
             mount -n -o mode=0755 -t tmpfs none "/dev"
@@ -73,13 +81,13 @@ case "$1" in
     echo -e '\000\000\000\000' > /proc/sys/kernel/hotplug
     @UDEVD@ -d
 
-    /usr/bin/udevadm control --env=STARTUP=1
+    udevadm control --env=STARTUP=1
     if [ "$not_first_boot" != "" ];then
-            /usr/bin/udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus  --subsystem-nomatch=graphics	 --subsystem-nomatch=backlight --subsystem-nomatch=video4linux	--subsystem-nomatch=platform
-            (/usr/bin/udevadm settle --timeout=3; /usr/bin/udevadm control --env=STARTUP=)&
+            udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus  --subsystem-nomatch=graphics	 --subsystem-nomatch=backlight --subsystem-nomatch=video4linux	--subsystem-nomatch=platform
+            (udevadm settle --timeout=3; udevadm control --env=STARTUP=)&
     else
-            /usr/bin/udevadm trigger --action=add
-            /usr/bin/udevadm settle
+            udevadm trigger --action=add
+            udevadm settle
     fi
     ;;
   stop)

meta/recipes-core/util-linux/util-linux.inc

@@ -93,8 +93,8 @@ RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-l
 RRECOMMENDS_${PN}_class-native = ""
 RDEPENDS_${PN}_class-native = ""
 
-SYSTEMD_PACKAGES = "util-linux-uuidd"
-SYSTEMD_SERVICE_util-linux-uuidd = "uuidd.service"
+SYSTEMD_PACKAGES = "${PN}-uuidd"
+SYSTEMD_SERVICE_${PN}-uuidd = "uuidd.service"
 
 do_compile () {
 	set -e

meta/recipes-devtools/devel-config/anjuta-remote-run.bb

@@ -15,5 +15,3 @@ do_install() {
 PACKAGES = "${PN}"
 RDEPENDS_${PN} = "dbus rsync"
 
-inherit allarch
-

meta/recipes-devtools/devel-config/distcc-config.bb

@@ -21,5 +21,3 @@ do_install() {
 }
 
 RDEPENDS_${PN} = "distcc"
-
-inherit allarch

meta/recipes-devtools/devel-config/nfs-export-root.bb

@@ -14,6 +14,4 @@ do_install() {
 	install -m 0644 exports ${D}${sysconfdir}/
 }
 
-RDEPENDS_${PN} = "task-core-nfs-server"
-
-inherit allarch
+RDEPENDS_${PN} = "packagegroup-core-nfs-server"

meta/recipes-devtools/dpkg/dpkg.inc

@@ -37,17 +37,9 @@ do_configure () {
 
 POSTLOG ?= "/var/log/postinstall.log"
 REDIRECT_CMD = "${@base_contains('IMAGE_FEATURES', 'debug-tweaks', '>${POSTLOG} 2>&1', '', d)}"
+REDIRECT_CMD[vardepsexclude] += "IMAGE_FEATURES POSTLOG"
 
 DPKG_INIT_POSITION ?= "98"
-do_install_prepend () {
-	install -d ${D}/${sysconfdir}/rcS.d
-	# this happens at S98 where our good 'ole packages script used to run
-	echo "#!/bin/sh
-dpkg --configure -a ${REDIRECT_CMD}
-rm -f ${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
-" > ${D}/${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
-	chmod 0755 ${D}/${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
-}
 
 do_install_append () {
 	if [ "${PN}" = "dpkg-native" ]; then
@@ -67,6 +59,20 @@ do_install_append_class-native () {
 	done
 }
 
+pkg_postinst_${PN} () {
+#!/bin/sh
+if [ "x$D" != "x" ] && [ -f $D/var/lib/dpkg/status ]; then
+	install -d $D${sysconfdir}/rcS.d
+
+	# this happens at S98 where our good 'ole packages script used to run
+	echo "#!/bin/sh
+dpkg --configure -a ${REDIRECT_CMD}
+rm -f ${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
+" > $D${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
+	chmod 0755 $D${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
+fi
+}
+
 PROV = "virtual/update-alternatives"
 PROV_class-native = ""
 

meta/recipes-devtools/opkg/opkg.inc

@@ -59,11 +59,13 @@ do_install_append_class-native() {
 
 POSTLOG ?= "/var/log/postinstall.log"
 REDIRECT_CMD = "${@base_contains('IMAGE_FEATURES', 'debug-tweaks', '>${POSTLOG} 2>&1', '', d)}"
+REDIRECT_CMD[vardepsexclude] += "IMAGE_FEATURES POSTLOG"
 
 pkg_postinst_${PN} () {
 #!/bin/sh
-if [ "x$D" != "x" ]; then
+if [ "x$D" != "x" ] && [ -f $D${OPKGLIBDIR}/opkg/status ]; then
 	install -d $D${sysconfdir}/rcS.d
+
 	# this happens at S98 where our good 'ole packages script used to run
 	echo "#!/bin/sh
 opkg-cl configure ${REDIRECT_CMD}

meta/recipes-devtools/qemu/files/3f08ffb4a4741d147634761dc053ed386243a0de.patch

@@ -1,4 +1,4 @@
-Upsteream-Status: Backport
+Upstream-Status: Backport
 
 [Appears to fix the random segfaults we were seeing in a variety of architectures:
 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4216 ]

meta/recipes-devtools/qemu/files/fdt_header.patch

@@ -0,0 +1,39 @@
+Upstream-Status: Pending 
+
+qemu: define fdt types in libfdt_env.h from qemu
+    
+    * fixes
+    In file included from /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/libfdt.h:55:0,
+                     from /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/work/x86_64-linux/qemu-native/1.4.0-r0/qemu-1.4.0/hw/arm/../../device_tree.c:28:
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:58:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:59:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:60:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:61:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:62:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:63:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:64:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:67:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:70:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:73:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:77:2: error: unknown type name 'fdt64_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:78:2: error: unknown type name 'fdt64_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:82:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:87:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:88:2: error: unknown type name 'fdt32_t'
+    /home/oe/setup-scripts/build/tmp-angstrom_next-uclibc/sysroots/x86_64-linux/usr/include/fdt.h:89:2: error: unknown type name 'fdt32_t'
+
+Index: qemu-1.4.0/include/libfdt_env.h
+===================================================================
+--- qemu-1.4.0.orig/include/libfdt_env.h	2013-02-15 23:05:35.000000000 +0000
++++ qemu-1.4.0/include/libfdt_env.h	2013-04-13 14:17:27.918885225 +0000
+@@ -21,6 +21,10 @@
+ 
+ #include "qemu/bswap.h"
+ 
++typedef uint16_t fdt16_t;
++typedef uint32_t fdt32_t;
++typedef uint64_t fdt64_t;
++
+ #ifdef HOST_WORDS_BIGENDIAN
+ #define fdt32_to_cpu(x)  (x)
+ #define cpu_to_fdt32(x)  (x)

meta/recipes-devtools/qemu/qemu_1.4.0.bb

@@ -3,7 +3,9 @@ require qemu.inc
 LIC_FILES_CHKSUM = "file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \
                     file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913"
 
-SRC_URI += "file://3f08ffb4a4741d147634761dc053ed386243a0de.patch"
+SRC_URI += "file://3f08ffb4a4741d147634761dc053ed386243a0de.patch \
+            file://fdt_header.patch \
+           "
 
 SRC_URI_prepend = "http://wiki.qemu.org/download/qemu-${PV}.tar.bz2"
 SRC_URI[md5sum] = "78f13b774814b6b7ebcaf4f9b9204318"

meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb

@@ -18,3 +18,5 @@ SYSROOT_PREPROCESS_FUNCS += "qemuwrapper_sysroot_preprocess"
 qemuwrapper_sysroot_preprocess () {
 	sysroot_stage_dir ${D}${bindir_crossscripts} ${SYSROOT_DESTDIR}${bindir_crossscripts}
 }
+
+INHIBIT_DEFAULT_DEPS = "1"

meta/recipes-devtools/rpm/rpm-postinsts.bb

@@ -5,17 +5,15 @@ LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/LGPL-2.1;md5=1
 
 RDEPENDS_${PN} = "base-files"
 
-inherit update-rc.d allarch
+inherit allarch
 #
 # Allow distributions to alter when [postponed] package install scripts are run
 #
 POSTINSTALL_INITPOSITION ?= "98"
 
-INITSCRIPT_NAME = "run-postinsts"
-INITSCRIPT_PARAMS = "start ${{POSTINSTALL_INITPOSITION} S ."
-
 POSTLOG ?= "/var/log/postinstall.log"
 REDIRECT_CMD = "${@base_contains('IMAGE_FEATURES', 'debug-tweaks', '>>${POSTLOG} 2>&1', '', d)}"
+REDIRECT_CMD[vardepsexclude] += "IMAGE_FEATURES POSTLOG"
 
 do_fetch() {
 	:
@@ -30,12 +28,16 @@ do_compile() {
 }
 
 do_install() {
-	install -d ${D}/${sysconfdir}/rcS.d
-	# Stop $i getting expanded below...
-	i=\$i
-	cat > ${D}${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts << EOF
+	:
+}
+
+pkg_postinst_${PN} () {
+if [ "x$D" != "x" ] && [ -f $D/var/lib/rpm/Packages ]; then
+	install -d $D/${sysconfdir}/rcS.d
+	cat > $D${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts << "EOF"
 #!/bin/sh
-for i in \`ls /etc/rpm-postinsts/\`; do
+
+[ -d /etc/rpm-postinsts ] && for i in `ls /etc/rpm-postinsts/`; do
 	i=/etc/rpm-postinsts/$i
 	echo "Running postinst $i..."
 	if [ -f $i ] && $i ${REDIRECT_CMD}; then
@@ -44,7 +46,10 @@ for i in \`ls /etc/rpm-postinsts/\`; do
 		echo "ERROR: postinst $i failed."
 	fi
 done
-rm -f ${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts
+rm -f ${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts 2>/dev/null
 EOF
-	chmod 0755 ${D}${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts
+	chmod 0755 $D${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts
+fi
 }
+
+ALLOW_EMPTY_${PN} = "1"

meta/recipes-extended/augeas/augeas.inc

@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=bbb461211a33b134d42ed5ee802b37ff"
 
 SRC_URI = "http://download.augeas.net/${BP}.tar.gz \
            file://add-missing-argz-conditional.patch \
+           file://sepbuildfix.patch \
           "
 
 DEPENDS = "readline libxml2"

meta/recipes-extended/augeas/augeas/sepbuildfix.patch

@@ -0,0 +1,22 @@
+Ensure that builds in separate builddirs (${B} != ${S}) correctly install the 
+lenses files.
+
+Upstream-Status: Pending
+
+RP 2013/4/17
+
+Index: augeas-1.0.0/Makefile.am
+===================================================================
+--- augeas-1.0.0.orig/Makefile.am	2012-11-02 15:20:11.000000000 +0000
++++ augeas-1.0.0/Makefile.am	2013-04-17 10:36:24.033400125 +0000
+@@ -5,8 +5,8 @@
+ lensdir=$(datadir)/augeas/lenses/dist
+ lenstestdir=$(datadir)/augeas/lenses/dist/tests
+ 
+-dist_lens_DATA=$(wildcard lenses/*.aug)
+-dist_lenstest_DATA=$(wildcard lenses/tests/*.aug)
++dist_lens_DATA=$(wildcard $(top_srcdir)/lenses/*.aug)
++dist_lenstest_DATA=$(wildcard $(top_srcdir)lenses/tests/*.aug)
+ 
+ EXTRA_DIST=augeas.spec build/aux/move-if-change Makefile.am HACKING
+ 

meta/recipes-extended/pam/libpam/add-checks-for-crypt-returning-NULL.patch

@@ -0,0 +1,63 @@
+Backport from linux-pam git repo.
+
+[YOCTO #4107]
+
+Upstream-Status: Backport
+
+Signed-off-by: Kang Kai <kai.kang@windriver.com>
+
+From 8dc056c1c8bc7acb66c4decc49add2c3a24e6310 Mon Sep 17 00:00:00 2001
+From: Tomas Mraz <tmraz@fedoraproject.org>
+Date: Fri, 8 Feb 2013 15:04:26 +0100
+Subject: [PATCH] Add checks for crypt() returning NULL.
+
+modules/pam_pwhistory/opasswd.c (compare_password): Add check for crypt() NULL return.
+modules/pam_unix/bigcrypt.c (bigcrypt): Likewise.
+---
+ modules/pam_pwhistory/opasswd.c |    2 +-
+ modules/pam_unix/bigcrypt.c     |    9 +++++++++
+ 2 files changed, 10 insertions(+), 1 deletions(-)
+
+diff --git a/modules/pam_pwhistory/opasswd.c b/modules/pam_pwhistory/opasswd.c
+index 274fdb9..836d713 100644
+--- a/modules/pam_pwhistory/opasswd.c
++++ b/modules/pam_pwhistory/opasswd.c
+@@ -108,7 +108,7 @@ compare_password(const char *newpass, const char *oldpass)
+   outval = crypt (newpass, oldpass);
+ #endif
+ 
+-  return strcmp(outval, oldpass) == 0;
++  return outval != NULL && strcmp(outval, oldpass) == 0;
+ }
+ 
+ /* Check, if the new password is already in the opasswd file.  */
+diff --git a/modules/pam_unix/bigcrypt.c b/modules/pam_unix/bigcrypt.c
+index e10d1c5..e1d57a0 100644
+--- a/modules/pam_unix/bigcrypt.c
++++ b/modules/pam_unix/bigcrypt.c
+@@ -109,6 +109,10 @@ char *bigcrypt(const char *key, const char *salt)
+ #else
+ 	tmp_ptr = crypt(plaintext_ptr, salt);	/* libc crypt() */
+ #endif
++	if (tmp_ptr == NULL) {
++		free(dec_c2_cryptbuf);
++		return NULL;
++	}
+ 	/* and place in the static area */
+ 	strncpy(cipher_ptr, tmp_ptr, 13);
+ 	cipher_ptr += ESEGMENT_SIZE + SALT_SIZE;
+@@ -130,6 +134,11 @@ char *bigcrypt(const char *key, const char *salt)
+ #else
+ 			tmp_ptr = crypt(plaintext_ptr, salt_ptr);
+ #endif
++			if (tmp_ptr == NULL) {
++				_pam_overwrite(dec_c2_cryptbuf);
++				free(dec_c2_cryptbuf);
++				return NULL;
++			}
+ 
+ 			/* skip the salt for seg!=0 */
+ 			strncpy(cipher_ptr, (tmp_ptr + SALT_SIZE), ESEGMENT_SIZE);
+-- 
+1.7.5.4
+

meta/recipes-extended/pam/libpam/reflect-the-enforce_for_root-semantics-change-in-pam.patch

@@ -0,0 +1,35 @@
+Backport from linux-pam git repo.
+
+[YOCTO #4107]
+
+Upstream-Status: Backport
+
+Signed-off-by: Kang Kai <kai.kang@windriver.com>
+
+From bd07ad3adc626f842a4391d256541883426fd389 Mon Sep 17 00:00:00 2001
+From: Tomas Mraz <tmraz@fedoraproject.org>
+Date: Tue, 13 Nov 2012 09:19:05 +0100
+Subject: [PATCH] Reflect the enforce_for_root semantics change in
+ pam_pwhistory xtest.
+
+xtests/tst-pam_pwhistory1.pamd: Use enforce_for_root as the test is
+running with real uid == 0.
+---
+ xtests/tst-pam_pwhistory1.pamd | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/xtests/tst-pam_pwhistory1.pamd b/xtests/tst-pam_pwhistory1.pamd
+index 68e1b94..d60db7c 100644
+--- a/xtests/tst-pam_pwhistory1.pamd
++++ b/xtests/tst-pam_pwhistory1.pamd
+@@ -1,6 +1,6 @@
+ #%PAM-1.0
+ auth     required       pam_permit.so
+ account  required       pam_permit.so
+-password required	pam_pwhistory.so remember=10 retry=1
++password required	pam_pwhistory.so remember=10 retry=1 enforce_for_root
+ password required	pam_unix.so	use_authtok md5
+ session  required       pam_permit.so
+-- 
+1.7.11.7
+

meta/recipes-extended/pam/libpam_1.1.6.bb

@@ -15,6 +15,8 @@ SRC_URI = "http://linux-pam.org/library/Linux-PAM-${PV}.tar.bz2 \
            file://libpam-xtests.patch \
            file://destdirfix.patch \
            file://fixsepbuild.patch \
+           file://reflect-the-enforce_for_root-semantics-change-in-pam.patch \
+           file://add-checks-for-crypt-returning-NULL.patch \
           "
 SRC_URI[md5sum] = "7b73e58b7ce79ffa321d408de06db2c4"
 SRC_URI[sha256sum] = "bab887d6280f47fc3963df3b95735a27a16f0f663636163ddf3acab5f1149fc2"