documentation/dev-manual/dev-manual-kernel-appendix.xml: Add note about conflict

Added a note to the part of the example where you bitbake the kernel
after turning off CONFIG_SMP.  The warnings you get can cause confusion.
the note explains they are normal.

(From yocto-docs rev: 08ed090f0b8b6970832242a52827ae2957918cf3)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

.gitignore

@@ -1,5 +1,6 @@
 *.pyc
 *.pyo
+/*.patch
 build*/conf/local.conf
 build*/conf/bblayers.conf
 build*/downloads

bitbake/bin/bitbake

@@ -40,7 +40,7 @@ from bb import cooker
 from bb import ui
 from bb import server
 
-__version__ = "1.15.1"
+__version__ = "1.15.2"
 logger = logging.getLogger("BitBake")
 
 

bitbake/lib/bb/__init__.py

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

bitbake/lib/bb/cooker.py

@@ -1175,7 +1175,7 @@ class BBCooker:
             return
 
         if self.state in (state.shutdown, state.stop):
-            self.parser.shutdown(clean=False)
+            self.parser.shutdown(clean=False, force = True)
             sys.exit(1)
 
         if self.state != state.parsing:
@@ -1608,10 +1608,13 @@ class CookerParser(object):
                 self.parser_quit.put(None)
 
             self.jobs.cancel_join_thread()
-            sys.exit(1)
 
         for process in self.processes:
-            process.join()
+            if force:
+                process.join(.1)
+                process.terminate()
+            else:
+                process.join()
         self.feeder.join()
 
         sync = threading.Thread(target=self.bb_cache.sync)

bitbake/lib/bb/event.py

@@ -517,3 +517,21 @@ class PackageInfo(Event):
     def __init__(self, pkginfolist):
         Event.__init__(self)
         self._pkginfolist = pkginfolist
+
+class SanityCheck(Event):
+    """
+    Event to issue sanity check
+    """
+
+class SanityCheckPassed(Event):
+    """
+    Event to indicate sanity check is passed
+    """
+
+class SanityCheckFailed(Event):
+    """
+    Event to indicate sanity check has failed
+    """
+    def __init__(self, msg):
+        Event.__init__(self)
+        self._msg = msg

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

@@ -354,6 +354,9 @@ class Builder(gtk.Window):
         self.handler.connect("data-generated",           self.handler_data_generated_cb)
         self.handler.connect("command-succeeded",        self.handler_command_succeeded_cb)
         self.handler.connect("command-failed",           self.handler_command_failed_cb)
+        self.handler.connect("sanity-failed",            self.handler_sanity_failed_cb)
+        self.handler.connect("recipe-populated",         self.handler_recipe_populated_cb)
+        self.handler.connect("package-populated",        self.handler_package_populated_cb)
 
         self.handler.set_config_filter(hob_conf_filter)
 
@@ -405,6 +408,9 @@ class Builder(gtk.Window):
         self.set_user_config()
         self.handler.generate_configuration()
 
+    def sanity_check(self):
+        self.handler.trigger_sanity_check()
+
     def populate_recipe_package_info_async(self):
         self.switch_page(self.RCPPKGINFO_POPULATING)
         # Parse recipes
@@ -618,6 +624,8 @@ class Builder(gtk.Window):
     def handler_command_succeeded_cb(self, handler, initcmd):
         if initcmd == self.handler.GENERATE_CONFIGURATION:
             self.update_configuration_parameters(self.get_parameters_sync())
+            self.sanity_check()
+        elif initcmd == self.handler.SANITY_CHECK:
             self.image_configuration_page.switch_machine_combo()
         elif initcmd in [self.handler.GENERATE_RECIPES,
                          self.handler.GENERATE_PACKAGES,
@@ -645,10 +653,14 @@ class Builder(gtk.Window):
 
     def handler_command_failed_cb(self, handler, msg):
         if msg:
-            msg = msg.replace("your local.conf", "Settings")
             self.show_error_dialog(msg)
         self.reset()
 
+    def handler_sanity_failed_cb(self, handler, msg):
+        msg = msg.replace("your local.conf", "Settings")
+        self.show_error_dialog(msg)
+        self.reset()
+
     def window_sensitive(self, sensitive):
         self.image_configuration_page.machine_combo.set_sensitive(sensitive)
         self.image_configuration_page.image_combo.set_sensitive(sensitive)
@@ -693,6 +705,12 @@ class Builder(gtk.Window):
     def packagelist_changed_cb(self, package_model):
         self.package_details_page.refresh_selection()
 
+    def handler_recipe_populated_cb(self, handler):
+        self.image_configuration_page.update_progress_bar("Populated recipes", 0.99)
+
+    def handler_package_populated_cb(self, handler):
+        self.image_configuration_page.update_progress_bar("Populated packages", 1.0)
+
     def handler_parsing_started_cb(self, handler, message):
         if self.current_step != self.RCPPKGINFO_POPULATING:
             return
@@ -712,7 +730,7 @@ class Builder(gtk.Window):
 
         fraction = message["current"] * 1.0/message["total"]
         if message["eventname"] == "TreeDataPreparationProgress":
-            fraction = 0.6 + 0.4 * fraction
+            fraction = 0.6 + 0.38 * fraction
         else:
             fraction = 0.6 * fraction
         self.image_configuration_page.update_progress_bar(message["title"], fraction)
@@ -722,7 +740,7 @@ class Builder(gtk.Window):
             return
 
         if message["eventname"] == "TreeDataPreparationCompleted":
-            fraction = 1.0
+            fraction = 0.98
         else:
             fraction = 0.6
         self.image_configuration_page.update_progress_bar(message["title"], fraction)

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

@@ -356,6 +356,15 @@ class AdvancedSettingDialog (CrumbsDialog):
         data += ("SDK_MACHINE: "          + self._get_sorted_value(self.configuration.curr_sdk_machine))
         data += ("TOOLCHAIN_BUILD: "      + self._get_sorted_value(self.configuration.toolchain_build))
         data += ("IMAGE_FSTYPES: "        + self._get_sorted_value(self.configuration.image_fstypes))
+        if self.enable_proxy:
+            data += ("ALL_PROXY: "            + self._get_sorted_value(self.configuration.all_proxy))
+            data += ("HTTP_PROXY: "           + self._get_sorted_value(self.configuration.http_proxy))
+            data += ("HTTPS_PROXY: "          + self._get_sorted_value(self.configuration.https_proxy))
+            data += ("FTP_PROXY: "            + self._get_sorted_value(self.configuration.ftp_proxy))
+            data += ("GIT_PROXY_HOST: "       + self._get_sorted_value(self.configuration.git_proxy_host))
+            data += ("GIT_PROXY_PORT: "       + self._get_sorted_value(self.configuration.git_proxy_port))
+            data += ("CVS_PROXY_HOST: "       + self._get_sorted_value(self.configuration.cvs_proxy_host))
+            data += ("CVS_PROXY_PORT: "       + self._get_sorted_value(self.configuration.cvs_proxy_port))
         for key in self.configuration.extra_setting.keys():
             data += (key + ": " + self._get_sorted_value(self.configuration.extra_setting[key]))
         return hashlib.md5(data).hexdigest()

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

@@ -42,6 +42,9 @@ class HobHandler(gobject.GObject):
          "command-failed"          : (gobject.SIGNAL_RUN_LAST,
                                       gobject.TYPE_NONE,
                                      (gobject.TYPE_STRING,)),
+         "sanity-failed"           : (gobject.SIGNAL_RUN_LAST,
+                                      gobject.TYPE_NONE,
+                                     (gobject.TYPE_STRING,)),
          "generating-data"         : (gobject.SIGNAL_RUN_LAST,
                                       gobject.TYPE_NONE,
                                      ()),
@@ -57,10 +60,16 @@ class HobHandler(gobject.GObject):
          "parsing-completed"       : (gobject.SIGNAL_RUN_LAST,
                                       gobject.TYPE_NONE,
                                      (gobject.TYPE_PYOBJECT,)),
+         "recipe-populated"        : (gobject.SIGNAL_RUN_LAST,
+                                      gobject.TYPE_NONE,
+                                     ()),
+         "package-populated"       : (gobject.SIGNAL_RUN_LAST,
+                                      gobject.TYPE_NONE,
+                                     ()),
     }
 
-    (GENERATE_CONFIGURATION, GENERATE_RECIPES, GENERATE_PACKAGES, GENERATE_IMAGE, POPULATE_PACKAGEINFO) = range(5)
-    (SUB_PATH_LAYERS, SUB_FILES_DISTRO, SUB_FILES_MACH, SUB_FILES_SDKMACH, SUB_MATCH_CLASS, SUB_PARSE_CONFIG, SUB_GNERATE_TGTS, SUB_GENERATE_PKGINFO, SUB_BUILD_RECIPES, SUB_BUILD_IMAGE) = range(10)
+    (GENERATE_CONFIGURATION, GENERATE_RECIPES, GENERATE_PACKAGES, GENERATE_IMAGE, POPULATE_PACKAGEINFO, SANITY_CHECK) = range(6)
+    (SUB_PATH_LAYERS, SUB_FILES_DISTRO, SUB_FILES_MACH, SUB_FILES_SDKMACH, SUB_MATCH_CLASS, SUB_PARSE_CONFIG, SUB_SANITY_CHECK, SUB_GNERATE_TGTS, SUB_GENERATE_PKGINFO, SUB_BUILD_RECIPES, SUB_BUILD_IMAGE) = range(11)
 
     def __init__(self, server, recipe_model, package_model):
         super(HobHandler, self).__init__()
@@ -129,6 +138,8 @@ class HobHandler(gobject.GObject):
             self.runCommand(["generateTargetsTree", "classes/image.bbclass", []])
         elif next_command == self.SUB_GENERATE_PKGINFO:
             self.runCommand(["triggerEvent", "bb.event.RequestPackageInfo()"])
+        elif next_command == self.SUB_SANITY_CHECK:
+            self.runCommand(["triggerEvent", "bb.event.SanityCheck()"])
         elif next_command == self.SUB_BUILD_RECIPES:
             self.clear_busy()
             self.building = True
@@ -156,8 +167,15 @@ class HobHandler(gobject.GObject):
 
         if isinstance(event, bb.event.PackageInfo):
             self.package_model.populate(event._pkginfolist)
+            self.emit("package-populated")
             self.run_next_command()
 
+        elif isinstance(event, bb.event.SanityCheckPassed):
+            self.run_next_command()
+
+        elif isinstance(event, bb.event.SanityCheckFailed):
+            self.emit("sanity-failed", event._msg)
+
         elif isinstance(event, logging.LogRecord):
             if event.levelno >= logging.ERROR:
                 self.error_msg += event.msg + '\n'
@@ -166,6 +184,7 @@ class HobHandler(gobject.GObject):
             self.current_phase = "data generation"
             if event._model:
                 self.recipe_model.populate(event._model)
+                self.emit("recipe-populated")
         elif isinstance(event, bb.event.ConfigFilesFound):
             self.current_phase = "configuration lookup"
             var = event._variable
@@ -194,6 +213,8 @@ class HobHandler(gobject.GObject):
             self.clear_busy()
             self.emit("command-failed", self.error_msg)
             self.error_msg = ""
+            if self.building:
+                self.building = False
         elif isinstance(event, (bb.event.ParseStarted,
                  bb.event.CacheLoadStarted,
                  bb.event.TreeDataPreparationStarted,
@@ -312,6 +333,10 @@ class HobHandler(gobject.GObject):
         self.commands_async.append(self.SUB_GENERATE_PKGINFO)
         self.run_next_command(self.POPULATE_PACKAGEINFO)
 
+    def trigger_sanity_check(self):
+        self.commands_async.append(self.SUB_SANITY_CHECK)
+        self.run_next_command(self.SANITY_CHECK)
+
     def generate_configuration(self):
         self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.commands_async.append(self.SUB_PATH_LAYERS)

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

@@ -1057,7 +1057,7 @@ class HobCellRendererPixbuf(gtk.CellRendererPixbuf):
             if self.control.is_active():
                 self.control.on_draw_pixbuf_cb(pix, window.cairo_create(), x, y, w, h, True)
             else:
-                self.control.start_run(200, 0, 0, 1000, 200, tree)
+                self.control.start_run(200, 0, 0, 1000, 150, tree)
         else:
             self.control.remove_running_cell_area(cell_area)
             self.control.on_draw_pixbuf_cb(pix, window.cairo_create(), x, y, w, h, False)

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

@@ -125,11 +125,17 @@ class PersistentTooltip(gtk.Window):
                 style.fg[gtk.STATE_NORMAL] = gtk.gdk.color_parse(val)
                 self.label.set_style(style)
                 break # we only care for the tooltip_fg_color
+
         self.label.set_markup(markup)
         self.label.show()
         bin.add(self.label)
         hbox.pack_end(bin, True, True, 6)
 
+        # add the original URL display for user reference
+        if 'a href' in markup:
+            hbox.set_tooltip_text(self.get_markup_url(markup))
+        hbox.show()
+
         self.connect("key-press-event", self._catch_esc_cb)
 
     """
@@ -165,3 +171,16 @@ class PersistentTooltip(gtk.Window):
     def hide(self):
         self.shown = False
         gtk.Window.hide(self)
+
+    """
+    Called to get the hyperlink URL from markup text.
+    """
+    def get_markup_url(self, markup):
+        url = "http:"
+        if markup and type(markup) == str:
+            s = markup
+            if 'http:' in s:
+                import re
+                url = re.search('(http:[^,\\ "]+)', s).group(0)
+
+        return url

documentation/Makefile

@@ -82,7 +82,8 @@ ALLPREQ = html pdf tarball
 #
 # Note that the tarfile might produce the "Cannot stat: No such file or directory" error
 # message for .PNG files that are not present when building a particular branch.  The 
-# list of files is all-inclusive for all branches.
+# list of files is all-inclusive for all branches.  Note, if you don't provide a BRANCH
+# option, it defaults to the latest stuff.  This would be appropriate for "master" branch.
 #
 
 	ifeq ($(BRANCH),edison)
@@ -94,13 +95,22 @@ TARFILES = style.css dev-manual.html dev-manual.pdf \
            figures/kernel-overview-3-edison.png \
            figures/source-repos.png figures/yp-download.png \
            figures/wip.png
-	else
+	else ifeq ($(BRANCH),denzil)
 TARFILES = style.css dev-manual.html dev-manual.pdf \
            figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
            figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
-           figures/kernel-example-repos.png \
+           figures/kernel-example-repos-denzil.png \
            figures/kernel-overview-1.png figures/kernel-overview-2.png \
-           figures/kernel-overview-3.png \
+           figures/kernel-overview-3-denzil.png \
+           figures/source-repos.png figures/yp-download.png \
+           figures/wip.png
+        else
+TARFILES = style.css dev-manual.html dev-manual.pdf \
+           figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+           figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+           figures/kernel-example-repos-denzil.png \
+           figures/kernel-overview-1.png figures/kernel-overview-2.png \
+           figures/kernel-overview-3-denzil.png \
            figures/source-repos.png figures/yp-download.png \
            figures/wip.png
 	endif
@@ -195,7 +205,7 @@ validate:
 
 publish:
 	scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/$(VER)/$(DOC)
-	cd $(DOC); scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/$(VER)/$(DOC)/figures
+	cd $(DOC); scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/$(VER)/$(DOC)
 
 clean:
 	rm -f $(MANUALS)

documentation/adt-manual/adt-eclipse.xml

@@ -324,7 +324,7 @@
                         </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>/opt/poky/1.1</filename> directory.
+                        <filename>&YOCTO_ADTPATH_DIR;</filename> directory.
                         This is the location for toolchains installed by the ADT Installer or by hand.
                         Sections "<link linkend='configuring-and-running-the-adt-installer-script'>Configuring 
                         and Running the ADT Installer Script</link>" and 

documentation/adt-manual/adt-manual.xml

@@ -46,8 +46,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2.1</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.2.1 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/bsp-guide/bsp-guide.xml

@@ -58,8 +58,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2.1</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.2.1 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/bsp-guide/bsp.xml

@@ -75,7 +75,7 @@
 
             <para>
                 Some layers function as a layer to hold other BSP layers.
-                An example of this type of layers is the <filename>meta-intel</filename> layer.  
+                An example of this type of layer is the <filename>meta-intel</filename> layer.  
                 The <filename>meta-intel</filename> layer contains over 10 individual BSP layers.
             </para>
 
@@ -121,6 +121,15 @@
                 are separate components that happen to be combined in certain end products.
             </para>
 
+            <para>
+                Before looking at the common form for the file structure inside a BSP Layer, 
+                you should be aware that some requirements do exist in order for a BSP to 
+                be considered compliant with the Yocto Project.
+                For that list of requirements, see the
+                "<link linkend='released-bsp-requirements'>Released BSP Requirements</link>"
+                section.
+            </para>
+
             <para>
                 Below is the common form for the file structure inside a BSP Layer.
                 While you can use this basic form for the standard, realize that the actual structures
@@ -644,6 +653,219 @@
             </section>
         </section>
 
+        <section id='requirements-and-recommendations-for-released-bsps'>
+            <title>Requirements and Recommendations for Released BSPs</title>
+
+            <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
+                released BSPs.
+            </para>
+
+            <section id='released-bsp-requirements'>
+                <title>Released BSP Requirements</title>
+
+                <para>
+                    Before looking at BSP requirements, you should consider the following:
+                    <itemizedlist>
+                        <listitem><para>The requirements here assume the BSP layer is a well-formed, "legal"
+                            layer that can be added to the Yocto Project.
+                            For guidelines on creating a Yocto Project layer that meets these base requirements, see the
+                            "<link linkend='bsp-layers'>BSP Layers</link>" and the 
+                            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding
+                            and Creating Layers"</ulink> in the Yocto Project Development Manual.</para></listitem>
+                        <listitem><para>The requirements in this section apply regardless of how you 
+                            ultimately package a BSP.
+                            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>
+                        <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
+                            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 
+                            modifications exist in the BSP layer, beyond the requirements for general 
+                            compliance with the Yocto Project.
+                            For example, no requirement exists dictating that a specific kernel or 
+                            kernel version be used in a given BSP.</para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Following are the requirements for a released BSP that conforms to the 
+                    Yocto Project:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Layer Name:</emphasis>
+                            The BSP must have a layer name that follows the Yocto
+                            Project standards.  
+                            For information on BSP layer names, see the
+                            "<link linkend='bsp-layers'>BSP Layers</link>" section.
+                            </para></listitem>
+                        <listitem><para><emphasis>File System Layout:</emphasis>
+                            When possible, use the same directory names in your 
+                            BSP layer as listed in the <filename>recipes.txt</filename> file.
+                            In particular, you should place recipes 
+                            (<filename>.bb</filename> files) and recipe
+                            modifications (<filename>.bbappend</filename> files) into  
+                            <filename>recipes-*</filename> subdirectories by functional area 
+                            as outlined in <filename>recipes.txt</filename>.
+                            If you cannot find a category in <filename>recipes.txt</filename>
+                            to fit a particular recipe, you can make up your own 
+                            <filename>recipe-*</filename> subdirectory.
+                            You can find <filename>recipes.txt</filename> in the
+                            <filename>meta</filename> directory of the 
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto 
+                            Project Files</ulink>, or in the OpenEmbedded Core Layer
+                            (<filename>openembedded-core</filename>) found at 
+                            <ulink url='http://git.openembedded.org/openembedded-core/tree/meta'></ulink>.
+                            </para>
+                            <para>Within any particular <filename>recipes-*</filename> category, the layout
+                            should match what is found in the OpenEmbedded Core
+                            Git repository (<filename>openembedded-core</filename>)
+                            or the Yocto Project Files (<filename>poky</filename>).
+                            In other words, make sure you place related files in appropriately
+                            related <filename>recipes-*</filename> subdirectories specific to the
+                            recipe's function, or within a subdirectory containing a set of closely-related
+                            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>
+                        <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.
+                            You must specify which license to use since there is no 
+                            default license if one is not specified.
+                            See the 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/COPYING.MIT'><filename>COPYING.MIT</filename></ulink>
+                            file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer 
+                            as an example.</para></listitem>
+                        <listitem><para><emphasis>README File:</emphasis>
+                            You must include a <filename>README</filename> file in the 
+                            <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            See the 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/README'><filename>README</filename></ulink>
+                            file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer 
+                            as an example.</para>
+                            <para>At a minimum, the <filename>README</filename> file should 
+                            contain the following:
+                            <itemizedlist>
+                                <listitem><para>A brief description about the hardware the BSP 
+                                    targets.</para></listitem>
+                                <listitem><para>A list of all the dependencies a 
+                                    on which a BSP layer depends.
+                                    These dependencies are typically a list of required layers needed 
+                                    to build the BSP.
+                                    However, the dependencies should also contain information regarding 
+                                    any other dependencies the BSP might have.</para></listitem>
+                                <listitem><para>Any required special licensing information.
+                                    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>
+                                <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>
+                                <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 
+                                    the BSP layer.</para></listitem>
+                                <listitem><para>Instructions on how to boot the binary images 
+                                    contained in the <filename>/binary</filename> directory, 
+                                    if present.</para></listitem>
+                                <listitem><para>Information on any known bugs or issues that users 
+                                    should know about when either building or booting the BSP 
+                                    binaries.</para></listitem>
+                            </itemizedlist></para></listitem>
+                        <listitem><para><emphasis>README.sources File:</emphasis>
+                            You must include a <filename>README.sources</filename> in the 
+                            <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            This file specifies exactly where you can find the sources used to 
+                            generate the binary images contained in the 
+                            <filename>/binary</filename> directory, if present.
+                            See the 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/README.sources'><filename>README.sources</filename></ulink>
+                            file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer 
+                            as an example.</para></listitem>
+                        <listitem><para><emphasis>Layer Configuration File:</emphasis>
+                            You must include a <filename>conf/layer.conf</filename> in the
+                            <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            This file identifies the <filename>meta-&lt;bsp_name&gt;</filename>
+                            BSP layer as a layer to the build system.</para></listitem>
+                        <listitem><para><emphasis>Machine Configuration File:</emphasis>
+                            You must include a <filename>conf/machine/&lt;bsp_name&gt;.conf</filename>
+                            in the <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            This configuration file defines a machine target that can be built
+                            using the BSP layer.
+                            Multiple machine configuration files define variations of machine 
+                            configurations that are supported by the BSP.
+                            If a BSP supports more multiple machine variations, you need to 
+                            adequately describe each variation in the BSP 
+                            <filename>README</filename> file.
+                            Do not use multiple machine configuration files to describe disparate
+                            hardware. 
+                            Multiple machine configuration files should describe very similar targets.
+                            If you do have very different targets, you should create a separate
+                            BSP.
+                            <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 
+                            from that directory using scripts or some other mechanism.  
+                            Such considerations are outside the scope of this document.</note>
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='released-bsp-recommendations'>
+                <title>Released BSP Recommendations</title>
+
+                <para>
+                    Following are recommendations for a released BSP that conforms to the 
+                    Yocto Project:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Bootable Images:</emphasis>
+                            BSP releases 
+                            can contain one or more bootable images.
+                            Including bootable images allows users to easily try out the BSP
+                            on their own hardware.</para>
+                            <para>In some cases, it might not be convenient to include a 
+                            bootable image. 
+                            In this case, you might want to make two versions of the 
+                            BSP available: one that contains binary images, and one
+                            that does not.
+                            The version that does not contain bootable images avoids 
+                            unnecessary download times for users not interested in the images.
+                            </para>
+                            <para>If you need to distribute a BSP and include bootable images or build kernel and
+                            filesystems meant to allow users to boot the BSP for evaluation
+                            purposes, you should put the images and artifacts within a 
+                            <filename>binary/</filename> subdirectory located in the 
+                            <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            <note>If you do include a bootable image as part of the BSP and the image
+                            was built by software covered by the GPL or other open source licenses,
+                            it is your responsibility to understand
+                            and meet all licensing requirements, which could include distribution
+                            of source files.</note></para></listitem>
+                        <listitem><para><emphasis>Use a Yocto Linux Kernel:</emphasis>
+                            Kernel recipes in the BSP should be based on a Yocto Linux kernel. 
+                            Basing your recipes on these kernels reduces the costs for maintaining 
+                            the BSP and increases its scalability.
+                            See the <filename>Yocto Linux Kernel</filename> category in the 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'><filename>Yocto Source Repositories</filename></ulink>
+                            for these kernels.</para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+        </section>
+
         <section id='customizing-a-recipe-for-a-bsp'>
             <title>Customizing a Recipe for a BSP</title>
 
@@ -760,7 +982,7 @@
 		        restart the build to continue where it left off.
 		        During the build, the prompt will not appear again
 		        since you have satisfied the requirement.</para>
-                        <para>Once the appropriate license flags are whitelisted
+                        <para>Once the appropriate license flags are on the white list
 		        in the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, you 
 		        can build the encumbered image with no change at all
 		        to the normal build process.</para></listitem> 
@@ -919,7 +1141,7 @@
      ...
 			    
      NOTE: Once created, you should add your new layer to your
-     bblayers.conf file in order for it to be subsquently seen and
+     bblayers.conf file in order for it to be subsequently seen and
      modified by the yocto-kernel tool.
 			    
      NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
@@ -931,7 +1153,7 @@
                 <para>
                     Now that you know where these two commands reside and how to access information 
                     on them, you should find it relatively straightforward to discover the commands 
-                    necessary to create a BSP and perform basic kernel maintainence on that BSP using
+                    necessary to create a BSP and perform basic kernel maintenance on that BSP using
                     the tools.
                     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.
@@ -990,7 +1212,7 @@
                     In every other way, this architecture is representative of how creating a BSP for
                     a 'real' machine would work.
                     The reason the example uses this architecture is because it is an emulated architecture
-                    and can easily be followed without requireing actual hardware.
+                    and can easily be followed without requiring actual hardware.
                 </para>
 
                 <para>
@@ -1059,7 +1281,7 @@
                             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, etc.).</para></listitem>
                         <listitem><para>Next, the script asks whether you would like to have a new 
-                            branch created especially for your BSPin the local 
+                            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>

documentation/dev-manual/dev-manual-bsp-appendix.xml

@@ -43,10 +43,10 @@
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
         </literallayout> 
-        Alternatively, you can start with the downloaded Poky "edison" tarball.
+        Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball.
         These commands unpack the tarball into a Yocto Project File directory structure.
         By default, the top-level directory of the file structure is named
-        <filename>poky-&YOCTO_POKY;</filename>:
+        <filename>&YOCTO_POKY;</filename>:
         <literallayout class='monospaced'>
      $ tar xfj &YOCTO_POKY_TARBALL;
      $ cd &YOCTO_POKY;
@@ -54,7 +54,7 @@
         <note><para>If you're using the tarball method, you can ignore all the following steps that
         ask you to carry out Git operations.  
         You already have the results of those operations
-        in the form of the edison release tarballs.
+        in the form of the &DISTRO_NAME; release tarballs.
         Consequently, there is nothing left to do other than extract those tarballs into the 
         proper locations.</para>
 
@@ -67,7 +67,7 @@
         and keep changes in revision control.
         See the 
         "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>" section
-        for more discussion around these differneces.</para></note>
+        for more discussion around these differences.</para></note>
     </para>
 
     <para>
@@ -133,7 +133,8 @@
 
     <para>
         You need to have the base BSP layer on your development system.  
-        Similar to the local Yocto Project files, you can get the BSP 
+        Similar to the local <link linkend='yocto-project-files'>Yocto Project Files</link>, 
+        you can get the BSP 
         layer in a couple of different ways:  
         download the BSP tarball and extract it, or set up a local Git repository that 
         has the Yocto Project BSP layers.  
@@ -160,15 +161,15 @@
      $ cd meta-intel
         </literallayout> 
         Alternatively, you can start with the downloaded Crown Bay tarball.
-        You can download the edison version of the BSP tarball from the
+        You can download the &DISTRO_NAME; version of the BSP tarball from the
         <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page of the 
         Yocto Project website. 
         Here is the specific link for the tarball needed for this example:
-        <ulink url='&YOCTO_MACHINES_DL_URL;/crownbay-noemgd/crownbay-noemgd-&DISTRO_NAME;-6.0.0.tar.bz2'></ulink>.
+        <ulink url='&YOCTO_MACHINES_DL_URL;/crownbay-noemgd/crownbay-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2'></ulink>.
         Again, be sure that you are already in the <filename>poky</filename> directory
         as described previously before installing the tarball:
         <literallayout class='monospaced'>
-     $ tar xfj crownbay-noemgd-&DISTRO_NAME;-6.0.0.tar.bz2
+     $ tar xfj crownbay-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2
      $ cd meta-intel
         </literallayout> 
     </para>
@@ -177,7 +178,7 @@
         The <filename>meta-intel</filename> directory contains all the metadata 
         that supports BSP creation.  
         If you're using the Git method, the following
-        step will switch to the edison metadata.
+        step will switch to the &DISTRO_NAME; metadata.
         If you're using the tarball method, you already have the correct metadata and can 
         skip to the next step.
         Because <filename>meta-intel</filename> is its own Git repository, you will want
@@ -185,6 +186,7 @@
         For this example we are going to use the <filename>&DISTRO_NAME;</filename> branch. 
         <literallayout class='monospaced'>
      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
      Switched to a new branch '&DISTRO_NAME;'
         </literallayout>
     </para>
@@ -261,10 +263,10 @@
 
         <para>
             Note that inside the <filename>mymachine.conf</filename> is the 
-            <filename>PREFERRED_PROVIDER_virtual/kernel</filename> statement. 
+            <filename>PREFERRED_VERSION_linux-yocto</filename> statement. 
             This statement identifies the kernel that the BSP is going to use.
             In this case, the BSP is using <filename>linux-yocto</filename>, which is the 
-            current Linux Yocto kernel based on the Linux 3.0 release. 
+            current Linux Yocto kernel based on the Linux 3.2 release. 
         </para>
 
         <para>
@@ -283,6 +285,8 @@
      BBFILE_COLLECTIONS += "crownbay"
      BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
      BBFILE_PRIORITY_crownbay = "6"
+
+     LAYERDEPENDS_crownbay = "intel"
             </literallayout>
         </para>
 
@@ -293,6 +297,8 @@
      BBFILE_COLLECTIONS += "mymachine"
      BBFILE_PATTERN_mymachine := "^${LAYERDIR}/"
      BBFILE_PRIORITY_mymachine = "6"
+
+     LAYERDEPENDS_mymachine = "intel"
             </literallayout>
         </para>
     </section>
@@ -391,7 +397,7 @@
                 The recipe for that kernel is not located in the  
                 BSP layer but rather in the local Yocto Project files at 
                 <filename>meta/recipes-kernel/linux</filename> and is 
-                named <filename>linux-yocto_3.0.bb</filename>.
+                named <filename>linux-yocto_3.2.bb</filename>.
                 The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
                 statements point to the exact commits used by the Yocto Project development team
                 in their source repositories that identify the right kernel for our hardware.
@@ -404,7 +410,7 @@
             <para>
                 However, in the <filename>meta-mymachine</filename> layer in 
                 <filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename>
-                file named <filename>linux-yocto_3.0.bbappend</filename> that 
+                file named <filename>linux-yocto_3.2.bbappend</filename> that 
                 appends information to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
                 Thus, the <filename>SRCREV</filename> statements in the append file override
                 the more general statements found in <filename>meta</filename>.
@@ -413,17 +419,20 @@
             <para>
                 The <filename>SRCREV</filename> statements in the append file currently identify
                 the kernel that supports the Crown Bay BSP with and without EMGD support.
-                Here are the statements: 
+                Here are the statements:
+                <note>The commit ID strings used in this manual might not match the actual commit
+                    ID strings found in the <filename>linux-yocto_3.2.bbappend</filename> file.
+                    For the example, this difference does not matter.</note> 
                 <literallayout class='monospaced'>
      SRCREV_machine_pn-linux-yocto_crownbay ?= \
-        "2247da9131ea7e46ed4766a69bb1353dba22f873"
+        "211fc7f4d10ec2b82b424286aabbaff9254b7cbd"
      SRCREV_meta_pn-linux-yocto_crownbay ?= \
-        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
+        "514847185c78c07f52e02750fbe0a03ca3a31d8f"
 
      SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
-        "2247da9131ea7e46ed4766a69bb1353dba22f873"
+        "211fc7f4d10ec2b82b424286aabbaff9254b7cbd"
      SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
-        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
+        "514847185c78c07f52e02750fbe0a03ca3a31d8f"
                 </literallayout>
             </para>
 
@@ -438,19 +447,19 @@
             </para>
 
             <para>  
-                To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>,
+                To fix this situation in <filename>linux-yocto_3.2.bbappend</filename>,
                 we delete the two <filename>SRCREV</filename> statements that support 
                 EMGD (the top pair).
                 We also change the remaining pair to specify <filename>mymachine</filename>
                 and insert the commit identifiers to identify the kernel in which we 
                 are interested, which will be based on the <filename>atom-pc-standard</filename>
                 kernel.
-                In this case, because we're working with the edison branch of everything, we
+                In this case, because we're working with the &DISTRO_NAME; branch of everything, we
                 need to use the <filename>SRCREV</filename> values for the atom-pc branch
-                that are associated with the edison release.  
+                that are associated with the &DISTRO_NAME; release.  
                 To find those values, we need to find the <filename>SRCREV</filename>
-                values that edison uses for the atom-pc branch, which we find in the
-                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
+                values that &DISTRO_NAME; uses for the atom-pc branch, which we find in the
+                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.2.bbappend</filename>
                 file.
             </para>
 
@@ -459,23 +468,21 @@
                 <filename>SRCREV_machine_atom-pc</filename> variable.  
                 The meta <filename>SRCREV</filename> isn't specified in this file, so it must be 
                 specified in the base kernel recipe in the
-                <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb</filename>
-                file, in the <filename>SRCREV_meta variable</filename> found there.  
-                It happens to be the same as the value we already inherited from the 
-                <filename>meta-crownbay</filename> BSP.
+                <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.2.bb</filename>
+                file, in the <filename>SRCREV_meta</filename>  variable found there.  
                 Here are the final <filename>SRCREV</filename> statements:
                 <literallayout class='monospaced'>
-     SRCREV_machine_pn-linux-yocto_mymachine ?= \ 
-        "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
-     SRCREV_meta_pn-linux-yocto_mymachine ?= \ 
-        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
+     SRCREV_machine_pn-linux-yocto_mymachine ?= \
+        "f29531a41df15d74be5ad47d958e4117ca9e489e"
+     SRCREV_meta_pn-linux-yocto_mymachine ?= \
+        "b14a08f5c7b469a5077c10942f4e1aec171faa9d"
                 </literallayout>
             </para>
 
             <para>
                 In this example, we're using the <filename>SRCREV</filename> values we 
-                found already captured in the edison release because we're creating a BSP based on 
-                edison.  
+                found already captured in the &DISTRO_NAME; release because we're creating a BSP based on 
+                &DISTRO_NAME;.  
                 If, instead, we had based our BSP on the master branches, we would want to use 
                 the most recent <filename>SRCREV</filename> values taken directly from the kernel repo.
                 We will not be doing that for this example.
@@ -484,19 +491,19 @@
                 exact commit strings in the Yocto Project source repositories you need to change 
                 the <filename>SRCREV</filename> statements.  
                 You can find all the <filename>machine</filename> and <filename>meta</filename> 
-                branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at
-                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/linux-yocto-3.0'></ulink>.  
+                branch points (commits) for the <filename>linux-yocto-3.2</filename> kernel at
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/linux-yocto-3.2'></ulink>.  
             </para>
 
             <para>
                 If you need a little more assistance after going to the link then do the following:
                 <orderedlist>
                     <listitem><para>Expand the list of branches by clicking <filename>[…]</filename></para></listitem>
-                    <listitem><para>Click on the <filename>yocto/standard/common-pc/atom-pc</filename> 
+                    <listitem><para>Click on the <filename>standard/default/common-pc/atom-pc</filename> 
                         branch</para></listitem>
                     <listitem><para>Click on the commit column header to view the top commit</para></listitem>
                     <listitem><para>Copy the commit string for use in the 
-                        <filename>linux-yocto_3.0.bbappend</filename> file</para></listitem>
+                        <filename>linux-yocto_3.2.bbappend</filename> file</para></listitem>
                 </orderedlist>
             </para>
 
@@ -507,32 +514,34 @@
             </para>
 
             <para>
-                Also in the <filename>linux-yocto_3.0.bbappend</filename> file are 
+                Also in the <filename>linux-yocto_3.2.bbappend</filename> file are 
                 <filename>COMPATIBLE_MACHINE</filename>, <filename>KMACHINE</filename>, 
-                and <filename>KERNEL_FEATURES</filename> statements.  
+                and <filename>KBRANCH</filename> statements.  
                 Two sets of these exist: one set supports EMGD and one set does not.
                 Because we are not interested in supporting EMGD those three can be deleted.
                 The remaining three must be changed so that <filename>mymachine</filename> replaces
                 <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
-                Because we are using the atom-pc branch for this new BSP, we can also find
-                the exact branch we need for the KMACHINE variable in our new BSP from the value
+                Because we are using the <filename>atom-pc</filename> branch for this new BSP, we can also find
+                the exact branch we need for the <filename>KMACHINE</filename>  
+                and <filename>KBRANCH</filename> variables in our new BSP from the value
                 we find in the
-                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
+                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.2.bbappend</filename>
                 file we looked at in a previous step.  
-                In this case, the value we want is in the KMACHINE_atom-pc variable in that file.
-                Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all 
+                In this case, the values we want are in the <filename>KMACHINE_atom-pc</filename> variable
+                and the <filename>KBRANCH_atom-pc</filename> variables in that file.
+                Here is the final <filename>linux-yocto_3.2.bbappend</filename> file after all 
                 the edits:
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
      COMPATIBLE_MACHINE_mymachine = "mymachine"
-     KMACHINE_mymachine  = "yocto/standard/common-pc/atom-pc"
-     KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"
+     KMACHINE_mymachine  = "atom-pc"
+     KBRANCH_mymachine  = "standard/default/common-pc/atom-pc"
 
      SRCREV_machine_pn-linux-yocto_mymachine ?= \
-        "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
+        "f29531a41df15d74be5ad47d958e4117ca9e489e"
      SRCREV_meta_pn-linux-yocto_mymachine ?= \
-        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
+        "b14a08f5c7b469a5077c10942f4e1aec171faa9d"
                 </literallayout>
             </para>
         </section>
@@ -600,11 +609,12 @@
                 both the <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename> 
                 variables to twice the number of cores your system supports.</para></listitem>
             <listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes 
-                the path to your new BSP layer.  
-                In this example you need to include the pathname to <filename>meta-mymachine</filename>.
-                For this example the 
-                <filename>BBLAYERS</filename> variable in the file would need to include the following path:
+                both the path to your new BSP layer and the path to the 
+                <filename>meta-intel</filename> layer.  
+                In this example, you need to include both these paths as part of the 
+                <filename>BBLAYERS</filename> variable:
                 <literallayout class='monospaced'>
+     $HOME/poky/meta-intel
      $HOME/poky/meta-intel/meta-mymachine
                 </literallayout></para></listitem>
         </orderedlist>
@@ -682,12 +692,12 @@
     </para>
 
     <para>
-        For reference, the sato image produced by the previous steps for edison 
+        For reference, the sato image produced by the previous steps for &DISTRO_NAME; 
         should look like the following in terms of size.
         If your sato image is much different from this,
         you probably made a mistake in one of the above steps:
         <literallayout class='monospaced'>
-     358715392 2011-11-01 19:11 core-image-sato-mymachine-20111101223904.hddimg
+     260538368 2012-04-27 01:44 core-image-sato-mymachine-20120427025051.hddimg
         </literallayout>
         <note>The previous instructions are also present in the README that was copied
         from meta-crownbay, which should also be updated to reflect the specifics of your

documentation/dev-manual/dev-manual-common-tasks.xml

@@ -188,7 +188,8 @@
                     <listitem><para>Store custom layers in a Git repository that uses the 
                         <filename>meta-&lt;layer_name&gt;</filename> format.</para></listitem>
                     <listitem><para>Clone the repository alongside other <filename>meta</filename>
-                        directories in the Yocto Project source files area.</para></listitem>
+                        directories in  
+                        <link linkend='yocto-project-files'>Yocto Project Files</link>.</para></listitem>
                  </itemizedlist>
                  Following these recommendations keeps your Yocto Project files area and 
                  its configuration entirely inside the Yocto Project's core base.
@@ -248,8 +249,8 @@
 
             <para>
                 Append files files must have the same name as the underlying recipe.
-                For example, the append file <filename>someapp_1.1.bbappend</filename> must 
-                apply to <filename>someapp_1.1.bb</filename>.
+                For example, the append file <filename>someapp_&DISTRO;.bbappend</filename> must 
+                apply to <filename>someapp_&DISTRO;.bb</filename>.
                 This means the original recipe and append file names are version number specific.
                 If the underlying recipe is renamed to update to a newer version, the 
                 corresponding <filename>.bbappend</filename> file must be renamed as well.
@@ -269,14 +270,14 @@
                 append file both from the 
                 <link linkend='yocto-project-files'>Yocto Project Files</link>.
                 Here is the main formfactor recipe, which is named <filename>formfactor_0.0.bb</filename> and  
-                located in the meta layer at <filename>meta/bsp-recipes/formfactor</filename>:
+                located in the meta layer at <filename>meta/recipes-bsp/formfactor</filename>:
                 <literallayout class='monospaced'>
      DESCRIPTION = "Device formfactor information"
      SECTION = "base"
      LICENSE = "MIT"
      LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
-                    file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
-     PR = "r19"
+                         file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+     PR = "r20"
 
      SRC_URI = "file://config file://machconfig"
      S = "${WORKDIR}"
@@ -290,11 +291,12 @@
              install -m 0644 ${S}/config ${D}${sysconfdir}/formfactor/
      	if [ -s "${S}/machconfig" ]; then
      	        install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
-	     fi
+     	fi
      }
                 </literallayout>
                 Here is the append file, which is named <filename>formfactor_0.0.bbappend</filename> and is from the 
-                Crown Bay BSP Layer named <filename>meta-intel/meta-crownbay</filename>:
+                Crown Bay BSP Layer named <filename>meta-intel/meta-crownbay</filename>.
+                The file is in <filename>recipes-bsp/formfactor</filename>:
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
  
@@ -477,12 +479,12 @@
             </para>
 
             <para>
-                The other method for creating a custom image is to modify an existing image. 
-                For example, if a developer wants to add <filename>strace</filename> into 
-                the <filename>core-image-sato</filename> image, they can use the following recipe:
+                The other method for creating a custom image is to base it on an existing image. 
+                For example, if you want to create an image based on <filename>core-image-sato</filename>
+                but add the additional package <filename>strace</filename> to the image, 
+                copy the <filename>meta/recipes-sato/images/core-image-sato.bb</filename> to a 
+                new <filename>.bb</filename> and add the following line to the end of the copy:
                 <literallayout class='monospaced'>
-     require core-image-sato.bb
-
      IMAGE_INSTALL += "strace"
                 </literallayout>
             </para>
@@ -748,7 +750,7 @@
                 The variable 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</ulink></filename> 
                 is used to track source license changes as described in the
-                "<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</ulink>" section. 
+                "<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Changes</ulink>" section. 
                 You can quickly create Autotool-based recipes in a manner similar to the previous example.
             </para>
         </section>
@@ -953,7 +955,7 @@
                 <filename>postinst</filename> script.
                 Normally 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'>PN</ulink></filename>
-                can be used, which automatically expands to PACKAGENAME.
+                can be used, which automatically expands to <filename>PACKAGENAME</filename>.
                 A post-installation function has the following structure:
                 <literallayout class='monospaced'>
      pkg_postinst_PACKAGENAME () {
@@ -1082,7 +1084,7 @@ so that there are some definite steps on how to do this.  I need more detail her
                     <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'>
                         PREFERRED_PROVIDER</ulink></filename>_virtual/kernel (see below)</para></listitem>
                     <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES'>
-                        MACHINE_FEATURES</ulink></filename> (e.g. "kernel26 apm screen wifi")</para></listitem>
+                        MACHINE_FEATURES</ulink></filename> (e.g. "apm screen wifi")</para></listitem>
                 </itemizedlist>
             </para>
 

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

@@ -127,6 +127,14 @@
                     <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-1.1-release-notes-poky-&POKYVERSION;'>
                     Release Notes</ulink>:</emphasis> Features, updates and known issues for the current 
                     release of the Yocto Project.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_HOME_URL;/projects/hob'>
+                    Hob</ulink>:</emphasis> A graphical user interface for BitBake. 
+                    Hob's primary goal is to enable a user to perform common tasks more easily.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>
+                    Build Appliance</ulink>:</emphasis> Allows you to build and boot a custom embedded Linux 
+                    image with the Yocto Project using a non-Linux development system.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>:</emphasis>
                     The bug tracking application the Yocto Project uses.

documentation/dev-manual/dev-manual-kernel-appendix.xml

@@ -71,7 +71,7 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-example-repos.png" width="7in" depth="5in" 
+                <imagedata fileref="figures/kernel-example-repos-denzil.png" width="7in" depth="5in" 
                     align="center" scale="100" />
             </para>
 
@@ -155,13 +155,13 @@
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1 Release code named "edison", 
-                which maps to the <filename>edison</filename> branch in the repository. 
-                The following commands create and checkout the local <filename>edison</filename>
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
+                which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
-     Branch edison set up to track remote branch &DISTRO_NAME; from origin.
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
      Switched to a new branch '&DISTRO_NAME;'
                 </literallayout>
             </para>
@@ -178,13 +178,28 @@
                 <filename>poky-extras</filename> Git Repository</link>" 
                 for information on how to get the <filename>poky-extras</filename> repository.
             </para>
+
+            <para>
+                Because this example uses the Yocto Project &DISTRO; Release code 
+                named "&DISTRO_NAME;", which maps to the <filename>&DISTRO_NAME;</filename> 
+                branch in the repository, you need to be sure you are using that 
+                branch for <filename>poky-extra</filename>.
+                The following commands create and checkout the local 
+                branch you are using for the <filename>&DISTRO_NAME;</filename>
+                branch:
+                <literallayout class='monospaced'>
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
+                </literallayout>
+            </para>
         </section>
 
         <section id='setting-up-the-bare-clone-and-its-copy'>
             <title>Setting Up the Bare Clone and its Copy</title>
 
             <para>
-                This example modifies the <filename>linux-yocto-3.0-1.1.x</filename> kernel.
+                This example modifies the <filename>linux-yocto-3.2</filename> kernel.
                 Thus, you need to create a bare clone of that kernel and then make a copy of the 
                 bare clone.
                 See the bulleted item
@@ -196,15 +211,16 @@
                 The bare clone exists for the kernel build tools and simply as the receiving end 
                 of <filename>git push</filename>
                 commands after you make edits and commits inside the copy of the clone.
-                The copy (<filename>my-linux-yocto-3.0-1.1.x-work</filename> in this example) has to have 
+                The copy (<filename>my-linux-yocto-3.2-work</filename> in this example) has to have 
                 a local branch created and checked out for your work.
                 This example uses <filename>common-pc-base</filename> as the local branch.
                 The following commands create and checkout the branch:
                 <literallayout class='monospaced'>
-     $ cd ~/my-linux-yocto-3.0-1.1.x-work
-     $ git checkout -b common-pc-base origin/yocto/standard/common-pc/base
+     $ cd ~/my-linux-yocto-3.2-work
+     $ git checkout -b common-pc-base origin/standard/default/common-pc/base
+     Checking out files: 100% (532/532), done.
      Branch common-pc-base set up to track remote branch 
-        yocto/standard/common-pc/base from origin.
+        standard/default/common-pc/base from origin.
      Switched to a new branch 'common-pc-base'
                 </literallayout>
             </para>
@@ -296,7 +312,7 @@
 
             <para>
                 The file you change in this example is named <filename>calibrate.c</filename>
-                and is located in the <filename>my-linux-yocto-3.0-1.1.x-work</filename> Git repository
+                and is located in the <filename>my-linux-yocto-3.2-work</filename> Git repository
                 (the copy of the bare clone) in <filename>init</filename>.
                 This example simply inserts several <filename>printk</filename> statements
                 at the beginning of the <filename>calibrate_delay</filename> function.
@@ -307,10 +323,11 @@
                 <literallayout class='monospaced'>
      void __cpuinit calibrate_delay(void)
      {
-	     unsigned long lpj;
-	     static bool printed;
+     	unsigned long lpj;
+     	static bool printed;
+     	int this_cpu = smp_processor_id();
 
-         if (preset_lpj) {
+     	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
                .
                .
                .
@@ -319,19 +336,21 @@
 
            <para>
                Here is the altered code showing five new <filename>printk</filename> statements 
-               just after initializing <filename>lps_precision</filename>:
+               near the top of the function:
                 <literallayout class='monospaced'>
      void __cpuinit calibrate_delay(void)
      {
-	     unsigned long lpj;
-	     static bool printed;
+         unsigned long lpj;
+         static bool printed;
+         int this_cpu = smp_processor_id();
+
          printk("*************************************\n");
          printk("*                                   *\n");
          printk("*        HELLO YOCTO KERNEL         *\n");
          printk("*                                   *\n");
          printk("*************************************\n");
 
-         if (preset_lpj) {
+     	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
                .
                .
                .
@@ -357,7 +376,7 @@
            <para>
                The following command pushes the changes to the bare clone:
                <literallayout class='monospaced'>
-     $ git push origin common-pc-base:yocto/standard/common-pc/base
+     $ git push origin common-pc-base:standard/default/common-pc/base
                </literallayout>
            </para>
        </section>
@@ -416,24 +435,24 @@
        "
                        </literallayout></para></listitem>
                    <listitem><para><emphasis>Identify Your Source Files:</emphasis> In the 
-                       <filename>linux-yocto_3.0.bbappend</filename> file located in the 
+                       <filename>linux-yocto_3.2.bbappend</filename> file located in the 
                        <filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
                        directory, you need to identify the location of the 
                        local source code, which in this example is the bare clone named
-                       <filename>linux-yocto-3.0-1.1.x.git</filename>.
+                       <filename>linux-yocto-3.2.git</filename>.
                        To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
-                       local <filename>linux-yocto-3.0-1.1.x.git</filename> Git repository by adding the 
+                       local <filename>linux-yocto-3.2.git</filename> Git repository by adding the 
                        following statement.
                        Be sure to substitute your user information in the statement:
                        <literallayout class='monospaced'>
-     KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0-1.1.x.git
+     KSRC_linux_yocto_3_2 ?= "/home/scottrif/linux-yocto-3.2.git"
                        </literallayout></para></listitem>
-                   <listitem><para><emphasis>Specify the Kernel Machine:</emphasis> Also in the 
-                       <filename>linux-yocto_3.0.bbappend</filename> file, you need to specify
+<!--                   <listitem><para><emphasis>Specify the Kernel Machine:</emphasis> Also in the 
+                       <filename>linux-yocto_3.2.bbappend</filename> file, you need to specify
                        the kernel machine with the following statement:
                        <literallayout class='monospaced'>
-     KMACHINE_qemux86 = "yocto/standard/common-pc/base"
-                       </literallayout></para></listitem>
+     KMACHINE_qemux86 = "standard/default/common-pc/base"
+                       </literallayout></para></listitem> -->
                </itemizedlist>
            </para>
 
@@ -446,7 +465,7 @@
                unused <filename>.bbappend</filename> files.
                Alternatively, you can simply remove all the files 
                except the one your are using for the build 
-               (i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).
+               (i.e. <filename>linux-yocto_3.2.bbappend</filename> in this example).
            </note>            
        </section>
 
@@ -505,8 +524,8 @@
         <title>Changing the Kernel Configuration</title>
 
         <para>
-            This example changes the default behavior, which is "off", of the Symmetric 
-            Multi-processing Support (<filename>CONFIG_SMP</filename>) to "on".  
+            This example changes the default behavior, which is "on", of the Symmetric 
+            Multi-processing Support (<filename>CONFIG_SMP</filename>) to "off".  
             It is a simple example that demonstrates how to reconfigure the kernel.
         </para>
 
@@ -518,9 +537,9 @@
                 in "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
                 Code</link>" you should already have the Yocto Project files set up on your 
                 host machine.
-                If this is the case, go to then next section titled
+                If this is the case, go to the next section, which is titled
                 "<link linkend='examining-the-default-config-smp-behavior'>Examining the Default
-                <filename>CONFIG_SMP</filename> Behavior</link>" and continue with the 
+                <filename>CONFIG_SMP</filename> Behavior</link>", and continue with the 
                 example.
             </para>
 
@@ -529,7 +548,7 @@
                 you can get them through tarball extraction or by 
                 cloning the <filename>poky</filename> Git repository.  
                 This example uses <filename>poky</filename> as the root directory of the 
-                local Yocto Project files Git repository.
+                local <link linkend='yocto-project-files'>Yocto Project Files</link> Git repository.
                 See the bulleted item
                 "<link linkend='local-yp-release'>Yocto Project Release</link>"
                 for information on how to get these files.
@@ -545,13 +564,13 @@
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1.1 Release code named "&DISTRO_NAME;", 
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
                 which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
                 The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
-     Branch edison set up to track remote branch &DISTRO_NAME; from origin.
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
      Switched to a new branch '&DISTRO_NAME;'
                 </literallayout>
             </para>
@@ -612,11 +631,11 @@
             <title>Examining the Default&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Behavior</title>
 
             <para>
-                By default, <filename>CONFIG_SMP</filename> supports single processor machines.
+                By default, <filename>CONFIG_SMP</filename> supports multiple processor machines.
                 To see this default setting from within the QEMU emulator, boot your image using 
                 the emulator as follows:
                 <literallayout class='monospaced'>
-     $ runqemu qemux86 qemuparams="-smp 2"
+     $ runqemu qemux86 qemuparams="-smp 4"
                 </literallayout>
             </para>
 
@@ -624,11 +643,25 @@
                 Login to the machine using <filename>root</filename> with no password.
                 After logging in, enter the following command to see how many processors are 
                 being supported in the emulator.
-                The emulator reports support for a single processor:
+                The emulator reports support for the number of processors you specified using 
+                the <filename>-smp</filename> option, four in this case:
                 <literallayout class='monospaced'>
      # cat /proc/cpuinfo | grep processor 
      processor       : 0
+     processor       : 1
+     processor       : 2
+     processor       : 3
      #
+                </literallayout>
+                To check the setting for <filename>CONFIG_SMP</filename>, you can use the 
+                following command:
+                <literallayout class='monospaced'>
+     zcat /proc/config.gz | grep CONFIG_SMP
+                </literallayout>
+                The console returns the following showing that multi-processor machine support
+                is set:
+                <literallayout class='monospaced'>
+     CONFIG_SMP=y
                 </literallayout>
                 Logout of the emulator using the <filename>exit</filename> command and 
                 then close it down.
@@ -654,15 +687,25 @@
             <para>
                 After setting up the environment to run <filename>menuconfig</filename>, you are ready 
                 to use the tool to interactively change the kernel configuration.
-                In this example, we are basing our changes on the <filename>linux-yocto-3.0-1.1.x</filename>
+                In this example, we are basing our changes on the <filename>linux-yocto-3.2</filename>
                 kernel.
                 The Yocto Project build environment recognizes this kernel as 
                 <filename>linux-yocto</filename>.
-                Thus, the following command from the shell in which you previously sourced the 
-                environment initialization script launches <filename>menuconfig</filename>:
+                Thus, the following commands from the shell in which you previously sourced the 
+                environment initialization script cleans the shared state memory and the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>
+                directory and then builds and launches <filename>menuconfig</filename>:
                 <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c cleansstate
      $ bitbake linux-yocto -c menuconfig
                 </literallayout>
+                <note>
+                    Due to a bug in the release, it is necessary to clean the shared state memory
+                    in order for configurations made using <filename>menuconfig</filename> to take
+                    effect.
+                    For information on the bug, see
+                    <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=2256'></ulink>
+                </note>
             </para>
                   
             <para>
@@ -671,7 +714,7 @@
                 You can find it at <filename>Processor Type and Features</filename>.
                 The configuration selection is 
                 <filename>Symmetric Multi-processing Support</filename>.
-                After using the arrow keys to highlight this selection, press "y" to select it.
+                After using the arrow keys to highlight this selection, press "n" to turn it off.
                 Then, exit out and save your selections.
             </para>
 
@@ -680,22 +723,25 @@
                 is updated. 
                 This is the file that the build system uses to configure the Linux Yocto kernel
                 when it is built. 
-                You can find and examine this file in the Yocto Project files Git repository in 
+                You can find and examine this file in the Yocto Project Files Git repository in 
                 the build directory. 
-                This example uses the following.
-                Note that this example directory is artificially split and many of the characters 
-                in the actually filename are omitted in order to make it more
-                readable:
+                This example uses the following:
                 <literallayout class='monospaced'>
-     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+84f...
-        ...r20/linux-qemux86-standard-build
+     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.2.11+git1+84f...
+        ...656ed30-r1/linux-qemux86-standard-build
                 </literallayout>
+                <note>
+                    The previous example directory is artificially split and many of the characters 
+                    in the actual filename are omitted in order to make it more readable.
+                    Also, depending on the kernel you are using, the exact pathname might differ 
+                    slightly.
+                </note>
             </para>
 
             <para>
                 Within the <filename>.config</filename> file, you can see the following setting:
                 <literallayout class='monospaced'>
-     CONFIG_SMP=y
+     # CONFIG_SMP is not set
                 </literallayout>
             </para>
 
@@ -729,11 +775,22 @@
      $ bitbake linux-yocto
                 </literallayout>
             </para>
+
+            <note>
+                Manually turning off a kernel configuration setting such as 
+                <filename>CONFIG_SMP</filename> can cause the kernel configuration audit
+                to issue warnings during the build. 
+                In this example, warnings appear telling you that the expected value
+                <filename>CONFIG_SMP</filename> does not appear in the <filename>.config</filename>
+                file.
+                Because in this example you specifically turned off <filename>CONFIG_SMP</filename>,
+                you can safely ignore the apparent conflict.
+            </note>
  
             <para>
-                Now run the QEMU emulator:
+                Now run the QEMU emulator and pass it the same multi-processor option as before:
                 <literallayout class='monospaced'>
-     $ runqemu qemux86 qemuparams="-smp 2"
+     $ runqemu qemux86 qemuparams="-smp 4"
                 </literallayout>
             </para>
 
@@ -743,13 +800,22 @@
                 <literallayout class='monospaced'>
      # cat /proc/cpuinfo | grep processor 
      processor       : 0
-     processor       : 1
      #
                 </literallayout>
             </para>
 
             <para>
-                From the output, you can see that you have successfully reconfigured the kernel.
+                From the output, you can see that the kernel no longer supports multi-processor systems.
+                The output indicates support for a single processor.  You can verify the 
+                <filename>CONFIG_SMP</filename> setting by using this command:
+                <literallayout class='monospaced'>
+     zcat /proc/config.gz | grep CONFIG_SMP
+                </literallayout>
+                The console returns the following output:
+                <literallayout class='monospaced'>
+     # CONFIG_SMP is not set
+                </literallayout>
+                You have successfully reconfigured the kernel.
             </para>
         </section>
     </section>

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

@@ -120,13 +120,15 @@
                     Crown Bay that does not support the <trademark class='registered'>Intel</trademark> 
                     Embedded Media Graphics Driver (EMGD).  
                     The remainder of this example uses that base BSP.</para>
-                    <para>To see the supported BSPs, go to the Yocto Project
-                    <ulink url='&YOCTO_DL_URL;/download'>download page</ulink> and click 
-                    on “BSP Downloads.”</para></listitem>
+                    <para>To see the supported BSPs, go to the 
+                    <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page on the Yocto Project
+                    website and click on “BSP Downloads.”</para></listitem>
                 <listitem><para><emphasis>Create your own BSP layer</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 for your BSP.
                     In fact, a BSP is, in itself, a special type of layer.   
+                    </para>
+                    <para>
                     Another example that illustrates a layer is an application.  
                     Suppose you are creating an application that has library or other dependencies in 
                     order for it to compile and run.  
@@ -134,16 +136,22 @@
                     are kept.  
                     The key point for a layer is that it is an isolated area that contains 
                     all the relevant information for the project that the Yocto Project build 
-                    system knows about.</para>
+                    system knows about.
+                    For more information on layers, see the 
+                    "<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>"
+                    section.
+                    For more information on BSP layers, see the
+                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" section in the 
+                    Yocto Project Board Support Package (BSP) Developer's Guide.</para>
                     <note>The Yocto Project supports four BSPs that are part of the 
                     Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>,
                     <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.  
                     The recipes and configurations for these four BSPs are located and dispersed 
-                    within the local Yocto Project files.
-                    Consequently, they are not totally isolated in the spirit of layers unless you think 
-                    of <filename>meta-yocto</filename> as a layer itself.  
+                    within the <link linkend='yocto-project-files'>Yocto Project Files</link>.
                     On the other hand, BSP layers for Crown Bay, Emenlow, Jasper Forest, 
-                    N450, and Sugar Bay are isolated.</note>
+                    N450, Cedar Trail, Fish River, Fish River Island II, Romley, sys940x, tlk, 
+                    and Sugar Bay 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
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
@@ -235,7 +243,7 @@
                 <ulink url='&YOCTO_GIT_URL;'></ulink>.
                 If you look at the interface, you will see to the left a grouping of 
                 Git repositories titled "Yocto Linux Kernel."  
-                Within this group, you will find the four different kernels supported by 
+                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 
@@ -247,6 +255,9 @@
                     <listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The 
                     stable Linux Yocto kernel to use with the Yocto Project Release 1.1.x. This kernel 
                     is based on the Linux 3.0 release</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.2</filename></emphasis> - The 
+                    stable Linux Yocto kernel to use with the Yocto Project Release 1.2. This kernel 
+                    is based on the Linux 3.2 release</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>
@@ -288,7 +299,7 @@
             </para>
 
             <note>
-                Keep in mind the figure does not take into account all four supported Linux Yocto
+                Keep in mind the figure does not take into account all the supported Linux Yocto
                 kernel types, but rather shows a single generic kernel just for conceptual purposes.
                 Also keep in mind that this structure represents the Yocto Project source repositories 
                 that are either pulled from during the build or established on the host development system
@@ -325,7 +336,7 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-overview-3.png" 
+                <imagedata fileref="figures/kernel-overview-3-denzil.png" 
                     width="6in" depth="4in" align="center" scale="100" />
             </para> 
 
@@ -363,11 +374,11 @@
             <para>
                 Again, for a complete discussion of the Yocto Project kernel's architcture and its 
                 branching strategy,
-                see the <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
+                see <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
                 The Yocto Project Kernel Architecture and Use Manual</ulink>.
-                Also, you can reference 
-                <xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</xref>
-                for a detailed example that modifies the kernel.
+                You can also reference the
+                "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</link>"
+                section for a detailed example that modifies the kernel.
             </para>
         </section> 
 
@@ -461,7 +472,7 @@
                     <listitem><para><emphasis>Prepare for the build</emphasis>:  Once you have made all the 
                         changes to your kernel (configurations, source code changes, recipe additions, 
                         or recipe changes), there remains a few things 
-                        you need to do in order for the Yocto Project build system to create your image.  
+                        you need to do in order for the Yocto Project build system (BitBake) to create your image.  
                         If you have not done so, you need to get the build environment ready by sourcing 
                         the environment setup script described earlier.
                         You also need to be sure two key configuration files 
@@ -574,7 +585,7 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     You must have a target kernel image that has been built using the Yocto Project.</para>
                     <para>Depending on whether the Yocto Project has a pre-built image that matches your target
                     architecture and where you are going to run the image while you develop your application
-                    (QEMU or real hardware), the area you get the image from differs.
+                    (QEMU or real hardware), the area from which you get the image differs.
                         <itemizedlist>
                             <listitem><para>Download the image from  
                                 <ulink url='&YOCTO_MACHINES_DL_URL;'>  
@@ -717,8 +728,8 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
             <listitem><para>You can modify various policy settings such as the package format used to build with, 
                 the parrallelism 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'>Understanding 
-                and Creating layers</link>.</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.
                 </para></listitem>
             <listitem><para>You can launch and monitor the build from within Hob.</para></listitem>

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

@@ -335,7 +335,8 @@
                 The area is created when you <filename>source</filename> the Yocto Project setup 
                 environment script that is found in the Yocto Project files area
                 (i.e. <filename>oe-init-build-env</filename>).
-                The <filename>TOPDIR</filename> variable points to the build directory.</para>
+                The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
+                variable points to the build directory.</para>
            
                 <para>You have a lot of flexibility when creating the Yocto Project Build Directory.
                 Following are some examples that show how to create the directory:
@@ -494,7 +495,8 @@
             Git uses "branches" to organize different development efforts. 
             For example, the <filename>poky</filename> repository has 
             <filename>laverne</filename>, <filename>bernard</filename>, 
-            <filename>edison</filename>, and <filename>master</filename> branches among 
+            <filename>edison</filename>, <filename>denzil</filename> and 
+            <filename>master</filename> branches among 
             others.
             You can see all the branches by going to  
             <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/'></ulink> and 
@@ -525,7 +527,7 @@
      $ cd ~
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
-     $ git checkout &DISTRO_NAME; -b &DISTRO_NAME;
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
             </literallayout>
             In this example, the name of the top-level directory of your local Yocto Project 
             Files Git repository is <filename>poky</filename>.
@@ -577,14 +579,14 @@
      $ cd ~
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
-     $ git checkout &DISTRO_NAME;-&POKYVERSION; -b &DISTRO_NAME;-&POKYVERSION;
+     $ git checkout -b my-&DISTRO_NAME;-&POKYVERSION; &DISTRO_NAME;-&POKYVERSION;
             </literallayout>
             In this example, the name of the top-level directory of your local Yocto Project 
             Files Git repository is <filename>poky</filename>.
             And, the name of the local branch you have created and checked out is
-            <filename>&DISTRO_NAME;-&POKYVERSION;</filename>.
+            <filename>my-&DISTRO_NAME;-&POKYVERSION;</filename>.
             The files in your repository now exactly match the Yocto Project &DISTRO;
-            Release tag (&DISTRO_NAME;).
+            Release tag (<filename>&DISTRO_NAME;-&POKYVERSION;</filename>).
             It is important to understand that when you create and checkout a local 
             working branch based on a tag, your environment matches a specific point 
             in time and not a development branch.

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

@@ -31,7 +31,8 @@
     </para>
 
     <para>
-        You can use the Yocto Project, which uses the BitBake build tool, to develop complete Linux 
+        You can use the Yocto Project build system, which uses 
+        <ulink url='http://bitbake.berlios.de/manual/'>BitBake</ulink>, to develop complete Linux 
         images and associated user-space applications for architectures based on ARM, MIPS, PowerPC, 
         x86 and x86-64.  
         While the Yocto Project does not provide a strict testing framework,
@@ -109,11 +110,11 @@
                         <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Initialized empty Git repository in /home/scottrif/poky/.git/
-     remote: Counting objects: 116882, done.
-     remote: Compressing objects: 100% (35987/35987), done.
-     remote: Total 116882 (delta 80651), reused 113045 (delta 77578)
-     Receiving objects: 100% (116882/116882), 72.13 MiB | 2.68 MiB/s, done.
-     Resolving deltas: 100% (80651/80651), done.
+     remote: Counting objects: 141863, done.
+     remote: Compressing objects: 100% (38624/38624), done.
+     remote: Total 141863 (delta 99661), reused 141816 (delta 99614)
+     Receiving objects: 100% (141863/141863), 76.64 MiB | 126 KiB/s, done.
+     Resolving deltas: 100% (99661/99661), done.
                         </literallayout></para>
                         <para>For another example of how to set up your own local Git repositories, see this
                         <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
@@ -132,29 +133,29 @@
                 For simplicity, it is recommended that you create these structures outside of the 
                 Yocto Project Files Git repository.</para>
                 <para>As an example, the following transcript shows how to create the bare clone
-                of the <filename>linux-yocto-3.0-1.1.x</filename> kernel and then create a copy of 
+                of the <filename>linux-yocto-3.2</filename> kernel and then create a copy of 
                 that clone.
                 <note>When you have a local Linux Yocto kernel Git repository, you can 
                 reference that repository rather than the upstream Git repository as 
                 part of the <filename>clone</filename> command.
                 Doing so can speed up the process.</note></para>
                 <para>In the following example, the bare clone is named 
-                <filename>linux-yocto-3.0-1.1.x.git</filename>, while the 
-                copy is named <filename>my-linux-yocto-3.0-1.1.x-work</filename>: 
+                <filename>linux-yocto-3.2.git</filename>, while the 
+                copy is named <filename>my-linux-yocto-3.2-work</filename>: 
                 <literallayout class='monospaced'>
-     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0-1.1.x linux-yocto-3.0-1.1.x.git
-     Initialized empty Git repository in /home/scottrif/linux-yocto-3.0-1.1.x.git/
-     remote: Counting objects: 2259181, done.
-     remote: Compressing objects: 100% (373259/373259), done.
-     remote: Total 2259181 (delta 1892638), reused 2231556 (delta 1865300)
-     Receiving objects: 100% (2259181/2259181), 482.44 MiB | 580 KiB/s, done.
-     Resolving deltas: 100% (1892638/1892638), done.
+     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2 linux-yocto-3.2.git
+     Initialized empty Git repository in /home/scottrif/linux-yocto-3.2.git/
+     remote: Counting objects: 2468027, done.
+     remote: Compressing objects: 100% (392255/392255), done.
+     remote: Total 2468027 (delta 2071693), reused 2448773 (delta 2052498)
+     Receiving objects: 100% (2468027/2468027), 530.46 MiB | 129 KiB/s, done.
+     Resolving deltas: 100% (2071693/2071693), done.
                 </literallayout></para>
                 <para>Now create a clone of the bare clone just created:
                 <literallayout class='monospaced'>
-     $ git clone linux-yocto-3.0-1.1.x.git my-linux-yocto-3.0-1.1.x-work
-     Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.0-1.1.x/.git/
-     Checking out files: 100% (36898/36898), done.
+     $ git clone linux-yocto-3.2.git my-linux-yocto-3.2-work
+     Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.2-work/.git/
+     Checking out files: 100% (37619/37619), done.
                 </literallayout></para></listitem>
             <listitem id='poky-extras-repo'><para><emphasis>
                 The <filename>poky-extras</filename> Git Repository</emphasis>:
@@ -175,14 +176,13 @@
                 repository inside the Yocto Project files Git repository, which is named 
                 <filename>poky</filename> in this case:
                 <literallayout class='monospaced'>
-     $ cd ~/poky
      $ git clone git://git.yoctoproject.org/poky-extras poky-extras
      Initialized empty Git repository in /home/scottrif/poky/poky-extras/.git/
-     remote: Counting objects: 561, done.
-     remote: Compressing objects: 100% (501/501), done.
-     remote: Total 561 (delta 159), reused 306 (delta 39)
-     Receiving objects: 100% (561/561), 519.96 KiB | 479 KiB/s, done.
-     Resolving deltas: 100% (159/159), done.
+     remote: Counting objects: 618, done.
+     remote: Compressing objects: 100% (558/558), done.
+     remote: Total 618 (delta 192), reused 307 (delta 39)
+     Receiving objects: 100% (618/618), 526.26 KiB | 111 KiB/s, done.
+     Resolving deltas: 100% (192/192), done.
                 </literallayout></para></listitem>
            <listitem><para id='supported-board-support-packages-(bsps)'><emphasis>Supported Board 
                 Support Packages (BSPs):</emphasis>  
@@ -231,14 +231,13 @@
                         <filename>meta-intel</filename>
                         Git repository inside the <filename>poky</filename> Git repository.
                         <literallayout class='monospaced'>
-     $ cd poky
      $ git clone git://git.yoctoproject.org/meta-intel.git
      Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/
-     remote: Counting objects: 1325, done.
-     remote: Compressing objects: 100% (1078/1078), done.
-     remote: Total 1325 (delta 546), reused 85 (delta 27)
-     Receiving objects: 100% (1325/1325), 1.56 MiB | 330 KiB/s, done.
-     Resolving deltas: 100% (546/546), done.
+     remote: Counting objects: 3380, done.
+     remote: Compressing objects: 100% (2750/2750), done.
+     remote: Total 3380 (delta 1689), reused 227 (delta 113)
+     Receiving objects: 100% (3380/3380), 1.77 MiB | 128 KiB/s, done.
+     Resolving deltas: 100% (1689/1689), done.
                         </literallayout></para>
                         <para>The same  
                         <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>

documentation/dev-manual/dev-manual.xml

@@ -36,8 +36,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2.1</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.2.1 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/kernel-manual/kernel-manual.xml

@@ -51,8 +51,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2.1</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.2.1 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/poky-ref-manual/poky-ref-manual.xml

@@ -65,8 +65,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2.1</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.2.1 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/poky-ref-manual/ref-images.xml

@@ -106,6 +106,14 @@
             instead of X11.  
             In order to build, this image requires specific distro configuration that enables 
             <filename>gtk</filename> over <filename>directfb</filename>.</para></listitem>
+        <listitem><para><emphasis><filename>self-hosted-image</filename>:</emphasis>
+            An image you can run using the Yocto Project Build Appliance.
+            The image is suitable to load and boot from either 
+            <ulink url='http://www.vmware.com/products/player/overview.html'>VMware Player</ulink>
+            or <ulink url='http://www.vmware.com/products/workstation/overview.html'>VMWare Workstation</ulink>.
+            For more information on the Build Appliance, see the
+            <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on 
+            the Yocto Project website.</para></listitem>
     </itemizedlist>
 
     <tip>

documentation/poky.ent

@@ -1,7 +1,7 @@
-<!ENTITY DISTRO "1.2">
+<!ENTITY DISTRO "1.2.1">
 <!ENTITY DISTRO_NAME "denzil">
-<!ENTITY YOCTO_DOC_VERSION "latest">
-<!ENTITY POKYVERSION "7.0">
+<!ENTITY YOCTO_DOC_VERSION "current">
+<!ENTITY POKYVERSION "7.0.1">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
 <!ENTITY COPYRIGHT_YEAR "2010-2012">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">

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

@@ -21,15 +21,23 @@
     </para>
 
     <para>
-        If you know all about open-source development, Linux development environments, Git source
-        repositories and the like and you just want some quick information that lets you try out
-        the Yocto Project, skip right to the "<link linkend='super-user'>Super User</link>" section at 
-        the end of this quick start.
-        Otherwise, keep reading...
+        If you don't have a system that runs Linux and you want to give the Yocto Project a test run, 
+        you might consider using the Yocto Project Build Appliance.
+        The Build Appliance allows you to build and boot a custom embedded Linux image with the Yocto 
+        Project using a non-Linux development system.  
+        See the <ulink url='http://www.yoctoproject.org/documentation/build-appliance'>Yocto 
+        Project Build Appliance</ulink> for more information.
     </para>
 
     <para>
-        This short document will give you some basic information about the environment and 
+        On the other hand, if you know all about open-source development, Linux development environments, 
+        Git source repositories and the like and you just want some quick information that lets you try out
+        the Yocto Project on your Linux system, skip right to the 
+        "<link linkend='super-user'>Super User</link>" section at the end of this quick start.
+    </para>
+
+    <para>
+        For the rest of you, this short document will give you some basic information about the environment and 
         let you experience it in its simplest form.  
         After reading this document, you will have a basic understanding of what the Yocto Project is
         and how to use some of its core components.  
@@ -220,11 +228,11 @@
             </para>
 
                 <literallayout class='monospaced'>
-     $ sudo apt-get install sed wget cvs subversion git-core coreutils \
+     $ sudo apt-get install sed wget subversion git-core coreutils \
      unzip texi2html texinfo libsdl1.2-dev docbook-utils fop gawk \
-     python-pysqlite2 diffstat help2man make gcc build-essential xsltproc \
+     python-pysqlite2 diffstat make gcc build-essential xsltproc \
      g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
-     mercurial autoconf automake groff libtool xterm libxml-parser-perl
+     autoconf automake groff libtool xterm libxml-parser-perl
                 </literallayout>
         </section>
 
@@ -238,26 +246,16 @@
 
                 <literallayout class='monospaced'>
      $ sudo yum groupinstall "development tools"
-     $ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
-     unzip python-psyco perl texinfo texi2html diffstat openjade \
+     $ sudo yum install python m4 make wget curl ftp tar bzip2 gzip \
+     unzip perl texinfo texi2html diffstat openjade \
      docbook-style-dsssl sed docbook-style-xsl docbook-dtds fop xsltproc \
      docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
-     groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
+     groff linuxdoc-tools patch cmake \
      perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
      SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
      autoconf automake libtool xterm
                 </literallayout>
 
-            <note><para>
-                If you are using a Fedora version prior to version 15, you will need to take some 
-                extra steps to enable <filename>sudo</filename>, or you will need to run
-                the commands as root user.
-                See the <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'>Configuring Sudo</ulink> 
-                wiki page for details.
-                For information on other dependencies you will need to install, see the Fedora section on the
-                <ulink url='&YOCTO_WIKI_URL;/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
-                wiki page.
-            </para></note>
         </section>
 
         <section id='opensuse'>
@@ -270,8 +268,8 @@
 
                 <literallayout class='monospaced'>
      $ sudo zypper install python gcc gcc-c++ libtool fop \
-     subversion git chrpath automake make wget help2man xsltproc \
-     diffstat texinfo mercurial freeglut-devel libSDL-devel
+     subversion git chrpath automake make wget xsltproc \
+     diffstat texinfo freeglut-devel libSDL-devel
                 </literallayout>
         </section>
 
@@ -290,7 +288,7 @@
        unzip perl texinfo texi2html diffstat openjade zlib-devel \
        docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
        docbook-utils bc glibc-devel pcre pcre-devel \
-       groff linuxdoc-tools patch linuxdoc-tools cmake \
+       groff linuxdoc-tools patch cmake \
        tcl-devel gettext ncurses apr \
        SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
        autoconf automake libtool xterm
@@ -336,7 +334,7 @@
     <title>A Quick Test Run</title>
 
     <para>
-        Now that you have your system requirements in order, you can give Yocto Project a try.  
+        Now that you have your system requirements in order, you can give the Yocto Project a try.  
         This section presents some steps that let you do the following:
     </para>
 
@@ -403,7 +401,7 @@
              Adding this statement deletes the work directory used for building a package
              once the package is built.
              <literallayout class='monospaced'>
-     INHERIT += rm_work
+     INHERIT += "rm_work"
              </literallayout>
          </para></tip>
 
@@ -412,8 +410,8 @@
                  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</ulink>
-                 Downloads page to retrieve the tarball.</para></listitem>
+                 <ulink url='&YOCTO_HOME_URL;/download'>Yocto Project website's Downloads page</ulink>
+                 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>
@@ -632,7 +630,7 @@
                 You must use the <filename>ext3</filename> form when booting an image using the 
                 QEMU emulator.
                 The <filename>tar</filename> form can be flattened out in your host development system
-                and used for Yocto Project build purposes.
+                and used for build purposes with the Yocto Project.
                 <literallayout class='monospaced'>
      core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.ext3
      core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.tar.bz2
@@ -686,11 +684,13 @@
             <para>
                 Continuing with the example, the following two commands setup the emulation 
                 environment and launch QEMU.
-                This example assumes the root filesystem tarball has been downloaded and expanded, and 
-                that the kernel and filesystem are for a 32-bit target architecture.
+                This example assumes the root filesystem (<filename>.ext3</filename> file) and 
+                the pre-built kernel image file both reside in your home directory. 
+                The kernel and filesystem are for a 32-bit target architecture.
                 <literallayout class='monospaced'>
-     $ source &YOCTO_ADTPATH_DIR;/environment-setup-i686-poky-linux 
-     $ runqemu qemux86 bzImage-qemux86-&DISTRO;.bin \
+     $ cd $HOME
+     $ source &YOCTO_ADTPATH_DIR;/environment-setup-i586-poky-linux 
+     $ runqemu qemux86 bzImage-qemux86.bin \
      core-image-sato-qemux86.ext3
                 </literallayout>
             </para>

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

@@ -64,16 +64,6 @@ ASSUME_PROVIDED += "pkgconfig$"
 # Comment out any of the lines below to disable them in the build
 DISTRO_FEATURES_LIBC_TINY = "libc-libm libc-crypt"
 
-# Building meta-toolchain currently imposes some additional requirements:
-# If you do not plan to build meta-toolchain, you can save ~461KB by
-# commenting out the DISTRO_FEATURES_LIBC_TOOLCHAIN assignment
-# gettext needs wchar, m4 needs spawn and locale, elfutils needs ftraverse
-DISTRO_FEATURES_LIBC_TOOLCHAIN = "libc-posix-clang-wchar \
-                                  libc-spawn libc-locale-code \
-                                  libc-ftraverse libc-libm-big \
-                                  libc-posix-regexp-glibc \
-                                 "
-
 # Required for "who"
 DISTRO_FEATURES_LIBC_MINIMAL = "libc-utmp libc-getlogin"
 DISTRO_FEATURES_LIBC_REGEX = "libc-posix-regexp"
@@ -83,7 +73,6 @@ DISTRO_FEATURES_LIBC = "${DISTRO_FEATURES_LIBC_TINY} \
                         ${DISTRO_FEATURES_LIBC_MINIMAL} \
                         ${DISTRO_FEATURES_LIBC_REGEX} \
                         ${DISTRO_FEATURES_LIBC_NET} \
-                        ${DISTRO_FEATURES_LIBC_TOOLCHAIN} \
                        "
 
 # Comment out any of the lines below to disable them in the build
@@ -125,3 +114,8 @@ IMAGE_FSTYPES = "ext2 cpio.gz"
 #        variants of all compatible machines, but that leads to a lot
 #        more machine configs to maintain long term.
 MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
+
+# The mtrace script included by eglibc is a perl script. This means the system
+# will build perl in case this package is installed. Since we don't care about
+# this script for the purposes of tiny, remove the dependency from here.
+RDEPENDS_${PN}-mtrace_pn-eglibc = ""

meta-yocto/conf/distro/poky.conf

@@ -1,8 +1,8 @@
 DISTRO = "poky"
-DISTRO_NAME = "Yocto (Built by Poky 6.0)"
-DISTRO_VERSION = "1.1+snapshot-${DATE}"
+DISTRO_NAME = "Yocto (Built by Poky 7.0.1)"
+DISTRO_VERSION = "1.2.1"
 SDK_VENDOR = "-pokysdk"
-SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
+SDK_VERSION := "${DISTRO_VERSION}" 
 
 MAINTAINER = "Poky <poky@yoctoproject.org>"
 
@@ -69,7 +69,7 @@ SANITY_TESTED_DISTROS ?= " \
             Yocto (Built by Poky 7.0) 1.2 \n \
             Ubuntu 10.04.4 LTS \n \
             Ubuntu 11.10 \n \
-            Ubuntu 12.04 \n \
+            Ubuntu 12.04 LTS \n \
             Fedora release 15 (Lovelock) \n \
             Fedora release 16 (Verne) \n \
             Fedora release 17 (Beefy Miracle) \n \

meta-yocto/recipes-core/netbase/netbase_4.47.bbappend

@@ -1 +1 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

meta/classes/buildhistory.bbclass

@@ -402,7 +402,7 @@ buildhistory_commit() {
 			git add ${BUILDHISTORY_DIR}/*
 			HOSTNAME=`hostname 2>/dev/null || echo unknown`
 			# porcelain output looks like "?? packages/foo/bar"
-			for entry in `echo $repostatus | awk '{print $2}' | awk -F/ '{print $1}' | sort | uniq` ; do
+			for entry in `echo "$repostatus" | awk '{print $2}' | awk -F/ '{print $1}' | sort | uniq` ; do
 				git commit ${BUILDHISTORY_DIR}/$entry -m "$entry: Build ${BUILDNAME} of ${DISTRO} ${DISTRO_VERSION} for machine ${MACHINE} on $HOSTNAME" --author "${BUILDHISTORY_COMMIT_AUTHOR}" > /dev/null
 			done
 			if [ "${BUILDHISTORY_PUSH_REPO}" != "" ] ; then

meta/classes/gconf.bbclass

@@ -1,10 +1,18 @@
 DEPENDS += "gconf gconf-native"
 
-# This is referenced by the gconf m4 macros and would default to the value hardcoded
-# into gconf at compile time otherwise
+# These are for when gconftool is used natively and the prefix isn't necessarily
+# the sysroot.  TODO: replicate the postinst logic for -native packages going
+# into sysroot as they won't be running their own install-time schema
+# registration (disabled below) nor the postinst script (as they don't happen).
 export GCONF_SCHEMA_INSTALL_SOURCE = "xml:merged:${STAGING_DIR_NATIVE}${sysconfdir}/gconf/gconf.xml.defaults"
 export GCONF_BACKEND_DIR = "${STAGING_LIBDIR_NATIVE}/GConf/2"
 
+# Disable install-time schema registration as we're a packaging system so this
+# happens in the postinst script, not at install time.  Set both the configure
+# script option and the traditional envionment variable just to make sure.
+EXTRA_OECONF += "--disable-schemas-install"
+export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL = "1"
+
 gconf_postinst() {
 if [ "x$D" != "x" ]; then
 	exit 1

meta/classes/gettext.bbclass

@@ -15,7 +15,7 @@ def gettext_oeconf(d):
         return '--disable-nls'
     return "--enable-nls"
 
-DEPENDS_GETTEXT = "virtual/gettext gettext-native"
+DEPENDS_GETTEXT ??= "virtual/gettext gettext-native"
 
 BASEDEPENDS =+ "${@gettext_dependencies(d)}"
 EXTRA_OECONF_append = " ${@gettext_oeconf(d)}"

meta/classes/image.bbclass

@@ -131,6 +131,7 @@ PSEUDO_PASSWD = "${IMAGE_ROOTFS}"
 do_rootfs[nostamp] = "1"
 do_rootfs[dirs] = "${TOPDIR}"
 do_rootfs[lockfiles] += "${IMAGE_ROOTFS}.lock"
+do_rootfs[cleandirs] += "${S}"
 do_build[nostamp] = "1"
 
 # Must call real_do_rootfs() from inside here, rather than as a separate

meta/classes/kernel.bbclass

@@ -276,9 +276,7 @@ fi
 }
 
 pkg_postinst_modules () {
-if [ -n "$D" ]; then
-	${HOST_PREFIX}depmod -A -b $D -F ${STAGING_KERNEL_DIR}/System.map-${KERNEL_VERSION} ${KERNEL_VERSION}
-else
+if [ -z "$D" ]; then
 	depmod -a
 	update-modules || true
 fi

meta/classes/mirrors.bbclass

@@ -1,5 +1,5 @@
 MIRRORS += "\
-${DEBIAN_MIRROR}/main	http://snapshot.debian.net/archive/pool \n \
+${DEBIAN_MIRROR}/main	http://snapshot.debian.org/archive/debian-archive/20120328T092752Z/debian/pool/ \n \
 ${DEBIAN_MIRROR}	ftp://ftp.de.debian.org/debian/pool \n \
 ${DEBIAN_MIRROR}	ftp://ftp.au.debian.org/debian/pool \n \
 ${DEBIAN_MIRROR}	ftp://ftp.cl.debian.org/debian/pool \n \

meta/classes/module.bbclass

@@ -37,15 +37,14 @@ module_do_install() {
 }
 
 pkg_postinst_append () {
-	if [ -n "$D" ]; then
-		exit 1
-	fi
+if [ -z "$D" ]; then
 	depmod -a
 	update-modules || true
+fi
 }
 
 pkg_postrm_append () {
-	update-modules || true
+update-modules || true
 }
 
 EXPORT_FUNCTIONS do_compile do_install

meta/classes/package.bbclass

@@ -870,6 +870,14 @@ python split_and_strip_files () {
 				elf_file = int(file_list[file][5:])
 				#bb.note("Strip %s" % file)
 				runstrip(file, elf_file, d)
+
+
+	if (d.getVar('INHIBIT_PACKAGE_STRIP', True) != '1'):	
+		for root, dirs, files in os.walk(dvar):
+			for f in files:
+				if not f.endswith(".ko"):
+					continue
+				runstrip(os.path.join(root, f), None, d)
 	#
 	# End of strip
 	#

meta/classes/patch.bbclass

@@ -1,7 +1,7 @@
 # Copyright (C) 2006  OpenedHand LTD
 
 # Point to an empty file so any user's custom settings don't break things
-QUILTRCFILE ?= "${STAGING_BINDIR_NATIVE}/quiltrc"
+QUILTRCFILE ?= "${STAGING_ETCDIR_NATIVE}/quiltrc"
 
 PATCHDEPENDENCY = "${PATCHTOOL}-native:do_populate_sysroot"
 

meta/classes/sanity.bbclass

@@ -4,7 +4,16 @@
 
 SANITY_REQUIRED_UTILITIES ?= "patch diffstat texi2html makeinfo svn bzip2 tar gzip gawk chrpath wget cpio"
 
-def raise_sanity_error(msg):
+def raise_sanity_error(msg, d):
+    if d.getVar("SANITY_USE_EVENTS", True) == "1":
+        # FIXME: handle when BitBake version is too old to support bb.event.SanityCheckFailed
+        # We can just fire the event directly once the minimum version is bumped beyond 1.15.1
+        try:
+            bb.event.fire(bb.event.SanityCheckFailed(msg), d)
+            return
+        except AttributeError:
+            pass
+
     bb.fatal(""" OE-core's config sanity checker detected a potential misconfiguration.
     Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
     Following is the list of potential problems / advisories:
@@ -112,8 +121,8 @@ def check_connectivity(d):
 
     return retval
 
-def check_supported_distro(e):
-    tested_distros = e.data.getVar('SANITY_TESTED_DISTROS', True)
+def check_supported_distro(sanity_data):
+    tested_distros = sanity_data.getVar('SANITY_TESTED_DISTROS', True)
     if not tested_distros:
         return
 
@@ -160,26 +169,26 @@ def check_supported_distro(e):
         bb.warn('Host distribution could not be determined; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.')
 
 # Checks we should only make if MACHINE is set correctly
-def check_sanity_validmachine(e):
+def check_sanity_validmachine(sanity_data):
     from bb import data
 
     messages = ""
 
     # Check TUNE_ARCH is set
-    if data.getVar('TUNE_ARCH', e.data, True) == 'INVALID':
+    if data.getVar('TUNE_ARCH', sanity_data, True) == 'INVALID':
         messages = messages + 'TUNE_ARCH is unset. Please ensure your MACHINE configuration includes a valid tune configuration file which will set this correctly.\n'
 
     # Check TARGET_ARCH is set correctly
-    if data.getVar('TARGE_ARCH', e.data, False) == '${TUNE_ARCH}':
+    if data.getVar('TARGE_ARCH', sanity_data, False) == '${TUNE_ARCH}':
         messages = messages + 'TARGET_ARCH is being overwritten, likely by your MACHINE configuration files.\nPlease use a valid tune configuration file which should set this correctly automatically\nand avoid setting this in the machine configuration. See the OE-Core mailing list for more information.\n'
     
     # Check TARGET_OS is set
-    if data.getVar('TARGET_OS', e.data, True) == 'INVALID':
+    if data.getVar('TARGET_OS', sanity_data, True) == 'INVALID':
         messages = messages + 'Please set TARGET_OS directly, or choose a MACHINE or DISTRO that does so.\n'
 
     # Check that we don't have duplicate entries in PACKAGE_ARCHS & that TUNE_PKGARCH is in PACKAGE_ARCHS
-    pkgarchs = data.getVar('PACKAGE_ARCHS', e.data, True)
-    tunepkg = data.getVar('TUNE_PKGARCH', e.data, True)
+    pkgarchs = data.getVar('PACKAGE_ARCHS', sanity_data, True)
+    tunepkg = data.getVar('TUNE_PKGARCH', sanity_data, True)
     tunefound = False
     seen = {}
     dups = []
@@ -201,7 +210,7 @@ def check_sanity_validmachine(e):
     return messages
 
 
-def check_sanity(e):
+def check_sanity(sanity_data):
     from bb import note, error, data, __version__
 
     try:
@@ -211,7 +220,7 @@ def check_sanity(e):
     import commands
 
     # Check the bitbake version meets minimum requirements
-    minversion = data.getVar('BB_MIN_VERSION', e.data , True)
+    minversion = data.getVar('BB_MIN_VERSION', sanity_data , True)
     if not minversion:
         # Hack: BB_MIN_VERSION hasn't been parsed yet so return 
         # and wait for the next call
@@ -219,7 +228,7 @@ def check_sanity(e):
         return
 
     if 0 == os.getuid():
-        raise_sanity_error("Do not use Bitbake as root.")
+        raise_sanity_error("Do not use Bitbake as root.", sanity_data)
 
     messages = ""
 
@@ -233,42 +242,42 @@ def check_sanity(e):
         messages = messages + 'Bitbake version %s is required and version %s was found\n' % (minversion, __version__)
 
     # Check that the MACHINE is valid, if it is set
-    if data.getVar('MACHINE', e.data, True):
-        if not check_conf_exists("conf/machine/${MACHINE}.conf", e.data):
+    if data.getVar('MACHINE', sanity_data, True):
+        if not check_conf_exists("conf/machine/${MACHINE}.conf", sanity_data):
             messages = messages + 'Please set a valid MACHINE in your local.conf or environment\n'
         else:
-            messages = messages + check_sanity_validmachine(e)
+            messages = messages + check_sanity_validmachine(sanity_data)
     else:
         messages = messages + 'Please set a MACHINE in your local.conf or environment\n'
 
     # Check we are using a valid lacal.conf
-    current_conf  = data.getVar('CONF_VERSION', e.data, True)
-    conf_version =  data.getVar('LOCALCONF_VERSION', e.data, True)
+    current_conf  = data.getVar('CONF_VERSION', sanity_data, True)
+    conf_version =  data.getVar('LOCALCONF_VERSION', sanity_data, 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 conf/local.conf.sample\" is a good way to visualise the changes.\n"
 
     # Check bblayers.conf is valid
-    current_lconf = data.getVar('LCONF_VERSION', e.data, True)
-    lconf_version = data.getVar('LAYER_CONF_VERSION', e.data, True)
+    current_lconf = data.getVar('LCONF_VERSION', sanity_data, True)
+    lconf_version = data.getVar('LAYER_CONF_VERSION', sanity_data, True)
     if current_lconf != lconf_version:
         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 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", e.data):
-        current_sconf = data.getVar('SCONF_VERSION', e.data, True)
-        sconf_version = data.getVar('SITE_CONF_VERSION', e.data, True)
+    if check_conf_exists("conf/site.conf", sanity_data):
+        current_sconf = data.getVar('SCONF_VERSION', sanity_data, True)
+        sconf_version = data.getVar('SITE_CONF_VERSION', sanity_data, True)
         if current_sconf != sconf_version:
             messages = messages + "Your version of site.conf was generated from an older version of site.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/site.conf conf/site.conf.sample\" is a good way to visualise the changes.\n"
 
-    assume_provided = data.getVar('ASSUME_PROVIDED', e.data , True).split()
+    assume_provided = data.getVar('ASSUME_PROVIDED', sanity_data , True).split()
     # Check user doesn't have ASSUME_PROVIDED = instead of += in local.conf
     if "diffstat-native" not in assume_provided:
         messages = messages + 'Please use ASSUME_PROVIDED +=, not ASSUME_PROVIDED = in your local.conf\n'
 
     # Check that DL_DIR is set, exists and is writable. In theory, we should never even hit the check if DL_DIR isn't 
     # set, since so much relies on it being set.
-    dldir = data.getVar('DL_DIR', e.data, True)
+    dldir = data.getVar('DL_DIR', sanity_data, True)
     if not dldir:
         messages = messages + "DL_DIR is not set. Your environment is misconfigured, check that DL_DIR is set, and if the directory exists, that it is writable. \n"
     if os.path.exists(dldir) and not os.access(dldir, os.W_OK):
@@ -276,32 +285,32 @@ def check_sanity(e):
     
     # Check that the DISTRO is valid, if set
     # need to take into account DISTRO renaming DISTRO
-    distro = data.getVar('DISTRO', e.data, True)
+    distro = data.getVar('DISTRO', sanity_data, True)
     if distro:
-        if not ( check_conf_exists("conf/distro/${DISTRO}.conf", e.data) or check_conf_exists("conf/distro/include/${DISTRO}.inc", e.data) ):
-            messages = messages + "DISTRO '%s' not found. Please set a valid DISTRO in your local.conf\n" % data.getVar("DISTRO", e.data, True )
+        if not ( check_conf_exists("conf/distro/${DISTRO}.conf", sanity_data) or check_conf_exists("conf/distro/include/${DISTRO}.inc", sanity_data) ):
+            messages = messages + "DISTRO '%s' not found. Please set a valid DISTRO in your local.conf\n" % data.getVar("DISTRO", sanity_data, True )
 
     missing = ""
 
-    if not check_app_exists("${MAKE}", e.data):
+    if not check_app_exists("${MAKE}", sanity_data):
         missing = missing + "GNU make,"
 
-    if not check_app_exists('${BUILD_PREFIX}gcc', e.data):
-        missing = missing + "C Compiler (%sgcc)," % data.getVar("BUILD_PREFIX", e.data, True)
+    if not check_app_exists('${BUILD_PREFIX}gcc', sanity_data):
+        missing = missing + "C Compiler (%sgcc)," % data.getVar("BUILD_PREFIX", sanity_data, True)
 
-    if not check_app_exists('${BUILD_PREFIX}g++', e.data):
-        missing = missing + "C++ Compiler (%sg++)," % data.getVar("BUILD_PREFIX", e.data, True)
+    if not check_app_exists('${BUILD_PREFIX}g++', sanity_data):
+        missing = missing + "C++ Compiler (%sg++)," % data.getVar("BUILD_PREFIX", sanity_data, True)
 
-    required_utilities = e.data.getVar('SANITY_REQUIRED_UTILITIES', True)
+    required_utilities = sanity_data.getVar('SANITY_REQUIRED_UTILITIES', True)
 
     if "qemu-native" in assume_provided:
-        if not check_app_exists("qemu-arm", e.data):
+        if not check_app_exists("qemu-arm", sanity_data):
             messages = messages + "qemu-native was in ASSUME_PROVIDED but the QEMU binaries (qemu-arm) can't be found in PATH"
 
-    if "." in data.getVar('PATH', e.data, True).split(":"):
+    if "." in data.getVar('PATH', sanity_data, True).split(":"):
         messages = messages + "PATH contains '.' which will break the build, please remove this"
 
-    if data.getVar('TARGET_ARCH', e.data, True) == "arm":
+    if data.getVar('TARGET_ARCH', sanity_data, True) == "arm":
         # This path is no longer user-readable in modern (very recent) Linux
         try:
             if os.path.exists("/proc/sys/vm/mmap_min_addr"):
@@ -315,7 +324,7 @@ def check_sanity(e):
             pass
 
     for util in required_utilities.split():
-        if not check_app_exists( util, e.data ):
+        if not check_app_exists( util, sanity_data ):
             missing = missing + "%s," % util
 
     if missing != "":
@@ -326,10 +335,10 @@ def check_sanity(e):
     if pseudo_msg != "":
         messages = messages + pseudo_msg + '\n'
 
-    check_supported_distro(e)
+    check_supported_distro(sanity_data)
 
     # Check if DISPLAY is set if IMAGETEST is set
-    if not data.getVar( 'DISPLAY', e.data, True ) and data.getVar( 'IMAGETEST', e.data, True ) == 'qemu':
+    if not data.getVar( 'DISPLAY', sanity_data, True ) and data.getVar( 'IMAGETEST', sanity_data, True ) == 'qemu':
         messages = messages + 'qemuimagetest needs a X desktop to start qemu, please set DISPLAY correctly (e.g. DISPLAY=:1.0)\n'
 
     omask = os.umask(022)
@@ -337,11 +346,11 @@ def check_sanity(e):
         messages = messages + "Please use a umask which allows a+rx and u+rwx\n"
     os.umask(omask)
 
-    oes_bb_conf = data.getVar( 'OES_BITBAKE_CONF', e.data, True )
+    oes_bb_conf = data.getVar( 'OES_BITBAKE_CONF', sanity_data, True )
     if not oes_bb_conf:
         messages = messages + 'You do not include OpenEmbeddeds version of conf/bitbake.conf. This means your environment is misconfigured, in particular check BBPATH.\n'
 
-    nolibs = data.getVar('NO32LIBS', e.data, True)
+    nolibs = data.getVar('NO32LIBS', sanity_data, True)
     if not nolibs:
         lib32path = '/lib'
         if os.path.exists('/lib64') and ( os.path.islink('/lib64') or os.path.islink('/lib') ):
@@ -350,8 +359,8 @@ def check_sanity(e):
         if os.path.exists('%s/libc.so.6' % lib32path) and not os.path.exists('/usr/include/gnu/stubs-32.h'):
             messages = messages + "You have a 32-bit libc, but no 32-bit headers.  You must install the 32-bit libc headers.\n"
 
-    tmpdir = data.getVar('TMPDIR', e.data, True)
-    sstate_dir = data.getVar('SSTATE_DIR', e.data, True)
+    tmpdir = data.getVar('TMPDIR', sanity_data, True)
+    sstate_dir = data.getVar('SSTATE_DIR', sanity_data, True)
 
     # Check saved sanity info
     last_sanity_version = 0
@@ -368,16 +377,16 @@ def check_sanity(e):
             if line.startswith('SSTATE_DIR'):
                 last_sstate_dir = line.split()[1]
     
-    sanity_version = int(data.getVar('SANITY_VERSION', e.data, True) or 1)
+    sanity_version = int(data.getVar('SANITY_VERSION', sanity_data, True) or 1)
     if last_sanity_version < sanity_version: 
-        messages = messages + check_sanity_version_change(e.data)
-        messages = messages + check_sanity_tmpdir_change(tmpdir, e.data)
-        messages = messages + check_sanity_sstate_dir_change(sstate_dir, e.data)
+        messages = messages + check_sanity_version_change(sanity_data)
+        messages = messages + check_sanity_tmpdir_change(tmpdir, sanity_data)
+        messages = messages + check_sanity_sstate_dir_change(sstate_dir, sanity_data)
     else: 
         if last_tmpdir != tmpdir:
-            messages = messages + check_sanity_tmpdir_change(tmpdir, e.data)
+            messages = messages + check_sanity_tmpdir_change(tmpdir, sanity_data)
         if last_sstate_dir != sstate_dir:
-            messages = messages + check_sanity_sstate_dir_change(sstate_dir, e.data)
+            messages = messages + check_sanity_sstate_dir_change(sstate_dir, sanity_data)
 
     if os.path.exists("conf") and not messages:
         f = file(sanityverfile, 'w')
@@ -402,8 +411,8 @@ def check_sanity(e):
     #
     # Check the 'ABI' of TMPDIR
     #
-    current_abi = data.getVar('OELAYOUT_ABI', e.data, True)
-    abifile = data.getVar('SANITY_ABIFILE', e.data, True)
+    current_abi = data.getVar('OELAYOUT_ABI', sanity_data, True)
+    abifile = data.getVar('SANITY_ABIFILE', sanity_data, True)
     if os.path.exists(abifile):
         f = file(abifile, "r")
         abi = f.read().strip()
@@ -412,16 +421,16 @@ def check_sanity(e):
             f.write(current_abi)
         elif abi == "2" and current_abi == "3":
             bb.note("Converting staging from layout version 2 to layout version 3")
-            os.system(e.data.expand("mv ${TMPDIR}/staging ${TMPDIR}/sysroots"))
-            os.system(e.data.expand("ln -s sysroots ${TMPDIR}/staging"))
-            os.system(e.data.expand("cd ${TMPDIR}/stamps; for i in */*do_populate_staging; do new=`echo $i | sed -e 's/do_populate_staging/do_populate_sysroot/'`; mv $i $new; done"))
+            os.system(sanity_data.expand("mv ${TMPDIR}/staging ${TMPDIR}/sysroots"))
+            os.system(sanity_data.expand("ln -s sysroots ${TMPDIR}/staging"))
+            os.system(sanity_data.expand("cd ${TMPDIR}/stamps; for i in */*do_populate_staging; do new=`echo $i | sed -e 's/do_populate_staging/do_populate_sysroot/'`; mv $i $new; done"))
             f = file(abifile, "w")
             f.write(current_abi)
         elif abi == "3" and current_abi == "4":
             bb.note("Converting staging layout from version 3 to layout version 4")
-            if os.path.exists(e.data.expand("${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS}")):
-                os.system(e.data.expand("mv ${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS} ${STAGING_BINDIR_CROSS}"))
-                os.system(e.data.expand("ln -s ${STAGING_BINDIR_CROSS} ${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS}"))
+            if os.path.exists(sanity_data.expand("${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS}")):
+                os.system(sanity_data.expand("mv ${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS} ${STAGING_BINDIR_CROSS}"))
+                os.system(sanity_data.expand("ln -s ${STAGING_BINDIR_CROSS} ${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS}"))
 
             f = file(abifile, "w")
             f.write(current_abi)
@@ -429,7 +438,7 @@ def check_sanity(e):
             messages = messages + "Staging layout has changed. The cross directory has been deprecated and cross packages are now built under the native sysroot.\nThis requires a rebuild.\n"
         elif abi == "5" and current_abi == "6":
             bb.note("Converting staging layout from version 5 to layout version 6")
-            os.system(e.data.expand("mv ${TMPDIR}/pstagelogs ${SSTATE_MANIFESTS}"))
+            os.system(sanity_data.expand("mv ${TMPDIR}/pstagelogs ${SSTATE_MANIFESTS}"))
             f = file(abifile, "w")
             f.write(current_abi)
         elif abi == "7" and current_abi == "8":
@@ -442,19 +451,32 @@ def check_sanity(e):
         f.write(current_abi)
     f.close()
 
-    oeroot = data.getVar('COREBASE', e.data)
+    oeroot = data.getVar('COREBASE', sanity_data)
     if oeroot.find ('+') != -1:
         messages = messages + "Error, you have an invalid character (+) in your COREBASE directory path. Please move the installation to a directory which doesn't include a +."
     elif oeroot.find (' ') != -1:
         messages = messages + "Error, you have a space in your COREBASE directory path. Please move the installation to a directory which doesn't include a space."
 
     if messages != "":
-        raise_sanity_error(messages)
+        raise_sanity_error(messages, sanity_data)
+
+# Create a copy of the datastore and finalise it to ensure appends and 
+# overrides are set - the datastore has yet to be finalised at ConfigParsed
+def copy_data(e):
+    sanity_data = bb.data.createCopy(e.data)
+    sanity_data.finalize()
+    return sanity_data
 
 addhandler check_sanity_eventhandler
 python check_sanity_eventhandler() {
-    if bb.event.getName(e) == "ConfigParsed" and e.data.getVar("BB_WORKERCONTEXT", True) != "1":
-        check_sanity(e)
+    if bb.event.getName(e) == "ConfigParsed" and e.data.getVar("BB_WORKERCONTEXT", True) != "1" and e.data.getVar("DISABLE_SANITY_CHECKS", True) != "1":
+        sanity_data = copy_data(e)
+        check_sanity(sanity_data)
+    elif bb.event.getName(e) == "SanityCheck":
+        sanity_data = copy_data(e)
+        sanity_data.setVar("SANITY_USE_EVENTS", "1")
+        check_sanity(sanity_data)
+        bb.event.fire(bb.event.SanityCheckPassed(), e.data)
 
     return
 }

meta/classes/utils.bbclass

@@ -282,7 +282,6 @@ create_cmdline_wrapper () {
    cmd=$1
    shift
 
-   # run echo via env to test syntactic validity of the variable arguments
    echo "Generating wrapper script for $cmd"
 
    mv $cmd $cmd.real
@@ -306,8 +305,7 @@ create_wrapper () {
    cmd=$1
    shift
 
-   # run echo via env to test syntactic validity of the variable arguments
-   env $@ echo "Generating wrapper script for $cmd"
+   echo "Generating wrapper script for $cmd"
 
    mv $cmd $cmd.real
    cmdname=`basename $cmd`.real

meta/conf/bitbake.conf

@@ -340,6 +340,7 @@ STAGING_DATADIR_NATIVE = "${STAGING_DIR_NATIVE}${datadir_native}"
 STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}"
 STAGING_BINDIR = "${STAGING_DIR_HOST}${bindir}"
 STAGING_LIBDIR = "${STAGING_DIR_HOST}${libdir}"
+STAGING_BASELIBDIR = "${STAGING_DIR_HOST}${base_libdir}"
 STAGING_INCDIR = "${STAGING_DIR_HOST}${includedir}"
 STAGING_DATADIR = "${STAGING_DIR_HOST}${datadir}"
 STAGING_EXECPREFIXDIR = "${STAGING_DIR_HOST}${exec_prefix}"
@@ -558,17 +559,17 @@ XORG_MIRROR = "http://xorg.freedesktop.org/releases"
 
 FETCHCMD_svn = "/usr/bin/env svn"
 FETCHCMD_cvs = "/usr/bin/env cvs"
-FETCHCMD_wget = "/usr/bin/env wget -t 5 -nv --no-check-certificate"
+FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 -nv --no-check-certificate"
 FETCHCMD_bzr = "/usr/bin/env bzr"
 FETCHCMD_hg = "/usr/bin/env hg"
 
 FETCHCOMMAND = "ERROR, this must be a BitBake bug"
-FETCHCOMMAND_wget = "/usr/bin/env wget -t 5 -nv --passive-ftp --no-check-certificate -P ${DL_DIR} '${URI}'"
+FETCHCOMMAND_wget = "/usr/bin/env wget  -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P ${DL_DIR} '${URI}'"
 FETCHCOMMAND_cvs = "/usr/bin/env cvs '-d${CVSROOT}' co ${CVSCOOPTS} ${CVSMODULE}"
 FETCHCOMMAND_svn = "/usr/bin/env svn co ${SVNCOOPTS} ${SVNROOT} ${SVNMODULE}"
-CHECKCOMMAND_wget = "/usr/bin/env wget --spider -t 5 --passive-ftp --no-check-certificate -P ${DL_DIR} '${URI}'"
+CHECKCOMMAND_wget = "/usr/bin/env wget --spider  -t 2 -T 30 --passive-ftp --no-check-certificate -P ${DL_DIR} '${URI}'"
 RESUMECOMMAND = "ERROR, this must be a BitBake bug"
-RESUMECOMMAND_wget = "/usr/bin/env wget -c -t 5 -nv --passive-ftp --no-check-certificate -P ${DL_DIR} '${URI}'"
+RESUMECOMMAND_wget = "/usr/bin/env wget -c -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P ${DL_DIR} '${URI}'"
 UPDATECOMMAND = "ERROR, this must be a BitBake bug"
 UPDATECOMMAND_cvs = "/usr/bin/env cvs -d${CVSROOT} update -d -P ${CVSCOOPTS}"
 UPDATECOMMAND_svn = "/usr/bin/env svn update ${SVNCOOPTS}"

meta/recipes-connectivity/connman/connman/0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch

@@ -0,0 +1,35 @@
+From 4ddaf78dad5a9ee4a0658235f71b75132192123e Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Sat, 7 Apr 2012 18:52:12 -0700
+Subject: [PATCH] plugin.h: Change visibility to default for debug symbols
+
+gold refuses to link in undefined weak symbols which
+have hidden visibility
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+
+
+Upstream-Status: Pending
+---
+ include/plugin.h |    4 ++--
+ 1 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/include/plugin.h b/include/plugin.h
+index 692a4e5..a9361c3 100644
+--- a/include/plugin.h
++++ b/include/plugin.h
+@@ -89,9 +89,9 @@ struct connman_plugin_desc {
+ #else
+ #define CONNMAN_PLUGIN_DEFINE(name, description, version, priority, init, exit) \
+ 		extern struct connman_debug_desc __start___debug[] \
+-				__attribute__ ((weak, visibility("hidden"))); \
++				__attribute__ ((weak, visibility("default"))); \
+ 		extern struct connman_debug_desc __stop___debug[] \
+-				__attribute__ ((weak, visibility("hidden"))); \
++				__attribute__ ((weak, visibility("default"))); \
+ 		extern struct connman_plugin_desc connman_plugin_desc \
+ 				__attribute__ ((visibility("default"))); \
+ 		struct connman_plugin_desc connman_plugin_desc = { \
+-- 
+1.7.5.4
+

meta/recipes-connectivity/connman/connman/test-set-ipv4-method-api-fix.patch

@@ -0,0 +1,50 @@
+From 0b817dd3096f5c3ca8f0b868ee55ea550054137b Mon Sep 17 00:00:00 2001
+From: Daniel Wagner <daniel.wagner@bmw-carit.de>
+Date: Mon, 19 Mar 2012 14:03:27 +0100
+Subject: [PATCH 3/3] set-ipv4-method: The arguments have to be wrapped into a
+ variant
+
+Fixes BMC#24986
+
+Upstream-Status: Backport
+
+Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
+---
+ test/set-ipv4-method |   11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/test/set-ipv4-method b/test/set-ipv4-method
+index 820b24b..235113f 100755
+--- a/test/set-ipv4-method
++++ b/test/set-ipv4-method
+@@ -3,6 +3,9 @@
+ import sys
+ import dbus
+ 
++def make_variant(string):
++	return dbus.String(string, variant_level=1)
++
+ def print_usage():
+ 	print "Usage: %s <service> [off|dhcp|manual <address> [netmask] [gateway]]" % (sys.argv[0])
+ 
+@@ -20,13 +23,13 @@ properties = service.GetProperties()
+ 
+ print "Setting method %s for %s" % (sys.argv[2], sys.argv[1])
+ 
+-ipv4_configuration = { "Method": sys.argv[2] }
++ipv4_configuration = { "Method": make_variant(sys.argv[2]) }
+ if (len(sys.argv) > 3):
+-	ipv4_configuration["Address"] = sys.argv[3]
++	ipv4_configuration["Address"] = make_variant(sys.argv[3])
+ if (len(sys.argv) > 4):
+-	ipv4_configuration["Netmask"] = sys.argv[4]
++	ipv4_configuration["Netmask"] = make_variant(sys.argv[4])
+ if (len(sys.argv) > 5):
+-        ipv4_configuration["Gateway"] = sys.argv[5]
++        ipv4_configuration["Gateway"] = make_variant(sys.argv[5])
+ 
+ service.SetProperty("IPv4.Configuration", ipv4_configuration)
+ print "New IPv4.Configuration: ", ipv4_configuration
+-- 
+1.7.9.5
+

meta/recipes-connectivity/connman/connman/test-set-ipv6-method-api-fix.patch

@@ -0,0 +1,55 @@
+From 2885e71c9c0df7ea9866e91ab79d255eaa8de53d Mon Sep 17 00:00:00 2001
+From: Daniel Wagner <daniel.wagner@bmw-carit.de>
+Date: Mon, 19 Mar 2012 14:03:28 +0100
+Subject: [PATCH 2/3] set-ipv6-method: The arguments have to be wrapped into a
+ variant
+
+Fixes BMC#24986
+
+Upstream-Status: Backport
+
+Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
+---
+ test/set-ipv6-method |   13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+diff --git a/test/set-ipv6-method b/test/set-ipv6-method
+index 7f60b88..4f2de09 100755
+--- a/test/set-ipv6-method
++++ b/test/set-ipv6-method
+@@ -3,6 +3,9 @@
+ import sys
+ import dbus
+ 
++def make_variant(string):
++	return dbus.String(string, variant_level=1)
++
+ def print_usage():
+ 	print "Usage: %s <service> off|manual|auto [<address> [prefixlen] [gateway]] [<privacy>]" % (sys.argv[0])
+ 
+@@ -19,17 +22,17 @@ properties = service.GetProperties()
+ 
+ print "Setting method %s for %s" % (sys.argv[2], sys.argv[1])
+ 
+-ipv6_configuration = { "Method": sys.argv[2] }
++ipv6_configuration = { "Method": make_variant(sys.argv[2])}
+ if sys.argv[2] == "auto":
+ 	if (len(sys.argv) > 3):
+-		ipv6_configuration["Privacy"] = sys.argv[3]
++		ipv6_configuration["Privacy"] = make_variant(sys.argv[3])
+ else:
+ 	if (len(sys.argv) > 3):
+-		ipv6_configuration["Address"] = sys.argv[3]
++		ipv6_configuration["Address"] = make_variant(sys.argv[3])
+ 	if (len(sys.argv) > 4):
+-		ipv6_configuration["PrefixLength"] = sys.argv[4]
++		ipv6_configuration["PrefixLength"] = make_variant(sys.argv[4])
+ 	if (len(sys.argv) > 5):
+-		ipv6_configuration["Gateway"] = sys.argv[5]
++		ipv6_configuration["Gateway"] = make_variant(sys.argv[5])
+ 
+ service.SetProperty("IPv6.Configuration", ipv6_configuration)
+ print "New IPv6.Configuration: ", ipv6_configuration
+-- 
+1.7.9.5
+

meta/recipes-connectivity/connman/connman_0.79.bb

@@ -6,6 +6,9 @@ SRC_URI  = "git://git.kernel.org/pub/scm/network/connman/connman.git \
             file://add_xuser_dbus_permission.patch \
             file://ethernet_default.patch \
             file://disable_alg-test.patch \
+            file://0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch \
+            file://test-set-ipv4-method-api-fix.patch \
+            file://test-set-ipv6-method-api-fix.patch \
             file://connman"
 S = "${WORKDIR}/git"
-PR = "r1"
+PR = "r3"

meta/recipes-connectivity/openssl/openssl-1.0.0i/configure-targets.patch

@@ -3,11 +3,11 @@ Upstream-Status: Inappropriate [embedded specific]
 The number of colons are important :)
 
 
-Index: openssl-1.0.0a/Configure
+Index: openssl-1.0.0h/Configure
 ===================================================================
---- openssl-1.0.0a.orig/Configure
-+++ openssl-1.0.0a/Configure
-@@ -380,6 +380,22 @@ my %table=(
+--- openssl-1.0.0h.orig/Configure	2012-04-23 09:16:09.521511921 -0700
++++ openssl-1.0.0h/Configure	2012-04-23 09:17:41.829516389 -0700
+@@ -380,6 +380,22 @@
  "linux-alpha-ccc","ccc:-fast -readonly_strings -DL_ENDIAN -DTERMIO::-D_REENTRANT:::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL:${alpha_asm}",
  "linux-alpha+bwx-ccc","ccc:-fast -readonly_strings -DL_ENDIAN -DTERMIO::-D_REENTRANT:::SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL:${alpha_asm}",
  
@@ -22,10 +22,10 @@ Index: openssl-1.0.0a/Configure
 +"linux-avr32","$ENV{'CC'}:-DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:BN_LLONG DES_RISC1:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).",
 +
 +#### Linux on MIPS/MIPS64
-+"linux-mips","$ENV{'CC'}:-DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:BN_LLONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL DES_RISC2::::::::::::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"linux-mips64","$ENV{'CC'}:-DB_ENDIAN -DTERMIO -mabi=64 -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL DES_RISC2::::::::::::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"linux-mips64el","$ENV{'CC'}:-DL_ENDIAN -DTERMIO -mabi=64 -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL DES_RISC2::::::::::::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"linux-mipsel","$ENV{'CC'}:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:BN_LLONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL DES_RISC2::::::::::::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"linux-mips","$ENV{'CC'}:-DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:BN_LLONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL DES_RISC2:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"linux-mips64","$ENV{'CC'}:-DB_ENDIAN -DTERMIO -mabi=64 -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL DES_RISC2:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"linux-mips64el","$ENV{'CC'}:-DL_ENDIAN -DTERMIO -mabi=64 -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL DES_RISC2:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"linux-mipsel","$ENV{'CC'}:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:BN_LLONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL DES_RISC2:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +
  #### *BSD [do see comment about ${BSDthreads} above!]
  "BSD-generic32","gcc:-DTERMIOS -O3 -fomit-frame-pointer -Wall::${BSDthreads}:::BN_LLONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL:${no_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",

meta/recipes-connectivity/openssl/openssl.inc

@@ -4,8 +4,7 @@ HOMEPAGE = "http://www.openssl.org/"
 BUGTRACKER = "http://www.openssl.org/news/vulnerabilities.html"
 SECTION = "libs/network"
 
-# Big Jump for OpenSSL 1.0 support with meta-oe
-INC_PR = "r15"
+INC_PR = "r0"
 
 # "openssl | SSLeay" dual license
 LICENSE = "openssl"

meta/recipes-connectivity/openssl/openssl_1.0.0i.bb

@@ -6,7 +6,7 @@ DEPENDS += "ocf-linux"
 
 CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS"
 
-PR = "${INC_PR}.1"
+PR = "${INC_PR}.2"
 
 LIC_FILES_CHKSUM = "file://LICENSE;md5=f9a8f968107345e0b75aa8c2ecaa7ec8"
 
@@ -31,8 +31,8 @@ SRC_URI += "file://configure-targets.patch \
             file://openssl_fix_for_x32.patch \
            "
 
-SRC_URI[md5sum] = "a5bc483c570f2ac3758ce5c19b667fab"
-SRC_URI[sha256sum] = "7e3dfc21aa57ed33ea673170053d1921322803b8a6a624a4f0d2e4c308bd418d"
+SRC_URI[md5sum] = "b4df9c11af454fd68178c85a1d5f328f"
+SRC_URI[sha256sum] = "548262d15777c504be1ab9bb8fabef1e14a3de54837a6593c8f403dd843d5e57"
 
 PACKAGES =+ " \
 	${PN}-engines \

meta/recipes-core/eglibc/eglibc-package.inc

@@ -20,11 +20,12 @@ USE_LDCONFIG ?= "1"
 PKGSUFFIX = ""
 PKGSUFFIX_virtclass-nativesdk = "-nativesdk"
 
-PACKAGES = "${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX} nscd${PKGSUFFIX} ldd${PKGSUFFIX} ${PN}-utils eglibc-extra-nss${PKGSUFFIX} eglibc-thread-db${PKGSUFFIX} ${PN}-pic ${PN}-dev ${PN}-staticdev ${PN}-doc libcidn${PKGSUFFIX} libmemusage${PKGSUFFIX} libsegfault${PKGSUFFIX} ${PN}-pcprofile libsotruss${PKGSUFFIX}"
+PACKAGES = "${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX} nscd${PKGSUFFIX} ldd${PKGSUFFIX} ${PN}-mtrace ${PN}-utils eglibc-extra-nss${PKGSUFFIX} eglibc-thread-db${PKGSUFFIX} ${PN}-pic ${PN}-dev ${PN}-staticdev ${PN}-doc libcidn${PKGSUFFIX} libmemusage${PKGSUFFIX} libsegfault${PKGSUFFIX} ${PN}-pcprofile libsotruss${PKGSUFFIX}"
 
 # The ld.so in this eglibc supports the GNU_HASH
 RPROVIDES_${PN} = "glibc${PKGSUFFIX} rtld(GNU_HASH)"
 RPROVIDES_${PN}-utils = "glibc${PKGSUFFIX}-utils"
+RPROVIDES_${PN}-mtrace = "glibc${PKGSUFFIX}-mtrace libc-mtrace"
 RPROVIDES_${PN}-pic = "glibc${PKGSUFFIX}-pic"
 RPROVIDES_${PN}-dev = "glibc${PKGSUFFIX}-dev"
 RPROVIDES_${PN}-staticdev = "glibc${PKGSUFFIX}-staticdev"
@@ -48,11 +49,13 @@ FILES_${PN}-dev_append += "${bindir}/rpcgen ${libdir}/*_nonshared.a \
 	${base_libdir}/*_nonshared.a ${base_libdir}/*.o ${datadir}/aclocal"
 FILES_${PN}-staticdev_append += "${libdir}/*.a ${base_libdir}/*.a"
 FILES_nscd${PKGSUFFIX} = "${sbindir}/nscd*"
+FILES_${PN}-mtrace = "${bindir}/mtrace"
 FILES_${PN}-utils = "${bindir}/* ${sbindir}/*"
 FILES_${PN}-dbg += "${libexecdir}/*/.debug ${libdir}/audit/.debug"
 FILES_catchsegv${PKGSUFFIX} = "${bindir}/catchsegv"
 RDEPENDS_catchsegv${PKGSUFFIX} = "libsegfault"
 RDEPENDS_${PN}-utils += "bash"
+RDEPENDS_${PN}-mtrace += "perl"
 FILES_${PN}-pcprofile = "${base_libdir}/libpcprofile.so"
 FILES_eglibc-thread-db${PKGSUFFIX} = "${base_libdir}/libthread_db.so.* ${base_libdir}/libthread_db-*.so"
 RPROVIDES_${PN}-dev += "libc-dev"
@@ -68,6 +71,8 @@ SUMMARY_ldd = "print shared library dependencies"
 DESCRIPTION_ldd = "/usr/bin/ldd prints shared library dependencies for each program or shared library specified on the command line."
 SUMMARY_${PN}-utils = "Miscellaneous utilities provided by eglibc"
 DESCRIPTION_${PN}-utils = "Miscellaneous utilities including getconf, iconf, locale, gencat, tzselect, zic, rpcinfo, ..."
+SUMMARY_${PN}-mtrace = "mtrace utility provided by eglibc"
+DESCRIPTION_${PN}-mtrace = "mtrace utility provided by eglibc"
 DESCRIPTION_libsotruss = "Library to support sotruss which traces calls through PLTs"
 
 inherit libc-common multilib_header

meta/recipes-core/eglibc/eglibc.inc

@@ -32,6 +32,8 @@ require eglibc-options.inc
 
 LEAD_SONAME = "libc.so"
 
+CACHED_CONFIGUREVARS += "ac_cv_path_KSH=${base_bindir}/bash \
+                       ac_cv_path_BASH_SHELL=${base_bindir}/bash"
 GLIBC_EXTRA_OECONF ?= ""
 GLIBC_EXTRA_OECONF_virtclass-nativesdk = ""
 INHIBIT_DEFAULT_DEPS = "1"

meta/recipes-core/eglibc/eglibc_2.13.bb

@@ -3,7 +3,7 @@ require eglibc.inc
 SRCREV = "15508"
 
 DEPENDS += "gperf-native"
-PR = "r26"
+PR = "r28"
 PR_append = "+svnr${SRCPV}"
 
 EGLIBC_BRANCH="eglibc-2_13"

meta/recipes-core/eglibc/eglibc_2.15.bb

@@ -3,7 +3,7 @@ require eglibc.inc
 SRCREV = "17386"
 
 DEPENDS += "gperf-native"
-PR = "r6"
+PR = "r7"
 PR_append = "+svnr${SRCPV}"
 
 EGLIBC_BRANCH="eglibc-2_15"

meta/recipes-core/images/self-hosted-image.bb

@@ -5,7 +5,7 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
                     file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 
-PR = "r12"
+PR = "r15"
 
 IMAGE_FEATURES += "x11-mini package-management"
 
@@ -19,7 +19,7 @@ IMAGE_FSTYPES = "vmdk"
 
 inherit core-image
 
-SRCREV = "20ff9db92165e6d16897671d2b1d370661962712"
+SRCREV = "3ab5d73f0c49df9fefa2a46031d33436bbd7d7d8"
 SRC_URI = "git://git.yoctoproject.org/poky;protocol=git"
 
 IMAGE_CMD_ext3_append () {

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

@@ -16,7 +16,7 @@ swap_ratio=5
 found="no"
 
 echo "Searching for a hard drive..."
-for device in 'hda' 'hdb' 'sda' 'sdb'
+for device in 'hda' 'hdb' 'sda' 'sdb' 'mmcblk0' 'mmcblk1'
   do
   if [ -e /sys/block/${device}/removable ]; then
       if [ "$(cat /sys/block/${device}/removable)" = "0" ]; then
@@ -62,13 +62,7 @@ rm -f /etc/udev/scripts/mount*
 #
 # Unmount anything the automounter had mounted
 #
-umount /dev/${device} 2> /dev/null || /bin/true
-umount /dev/${device}1 2> /dev/null || /bin/true
-umount /dev/${device}2 2> /dev/null || /bin/true
-umount /dev/${device}3 2> /dev/null || /bin/true
-umount /dev/${device}4 2> /dev/null || /bin/true
-umount /dev/${device}5 2> /dev/null || /bin/true
-umount /dev/${device}6 2> /dev/null || /bin/true
+umount /dev/${device}* 2> /dev/null || /bin/true
 
 if [ ! -b /dev/sda ] ; then
     mknod /dev/sda b 8 0
@@ -94,14 +88,23 @@ rootfs_start=$((boot_size + 1))
 rootfs_end=$((rootfs_start+rootfs_size))
 swap_start=$((rootfs_end+1))
 
-bootfs=/dev/${device}1
-rootfs=/dev/${device}2
-swap=/dev/${device}3
+# MMC devices are special in a couple of ways
+# 1) they use a partition prefix character 'p'
+# 2) they are detected asynchronously (need rootwait)
+rootwait=""
+part_prefix=""
+if [ ! "${device#mmcblk}" = "${device}" ]; then
+	part_prefix="p"
+	rootwait="rootwait"
+fi
+bootfs=/dev/${device}${part_prefix}1
+rootfs=/dev/${device}${part_prefix}2
+swap=/dev/${device}${part_prefix}3
 
 echo "*****************"
-echo "Boot partition size:   $boot_size MB (/dev/${device}1)"
-echo "Rootfs partition size: $rootfs_size MB (/dev/${device}2)"
-echo "Swap partition size:   $swap_size MB (/dev/${device}3)"
+echo "Boot partition size:   $boot_size MB ($bootfs)"
+echo "Rootfs partition size: $rootfs_size MB ($rootfs)"
+echo "Swap partition size:   $swap_size MB ($swap)"
 echo "*****************"
 echo "Deleting partition table on /dev/${device} ..."
 dd if=/dev/zero of=/dev/${device} bs=512 count=2
@@ -109,24 +112,24 @@ dd if=/dev/zero of=/dev/${device} bs=512 count=2
 echo "Creating new partition table on /dev/${device} ..."
 parted /dev/${device} mklabel msdos
 
-echo "Creating boot partition on /dev/${device}1"
+echo "Creating boot partition on $bootfs"
 parted /dev/${device} mkpart primary 1 $boot_size
 
-echo "Creating rootfs partition on /dev/${device}2"
+echo "Creating rootfs partition on $rootfs"
 parted /dev/${device} mkpart primary $rootfs_start $rootfs_end
 
-echo "Creating swap partition on /dev/${device}3"
+echo "Creating swap partition on $swap"
 parted /dev/${device} mkpart primary $swap_start $disk_size
 
 parted /dev/${device} print
 
-echo "Formatting /dev/${device}1 to ext2..."
+echo "Formatting $bootfs to ext2..."
 mkfs.ext3 $bootfs
 
-echo "Formatting /dev/${device}2 to ext3..."
+echo "Formatting $rootfs to ext3..."
 mkfs.ext3 $rootfs
 
-echo "Formatting swap partition...(/dev/${device}3)"
+echo "Formatting swap partition...($swap)"
 mkswap $swap
 
 mkdir /ssd
@@ -150,7 +153,7 @@ fi
 
 if [ -f /ssd/etc/grub.d/40_custom ] ; then
     echo "Preparing custom grub2 menu..."
-    sed -i "s@__ROOTFS__@$rootfs@g" /ssd/etc/grub.d/40_custom
+    sed -i "s@__ROOTFS__@$rootfs $rootwait@g" /ssd/etc/grub.d/40_custom
     sed -i "s/__VIDEO_MODE__/$3/g" /ssd/etc/grub.d/40_custom
     sed -i "s/__VGA_MODE__/$4/g" /ssd/etc/grub.d/40_custom
     mount $bootfs /bootmnt

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

@@ -5,12 +5,13 @@ RDEPENDS = "udev"
 DEPENDS = "virtual/kernel"
 SRC_URI = "file://init-live.sh"
 
-PR = "r9"
+PR = "r10"
 
 do_compile() {
-	if grep -q "CONFIG_UNION_FS=y" ${STAGING_KERNEL_DIR}/.config; then
-		sed -i 's/UNIONFS="no"/UNIONFS="yes"/g' ${WORKDIR}/init-live.sh
-	fi
+	#if grep -q "CONFIG_UNION_FS=y" ${STAGING_KERNEL_DIR}/.config; then
+	#	sed -i 's/UNIONFS="no"/UNIONFS="yes"/g' ${WORKDIR}/init-live.sh
+	#fi
+	:
 }
  
 do_install() {

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 = "r6"
+PR = "r7"
 
 RDEPENDS_${PN} = "grub parted e2fsprogs-mke2fs"
 

meta/recipes-core/ncurses/ncurses.inc

@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = "file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc
 SECTION = "libs"
 DEPENDS = "ncurses-native"
 DEPENDS_virtclass-native = ""
-INC_PR = "r8"
+INC_PR = "r9"
 
 inherit autotools binconfig multilib_header
 
@@ -107,10 +107,15 @@ do_test() {
         diff curses-narrowc.h curses-widec.h
 }
 
+# Split original _install_opts to two parts.
+# One is the options to install contents, the other is the parameters \
+# when running command "make install"
 _install_opts = "\
+  install.libs install.includes install.man \
+"
+_install_cfgs = "\
   DESTDIR='${D}' \
   PKG_CONFIG_LIBDIR='${libdir}/pkgconfig' \
-  install.libs install.includes install.man \
 "
 
 python do_install () {
@@ -122,11 +127,19 @@ shell_do_install() {
         # Order of installation is important; widec installs a 'curses.h'
         # header with more definitions and must be installed last hence.
         # Compatibility of these headers will be checked in 'do_test()'.
-        oe_runmake -C narrowc ${_install_opts} \
-                install.data install.progs
+        oe_runmake -C narrowc ${_install_cfgs} ${_install_opts} \
+                install.progs
+
+        # The install.data should run after install.libs, otherwise
+        # there would be a race issue in a very critical conditon, since
+        # tic will be run by install.data, and tic needs libtinfo.so
+        # which would be regenerated by install.libs.
+        oe_runmake -C narrowc ${_install_cfgs} \
+                install.data
+
 
         ! ${ENABLE_WIDEC} || \
-            oe_runmake -C widec ${_install_opts}
+            oe_runmake -C widec ${_install_cfgs} ${_install_opts}
 
         cd narrowc
 

meta/recipes-core/tasks/task-core-tools-debug.bb

@@ -17,10 +17,14 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 ALLOW_EMPTY = "1"
 
+MTRACE = ""
+MTRACE_libc-glibc = "libc-mtrace"
+
 RDEPENDS_${PN} = "\
     gdb \
     gdbserver \
     tcf-agent \
     rsync \
     strace \
+    ${MTRACE} \
     "

meta/recipes-core/uclibc/uclibc.inc

@@ -13,7 +13,7 @@ SECTION = "libs"
 LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=a6f89e2100d9b6cdffcea4f398e37343 \
 		    file://COPYING.LIB.boilerplate;md5=aaddeadcddeb918297e0e4afc52ce46f \
 file://${S}/test/regex/testregex.c;startline=1;endline=31;md5=234efb227d0a40677f895e4a1e26e960"
-INC_PR = "r6"
+INC_PR = "r7"
 
 require uclibc-config.inc
 STAGINGCC = "gcc-cross-intermediate"
@@ -48,9 +48,9 @@ RDEPENDS_${PN}-dev = "linux-libc-headers-dev"
 
 INHIBIT_DEFAULT_DEPS = "1"
 
-PACKAGES =+ "ldd uclibc-utils-dbg uclibc-utils uclibc-gconv uclibc-thread-db uclibc-argp uclibc-backtrace"
-PACKAGES =+ "uclibc-libcrypt uclibc-libintl uclibc-libnsl uclibc-libresolv uclibc-libm"
-PACKAGES =+ "uclibc-libdl uclibc-libutil uclibc-libpthread uclibc-librt"
+# Ensure the uclibc-dev package is processed before uclibc-staticdev to allow
+# *_nonshared.a libraries to be packaged in the uclibc-dev package.
+PACKAGES = "${PN}-dbg ${PN}-dev ${PN}-staticdev ${PN} ${PN}-doc ldd uclibc-utils-dbg uclibc-utils uclibc-gconv uclibc-thread-db uclibc-argp uclibc-backtrace uclibc-libcrypt uclibc-libintl uclibc-libnsl uclibc-libresolv uclibc-libm uclibc-libdl uclibc-libutil uclibc-libpthread uclibc-librt"
 
 FILES_uclibc-libcrypt = "${base_libdir}/libcrypt*.so.* ${base_libdir}/libcrypt-*.so"
 FILES_uclibc-libintl = "${base_libdir}/libintl*.so.* ${base_libdir}/libintl-*.so"
@@ -88,7 +88,8 @@ RPROVIDES_${PN}-dev += "libc-dev virtual-libc-dev"
 # uclibc does not really have libsegfault but then using the one from glibc is also not
 # going to work. So we pretend that we have it to make bitbake not pull other recipes
 # to satisfy this dependency for the images/tasks
-RPROVIDES_uclibc += "libsegfault"
+
+RPROVIDES_uclibc += "libsegfault rtld(GNU_HASH)"
 
 SRC_URI = "\
         http://www.uclibc.org/downloads/uClibc-${PV}.tar.bz2;name=uClibc-${PV} \

meta/recipes-devtools/binutils/binutils.inc

@@ -32,6 +32,7 @@ FILES_${PN}-symlinks = " \
 	${bindir}/addr2line \
 	${bindir}/as \
 	${bindir}/c++filt \
+	${bindir}/embedspu \
 	${bindir}/gprof \
 	${bindir}/ld \
 	${bindir}/ld.bfd \

meta/recipes-devtools/dpkg/dpkg/dpkg-deb-avoid-fflush.patch

@@ -0,0 +1,198 @@
+From 78eaf928d30d0b16e05d8d63c55a3632a135ed9a Mon Sep 17 00:00:00 2001
+From: Guillem Jover <guillem@debian.org>
+Date: Thu, 4 Nov 2010 00:51:13 +0100
+Subject: [PATCH] dpkg-deb: Use fd instead of stream based buffered I/O
+
+Behaviour of fflush() on input streams is undefined per POSIX, avoid
+mixing stream and file descriptor based I/O, and only use the latter
+instead.
+
+Upstream-Status: Backport of revision 2d420ee1d05033d237462a0075facfe406b08043 (in 1.16.x)
+
+---
+ dpkg-deb/extract.c |   83 ++++++++++++++++++++++++++++++++++++++-------------
+ 1 files changed, 62 insertions(+), 21 deletions(-)
+
+diff --git a/dpkg-deb/extract.c b/dpkg-deb/extract.c
+index 22aea98..0f5ac88 100644
+--- a/dpkg-deb/extract.c
++++ b/dpkg-deb/extract.c
+@@ -31,6 +31,7 @@
+ #include <ctype.h>
+ #include <string.h>
+ #include <dirent.h>
++#include <fcntl.h>
+ #include <unistd.h>
+ #include <ar.h>
+ #include <stdbool.h>
+@@ -61,13 +62,41 @@ static void movecontrolfiles(const char *thing) {
+ }
+ 
+ static void DPKG_ATTR_NORET
+-readfail(FILE *a, const char *filename, const char *what)
++read_fail(int rc, const char *filename, const char *what)
+ {
+-  if (ferror(a)) {
+-    ohshite(_("error reading %s from file %.255s"), what, filename);
+-  } else {
++  if (rc == 0)
+     ohshit(_("unexpected end of file in %s in %.255s"),what,filename);
++  else
++    ohshite(_("error reading %s from file %.255s"), what, filename);
++}
++
++static ssize_t
++read_line(int fd, char *buf, size_t min_size, size_t max_size)
++{
++  ssize_t line_size = 0;
++  size_t n = min_size;
++
++  while (line_size < (ssize_t)max_size) {
++    ssize_t r;
++    char *nl;
++
++    r = read(fd, buf + line_size, n);
++    if (r <= 0)
++      return r;
++
++    nl = strchr(buf + line_size, '\n');
++    line_size += r;
++
++    if (nl != NULL) {
++      nl[1] = '\0';
++      return line_size;
++    }
++
++    n = 1;
+   }
++
++  buf[line_size] = '\0';
++  return line_size;
+ }
+ 
+ static size_t
+@@ -115,19 +144,26 @@ void extracthalf(const char *debar, const char *directory,
+   char versionbuf[40];
+   float versionnum;
+   size_t ctrllennum, memberlen= 0;
++  ssize_t r;
+   int dummy;
+   pid_t c1=0,c2,c3;
+   int p1[2], p2[2];
+-  FILE *ar;
++  int arfd;
+   struct stat stab;
+   char nlc;
+   int adminmember;
+   bool oldformat, header_done;
+   struct compressor *decompressor = &compressor_gzip;
+   
+-  ar= fopen(debar,"r"); if (!ar) ohshite(_("failed to read archive `%.255s'"),debar);
+-  if (fstat(fileno(ar),&stab)) ohshite(_("failed to fstat archive"));
+-  if (!fgets(versionbuf,sizeof(versionbuf),ar)) readfail(ar,debar,_("version number"));
++  arfd = open(debar, O_RDONLY);
++  if (arfd < 0)
++    ohshite(_("failed to read archive `%.255s'"), debar);
++  if (fstat(arfd, &stab))
++    ohshite(_("failed to fstat archive"));
++
++  r = read_line(arfd, versionbuf, strlen(DPKG_AR_MAGIC), sizeof(versionbuf));
++  if (r < 0)
++    read_fail(r, debar, _("archive magic version number"));
+ 
+   if (!strcmp(versionbuf, DPKG_AR_MAGIC)) {
+     oldformat = false;
+@@ -137,8 +173,9 @@ void extracthalf(const char *debar, const char *directory,
+     for (;;) {
+       struct ar_hdr arh;
+ 
+-      if (fread(&arh,1,sizeof(arh),ar) != sizeof(arh))
+-        readfail(ar,debar,_("between members"));
++      r = read(arfd, &arh, sizeof(arh));
++      if (r != sizeof(arh))
++        read_fail(r, debar, _("archive member header"));
+ 
+       dpkg_ar_normalize_name(&arh);
+ 
+@@ -153,8 +190,9 @@ void extracthalf(const char *debar, const char *directory,
+         if (strncmp(arh.ar_name, DEBMAGIC, sizeof(arh.ar_name)) != 0)
+           ohshit(_("file `%.250s' is not a debian binary archive (try dpkg-split?)"),debar);
+         infobuf= m_malloc(memberlen+1);
+-        if (fread(infobuf,1, memberlen + (memberlen&1), ar) != memberlen + (memberlen&1))
+-          readfail(ar,debar,_("header info member"));
++        r = read(arfd, infobuf, memberlen + (memberlen & 1));
++        if ((size_t)r != (memberlen + (memberlen & 1)))
++          read_fail(r, debar, _("archive information header member"));
+         infobuf[memberlen] = '\0';
+         cur= strchr(infobuf,'\n');
+         if (!cur) ohshit(_("archive has no newlines in header"));
+@@ -174,7 +212,8 @@ void extracthalf(const char *debar, const char *directory,
+           /* Members with `_' are noncritical, and if we don't understand them
+            * we skip them.
+            */
+-	stream_null_copy(ar, memberlen + (memberlen&1),_("skipped member data from %s"), debar);
++        fd_null_copy(arfd, memberlen + (memberlen & 1),
++                     _("skipped archive member data from %s"), debar);
+       } else {
+ 	if (strncmp(arh.ar_name, ADMINMEMBER, sizeof(arh.ar_name)) == 0)
+ 	  adminmember = 1;
+@@ -198,7 +237,8 @@ void extracthalf(const char *debar, const char *directory,
+           ctrllennum= memberlen;
+         }
+         if (!adminmember != !admininfo) {
+-	  stream_null_copy(ar, memberlen + (memberlen&1),_("skipped member data from %s"), debar);
++          fd_null_copy(arfd, memberlen + (memberlen & 1),
++                       _("skipped archive member data from %s"), debar);
+         } else {
+           break; /* Yes ! - found it. */
+         }
+@@ -221,8 +261,10 @@ void extracthalf(const char *debar, const char *directory,
+     l = strlen(versionbuf);
+     if (l && versionbuf[l - 1] == '\n')
+       versionbuf[l - 1] = '\0';
+-    if (!fgets(ctrllenbuf,sizeof(ctrllenbuf),ar))
+-      readfail(ar, debar, _("control information length"));
++
++    r = read_line(arfd, ctrllenbuf, 1, sizeof(ctrllenbuf));
++    if (r < 0)
++      read_fail(r, debar, _("archive control member size"));
+     if (sscanf(ctrllenbuf,"%zi%c%d",&ctrllennum,&nlc,&dummy) !=2 || nlc != '\n')
+       ohshit(_("archive has malformatted control length `%s'"), ctrllenbuf);
+ 
+@@ -230,7 +272,8 @@ void extracthalf(const char *debar, const char *directory,
+       memberlen = ctrllennum;
+     } else {
+       memberlen = stab.st_size - ctrllennum - strlen(ctrllenbuf) - l;
+-      stream_null_copy(ar, ctrllennum, _("skipped control area from %s"), debar);
++      fd_null_copy(arfd, ctrllennum,
++                   _("skipped archive control member data from %s"), debar);
+     }
+ 
+     if (admininfo >= 2) {
+@@ -252,13 +295,11 @@ void extracthalf(const char *debar, const char *directory,
+ 
+   }
+ 
+-  safe_fflush(ar);
+-
+   m_pipe(p1);
+   c1 = subproc_fork();
+   if (!c1) {
+     close(p1[0]);
+-    stream_fd_copy(ar, p1[1], memberlen, _("failed to write to pipe in copy"));
++    fd_fd_copy(arfd, p1[1], memberlen, _("failed to write to pipe in copy"));
+     if (close(p1[1]))
+       ohshite(_("failed to close pipe in copy"));
+     exit(0);
+@@ -275,7 +316,7 @@ void extracthalf(const char *debar, const char *directory,
+     decompress_filter(decompressor, 0, 1, _("data"));
+   }
+   close(p1[0]);
+-  fclose(ar);
++  close(arfd);
+   if (taroption) close(p2[1]);
+ 
+   if (taroption && directory) {
+-- 
+1.7.7.6
+

meta/recipes-devtools/dpkg/dpkg_1.15.8.7.bb

@@ -5,10 +5,11 @@ SRC_URI += "file://noman.patch \
             file://check_snprintf.patch \
             file://check_version.patch \
             file://perllibdir.patch \
-            file://preinst.patch"
+            file://preinst.patch \
+            file://dpkg-deb-avoid-fflush.patch"
 
 SRC_URI[md5sum] = "d1731d4147c1ea3b537a4d094519a6dc"
 SRC_URI[sha256sum] = "1ec1376471b04717a4497e5d7a27cd545248c92116898ce0c53ced8ea94267b5"
 
-PR = "${INC_PR}.3"
+PR = "${INC_PR}.4"
 

meta/recipes-devtools/gcc/gcc-package-target.inc

@@ -1,5 +1,5 @@
 PACKAGES = "\
-  ${PN} ${PN}-symlinks \
+  ${PN} ${PN}-plugins ${PN}-symlinks \
   g++ g++-symlinks \
   cpp cpp-symlinks \
   g77 g77-symlinks \
@@ -40,6 +40,11 @@ FILES_${PN}-symlinks = "\
   ${bindir}/gccbug \
 "
 
+FILES_${PN}-plugins = "\
+  ${gcclibdir}/${TARGET_SYS}/${BINV}/plugin \
+"
+ALLOW_EMPTY_${PN}-plugins = "1"
+
 FILES_g77 = "\
   ${bindir}/${TARGET_PREFIX}g77 \
   ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/f771 \
@@ -88,6 +93,7 @@ do_install () {
 	rm -r ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/install-tools
 	rm -r ${D}${libexecdir}/gcc/${TARGET_SYS}/${BINV}/install-tools
 	rm -rf ${D}${libexecdir}/gcc/${TARGET_SYS}/${BINV}/*.la
+	rmdir ${D}${includedir}
 
 	# Hack around specs file assumptions
 	test -f ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/specs && sed -i -e '/^*cross_compile:$/ { n; s/1/0/; }' ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/specs

meta/recipes-devtools/gcc/libgcc_4.6.bb

@@ -16,7 +16,7 @@ PACKAGES = "\
 FILES_${PN} = "${base_libdir}/libgcc*.so.*"
 FILES_${PN}-dev = " \
   ${base_libdir}/libgcc*.so \
-  ${libdir}/${TARGET_SYS}/${BINV}/crt* \
+  ${libdir}/${TARGET_SYS}/${BINV}/*crt* \
   ${libdir}/${TARGET_SYS}/${BINV}/libgcc*"
 FILES_libgcov${PKGSUFFIX}-dev = " \
   ${libdir}/${TARGET_SYS}/${BINV}/libgcov.a"

meta/recipes-devtools/openjade/openjade-1.3.2/reautoconf.patch

@@ -0,0 +1,83 @@
+Ensure we reautoconf the packag
+
+Currently since configure.in in is in a subdirectory, we don't reautoconf the 
+recipe. We really need to do this, to update things like the libtool script used
+and fix various issues such as those that could creep in if a reautoconf is 
+triggered for some reason. Since this source only calls AM_INIT_AUTOMAKE to 
+gain the PACKAGE and VERSION definitions and that macro now errors if Makefile.am 
+doesn't exist, we need to add these definitions manually. 
+
+These changes avoid failures like: 
+---- 
+| ... 
+| DssslApp.cxx:117:36: error: 'PACKAGE' was not declared in this scope 
+| DssslApp.cxx:118:36: error: 'VERSION' was not declared in this scope 
+| make[2]: *** [DssslApp.lo] Error 1 ----
+
+Upstream-Status: Pending
+
+RP 2012/6/12
+
+Index: openjade-1.3.2/acinclude.m4
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ openjade-1.3.2/acinclude.m4	2012-06-12 12:48:54.871365344 +0000
+@@ -0,0 +1,39 @@
++dnl Configure-time switch with default
++dnl
++dnl Each switch defines an --enable-FOO and --disable-FOO option in
++dnl the resulting configure script.
++dnl
++dnl Usage:
++dnl smr_SWITCH(name, description, default, pos-def, neg-def)
++dnl
++dnl where:
++dnl
++dnl name        name of switch; generates --enable-name & --disable-name
++dnl             options
++dnl description help string is set to this prefixed by "enable" or
++dnl             "disable", whichever is the non-default value
++dnl default     either "on" or "off"; specifies default if neither
++dnl             --enable-name nor --disable-name is specified
++dnl pos-def     a symbol to AC_DEFINE if switch is on (optional)
++dnl neg-def     a symbol to AC_DEFINE if switch is off (optional)
++dnl
++AC_DEFUN(smr_SWITCH, [
++    AC_MSG_CHECKING(whether to enable $2)
++    AC_ARG_ENABLE(
++        $1,
++        ifelse($3, on,
++            [  --disable-[$1]    disable [$2]],
++            [  --enable-[$1]     enable [$2]]),
++        [ if test "$enableval" = yes; then
++            AC_MSG_RESULT(yes)
++            ifelse($4, , , AC_DEFINE($4))
++        else
++            AC_MSG_RESULT(no)
++            ifelse($5, , , AC_DEFINE($5))
++        fi ],
++        ifelse($3, on,
++           [ AC_MSG_RESULT(yes)
++             ifelse($4, , , AC_DEFINE($4)) ],
++           [ AC_MSG_RESULT(no)
++            ifelse($5, , , AC_DEFINE($5))]))])
++
+Index: openjade-1.3.2/config/configure.in
+===================================================================
+--- openjade-1.3.2.orig/config/configure.in	2012-06-12 12:47:20.735365445 +0000
++++ openjade-1.3.2/config/configure.in	2012-06-12 12:48:17.507364080 +0000
+@@ -12,9 +12,12 @@
+ dnl  Credits: this autoconf script was largely "inspired" <g> by the
+ dnl  autoconf script around SP made by Henry Thompson.
+ dnl
+-AC_INIT(dsssl)
++AC_INIT([openjade], [1.3.2])
+ AC_CONFIG_AUX_DIR(config)
+-AM_INIT_AUTOMAKE( openjade, 1.3.2)
++AC_SUBST([PACKAGE], [openjade])
++AC_SUBST([VERSION], [1.3.2])
++AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE")
++AC_DEFINE_UNQUOTED(VERSION, "$VERSION")
+ TOP=`pwd`
+ AC_SUBST(TOP)
+ dnl

meta/recipes-devtools/openjade/openjade-native_1.3.2.bb

@@ -14,6 +14,7 @@ RDEPENDS_${PN} = "sgml-common-native"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/openjade/openjade-${PV}.tar.gz \
            file://makefile.patch \
+           file://reautoconf.patch \
 	   file://user-declared-default-constructor.patch"
 
 SRC_URI[md5sum] = "7df692e3186109cc00db6825b777201e"
@@ -38,6 +39,10 @@ CFLAGS =+ "-I${S}/include"
 SSTATEPOSTINSTFUNCS += "openjade_sstate_postinst"
 SYSROOT_PREPROCESS_FUNCS += "openjade_sysroot_preprocess"
 
+# configure.in needs to be reloacted to trigger reautoconf
+do_configure_prepend () {
+	cp ${S}/config/configure.in ${S}/
+}
 
 # We need to do this else the source interdependencies aren't generated and
 # build failures can result (e.g. zero size style/Makefile.dep file)

meta/recipes-devtools/pseudo/files/symver.patch

@@ -0,0 +1,26 @@
+When running as pseudo-nativesdk, we might need to run host binaries 
+linked against the host libc. Having a 2.14 libc dependency from memcpy is
+problematic so instruct the linker to use older symbols.
+
+Upstream-Status: Pending
+
+RP 2012/4/22
+
+Index: pseudo-1.3/pseudo.h
+===================================================================
+--- pseudo-1.3.orig/pseudo.h	2012-04-22 12:17:59.078909060 +0000
++++ pseudo-1.3/pseudo.h	2012-04-22 12:32:42.954888587 +0000
+@@ -29,6 +29,13 @@
+ int pseudo_set_value(const char *key, const char *value);
+ char *pseudo_get_value(const char *key);
+ 
++#ifdef __amd64__   
++#define GLIBC_COMPAT_SYMBOL(SYM) __asm__(".symver " #SYM "," #SYM "@GLIBC_2.2.5")
++#else   
++#define GLIBC_COMPAT_SYMBOL(SYM) __asm__(".symver " #SYM "," #SYM "@GLIBC_2.0")
++#endif
++GLIBC_COMPAT_SYMBOL(memcpy);
++
+ #include "pseudo_tables.h"
+ 
+ extern void pseudo_debug_verbose(void);

meta/recipes-devtools/pseudo/pseudo.inc

@@ -9,6 +9,8 @@ SECTION = "base"
 LICENSE = "LGPL2.1"
 DEPENDS = "sqlite3"
 
+SRC_URI_append_virtclass-nativesdk = " file://symver.patch"
+
 FILES_${PN} = "${libdir}/pseudo/lib*/libpseudo.so ${bindir}/* ${localstatedir}/pseudo ${prefix}/var/pseudo"
 FILES_${PN}-dbg += "${libdir}/pseudo/lib*/.debug"
 PROVIDES += "virtual/fakeroot"
@@ -25,7 +27,7 @@ NO32LIBS ??= "1"
 
 # Compile for the local machine arch...
 do_compile () {
-	if [ "${SITEINFO_BITS}" == "64" ]; then
+	if [ "${SITEINFO_BITS}" = "64" ]; then
 	  ${S}/configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib${SITEINFO_BITS} --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS} --enable-static-sqlite --without-rpath
 	else
 	  ${S}/configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=${SITEINFO_BITS} --enable-static-sqlite --without-rpath
@@ -37,7 +39,7 @@ do_compile () {
 # If necessary compile for the alternative machine arch.  This is only 
 # necessary in a native build.
 do_compile_prepend_virtclass-native () {
-	if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" == "pseudo-native" -a "${NO32LIBS}" != "1" ]; then
+	if [ "${SITEINFO_BITS}" = "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" = "pseudo-native" -a "${NO32LIBS}" != "1" ]; then
 		# We need the 32-bit libpseudo on a 64-bit machine...
 		./configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32 --without-rpath
 		oe_runmake ${MAKEOPTS} libpseudo
@@ -47,7 +49,7 @@ do_compile_prepend_virtclass-native () {
 }
 
 do_compile_prepend_virtclass-nativesdk () {
-	if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" == "pseudo-native" -a "${NO32LIBS}" != "1" ]; then
+	if [ "${SITEINFO_BITS}" = "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" = "pseudo-native" -a "${NO32LIBS}" != "1" ]; then
 		# We need the 32-bit libpseudo on a 64-bit machine...
 		./configure --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --bits=32 --without-rpath
 		oe_runmake ${MAKEOPTS} libpseudo
@@ -64,19 +66,17 @@ do_install () {
 # If necessary install for the alternative machine arch.  This is only 
 # necessary in a native build.
 do_install_append_virtclass-native () {
-	if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" == "pseudo-native" -a "${NO32LIBS}" != "1" ]; then
+	if [ "${SITEINFO_BITS}" = "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" = "pseudo-native" -a "${NO32LIBS}" != "1" ]; then
 		mkdir -p ${D}${prefix}/lib/pseudo/lib
 		cp lib/pseudo/lib/libpseudo.so ${D}${prefix}/lib/pseudo/lib/.
 	fi
 }
 
 do_install_append_virtclass-nativesdk () {
-	if [ "${SITEINFO_BITS}" == "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" == "pseudo-native" -a "${NO32LIBS}" != "1" ]; then
+	if [ "${SITEINFO_BITS}" = "64" -a -e "/usr/include/gnu/stubs-32.h" -a "${PN}" = "pseudo-native" -a "${NO32LIBS}" != "1" ]; then
 		mkdir -p ${D}${prefix}/lib/pseudo/lib
 		cp lib/pseudo/lib/libpseudo.so ${D}${prefix}/lib/pseudo/lib/.
 	fi
-
-	create_wrapper ${D}${bindir}/pseudo LD_LIBRARY_PATH=${base_libdir}:${libdir}
 }
 
 BBCLASSEXTEND = "native nativesdk"

meta/recipes-devtools/pseudo/pseudo_1.3.bb

@@ -1,6 +1,6 @@
 require pseudo.inc
 
-PR = "r9"
+PR = "r10"
 
 SRC_URI = "http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2"
 

meta/recipes-devtools/pseudo/pseudo_git.bb

@@ -2,7 +2,7 @@ require pseudo.inc
 
 SRCREV = "f0375c9aaefbccfd41aebbf6d332bb4d9e8f980c"
 PV = "1.3+git${SRCPV}"
-PR = "r24"
+PR = "r25"
 
 DEFAULT_PREFERENCE = "-1"
 

meta/recipes-devtools/python/python/01-use-proper-tools-for-cross-build.patch

@@ -119,8 +119,8 @@ Index: Python-2.7.2/setup.py
  
          # XXX Omitted modules: gl, pure, dl, SGI-specific modules
  
-+        lib_dirs = [ os.getenv( "STAGING_LIBDIR" ) ]
-+        inc_dirs = [ os.getenv( "STAGING_INCDIR" ) ]
++        lib_dirs = [ os.getenv("STAGING_LIBDIR"),  os.getenv("STAGING_BASELIBDIR") ]
++        inc_dirs = [ os.getenv("STAGING_INCDIR") ]
 +
          #
          # The following modules are all pretty straightforward, and compile

meta/recipes-devtools/python/python/check-if-target-is-64b-not-host.patch

@@ -0,0 +1,57 @@
+Author: Andrei Gherzan <andrei@gherzan.ro>
+Date:   Sun Mar 25 02:02:27 2012 +0200
+
+This patch was added for 64bit host machines. In the compile process python
+is checking if platform is a 64bit platform using sys.maxint which is the host's
+value. The patch fixes this issue so that python would check if TARGET machine
+is 64bit not the HOST machine. In this way will have "dl" and "imageop" modules
+built if HOST machine is 64bit but the target machine is 32bit.
+
+Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
+
+Upstream-Status: Pending
+
+Index: Python-2.7.2/setup.py
+===================================================================
+--- Python-2.7.2.orig/setup.py	2012-03-25 01:10:41.540163187 +0200
++++ Python-2.7.2/setup.py	2012-03-25 01:26:06.092539990 +0200
+@@ -23,6 +23,21 @@
+ # This global variable is used to hold the list of modules to be disabled.
+ disabled_module_list = []
+ 
++def target_is_64bit_platform ():
++    """
++    In case of cross-compile, some modules are not build as setup checks if HOST
++    is 64bit and not TARGET.
++    As python was built for TARGET we can check this in pyconfig.h in this way:
++	Sizeof LONG on a 32 bit platform is 4 bytes
++	Sizeof LONG on a 64 bit platform is 8 bytes
++    """
++    pyconf = open("pyconfig.h").read()
++    aux = re.search(r"#s*define\s+SIZEOF_LONG\s+8\s*", pyconf)
++    if aux is not None:
++	return True
++    else:
++	return False
++
+ def add_dir_to_list(dirlist, dir):
+     """Add the directory 'dir' to the list 'dirlist' (at the front) if
+     1) 'dir' is not already in 'dirlist'
+@@ -628,7 +643,7 @@
+         exts.append( Extension('audioop', ['audioop.c']) )
+ 
+         # Disabled on 64-bit platforms
+-        if sys.maxint != 9223372036854775807L:
++        if not target_is_64bit_platform():
+             # Operations on images
+             exts.append( Extension('imageop', ['imageop.c']) )
+         else:
+@@ -1418,7 +1433,7 @@
+                 missing.append('_codecs_%s' % loc)
+ 
+         # Dynamic loading module
+-        if sys.maxint == 0x7fffffff:
++        if not target_is_64bit_platform():
+             # This requires sizeof(int) == sizeof(long) == sizeof(char*)
+             dl_inc = find_file('dlfcn.h', [], inc_dirs)
+             if (dl_inc is not None) and (platform not in ['atheos']):

meta/recipes-devtools/python/python/search_db_h_in_inc_dirs_and_avoid_warning.patch

@@ -0,0 +1,40 @@
+python should search for db.h in inc_dirs and not in a hardcoded path.
+If db.h is found but HASHVERSION is not 2 we avoid a warning by not 
+adding this module to missing variable.
+
+Upstream-Status: Inappropriate [distribution]
+
+Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
+
+Index: Python-2.7.2/setup.py
+===================================================================
+--- Python-2.7.2.orig/setup.py	2012-04-05 22:27:22.437199989 +0300
++++ Python-2.7.2/setup.py	2012-04-05 22:26:38.000000000 +0300
+@@ -1141,12 +1141,12 @@
+         # the more recent berkeleydb's db.h file first in the include path
+         # when attempting to compile and it will fail.
+         f = "/usr/include/db.h"
+-
++        if len(inc_dirs) != 0:
++            f = os.path.join(inc_dirs[0], "db.h")
+         if sys.platform == 'darwin':
+             if is_macosx_sdk_path(f):
+                 sysroot = macosx_sdk_root()
+                 f = os.path.join(sysroot, f[1:])
+-
+         if os.path.exists(f) and not db_incs:
+             data = open(f).read()
+             m = re.search(r"#s*define\s+HASHVERSION\s+2\s*", data)
+@@ -1161,8 +1161,10 @@
+                                           libraries=libraries))
+                 else:
+                     exts.append(Extension('bsddb185', ['bsddbmodule.c']))
+-            else:
+-                missing.append('bsddb185')
++            # If a newer version is detected don't report an useless
++            # warning
++            #else:
++            #    missing.append('bsddb185')
+         else:
+             missing.append('bsddb185')
+ 

meta/recipes-devtools/python/python/setuptweaks.patch

@@ -0,0 +1,57 @@
+This patch removes various ways native system options can pass into the python 
+compilation and somehow break C modules.
+
+Upstream-Status: Configuration [OE Specific]
+
+RP 2012/04/23
+
+Index: Python-2.7.2/setup.py
+===================================================================
+--- Python-2.7.2.orig/setup.py	2012-04-23 20:03:47.295582553 +0000
++++ Python-2.7.2/setup.py	2012-04-23 20:03:15.000000000 +0000
+@@ -231,7 +231,13 @@
+         # compilers
+         if compiler is not None:
+             (ccshared,cflags) = sysconfig.get_config_vars('CCSHARED','CFLAGS')
+-            args['compiler_so'] = compiler + ' ' + ccshared + ' ' + cflags
++            # Need to filter out -isysroot from the flags. Ideally should 
++            # figure out target flags here.
++            flags = []
++            for f in cflags.split():
++                if not f.startswith("-isystem"):
++                    flags.append(f)
++            args['compiler_so'] = compiler + ' ' + ccshared + ' ' + ' '.join(flags)
+         self.compiler.set_executables(**args)
+ 
+         build_ext.build_extensions(self)
+@@ -393,7 +399,6 @@
+         # into configure and stored in the Makefile (issue found on OS X 10.3).
+         for env_var, arg_name, dir_list in (
+                 ('LDFLAGS', '-R', self.compiler.runtime_library_dirs),
+-                ('LDFLAGS', '-L', self.compiler.library_dirs),
+                 ('CPPFLAGS', '-I', self.compiler.include_dirs)):
+             env_val = sysconfig.get_config_var(env_var)
+             if env_val:
+@@ -419,16 +424,16 @@
+                     for directory in reversed(options.dirs):
+                         add_dir_to_list(dir_list, directory)
+ 
+-        if os.path.normpath(sys.prefix) != '/usr' \
+-                and not sysconfig.get_config_var('PYTHONFRAMEWORK'):
++#        if os.path.normpath(sys.prefix) != '/usr' \
++#                and not sysconfig.get_config_var('PYTHONFRAMEWORK'):
+             # OSX note: Don't add LIBDIR and INCLUDEDIR to building a framework
+             # (PYTHONFRAMEWORK is set) to avoid # linking problems when
+             # building a framework with different architectures than
+             # the one that is currently installed (issue #7473)
+-            add_dir_to_list(self.compiler.library_dirs,
+-                            sysconfig.get_config_var("LIBDIR"))
+-            add_dir_to_list(self.compiler.include_dirs,
+-                            sysconfig.get_config_var("INCLUDEDIR"))
++#            add_dir_to_list(self.compiler.library_dirs,
++#                            sysconfig.get_config_var("LIBDIR"))
++#            add_dir_to_list(self.compiler.include_dirs,
++#                            sysconfig.get_config_var("INCLUDEDIR"))
+ 
+         try:
+             have_unicode = unicode

meta/recipes-devtools/python/python_2.7.2.bb

@@ -1,6 +1,6 @@
 require python.inc
 DEPENDS = "python-native bzip2 db gdbm openssl readline sqlite3 zlib"
-PR = "${INC_PR}.12"
+PR = "${INC_PR}.17"
 
 DISTRO_SRC_URI ?= "file://sitecustomize.py"
 DISTRO_SRC_URI_linuxstdbase = ""
@@ -21,6 +21,9 @@ SRC_URI += "\
   file://host_include_contamination.patch \
   file://sys_platform_is_now_always_linux2.patch \
   file://fix_for_using_different_libdir.patch \
+  file://setuptweaks.patch \
+  file://check-if-target-is-64b-not-host.patch \
+  file://search_db_h_in_inc_dirs_and_avoid_warning.patch \
 "
 
 S = "${WORKDIR}/Python-${PV}"
@@ -33,6 +36,7 @@ TARGET_CC_ARCH_append_armv6 = " -D__SOFTFP__"
 TARGET_CC_ARCH_append_armv7a = " -D__SOFTFP__"
 
 do_configure_prepend() {
+	rm -f ${S}/Makefile.orig
 	autoreconf -Wcross --verbose --install --force --exclude=autopoint Modules/_ctypes/libffi || bbnote "_ctypes failed to autoreconf"
 }
 
@@ -65,10 +69,17 @@ do_compile() {
 	# remove any bogus LD_LIBRARY_PATH
 	sed -i -e s,RUNSHARED=.*,RUNSHARED=, Makefile
 
-	install -m 0644 Makefile Makefile.orig
-	sed -i -e 's,${includedir},${STAGING_INCDIR},' Makefile
-	sed -i -e 's,${libdir},${STAGING_LIBDIR},' Makefile
-	sed -i -e 's,LDFLAGS=,LDFLAGS=-L. -L${STAGING_LIBDIR},' Makefile
+	if [ ! -f Makefile.orig ]; then
+		install -m 0644 Makefile Makefile.orig
+	fi
+	sed -i -e 's,^LDFLAGS=.*,LDFLAGS=-L. -L${STAGING_LIBDIR},g' \
+		-e 's,libdir=${libdir},libdir=${STAGING_LIBDIR},g' \
+		-e 's,libexecdir=${libexecdir},libexecdir=${STAGING_DIR_HOST}${libexecdir},g' \
+		-e 's,^LIBDIR=.*,LIBDIR=${STAGING_LIBDIR},g' \
+		-e 's,includedir=${includedir},includedir=${STAGING_INCDIR},g' \
+		-e 's,^INCLUDEDIR=.*,INCLUDE=${STAGING_INCDIR},g' \
+		-e 's,^CONFINCLUDEDIR=.*,CONFINCLUDE=${STAGING_INCDIR},g' \
+		Makefile
 	install -m 0644 Makefile ${STAGING_LIBDIR}/python${PYTHON_MAJMIN}/config/
 	# save copy of it now, because if we do it in do_install and 
 	# then call do_install twice we get Makefile.orig == Makefile.sysroot
@@ -79,6 +90,7 @@ do_compile() {
 	oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/pgen \
 		HOSTPYTHON=${STAGING_BINDIR_NATIVE}/python \
 		STAGING_LIBDIR=${STAGING_LIBDIR} \
+		STAGING_BASELIBDIR=${STAGING_BASELIBDIR} \
 		STAGING_INCDIR=${STAGING_INCDIR} \
 		BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
 		OPT="${CFLAGS}" libpython${PYTHON_MAJMIN}.so
@@ -89,6 +101,7 @@ do_compile() {
 		HOSTPYTHON=${STAGING_BINDIR_NATIVE}/python \
 		STAGING_LIBDIR=${STAGING_LIBDIR} \
 		STAGING_INCDIR=${STAGING_INCDIR} \
+		STAGING_BASELIBDIR=${STAGING_BASELIBDIR} \
 		BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
 		OPT="${CFLAGS}"
 }
@@ -105,6 +118,7 @@ do_install() {
 		CROSSPYTHONPATH=${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-dynload/ \
 		STAGING_LIBDIR=${STAGING_LIBDIR} \
 		STAGING_INCDIR=${STAGING_INCDIR} \
+		STAGING_BASELIBDIR=${STAGING_BASELIBDIR} \
 		BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
 		DESTDIR=${D} LIBDIR=${libdir} install
 
@@ -133,8 +147,8 @@ RRECOMMENDS_${PN}-core = "${PN}-readline"
 RRECOMMENDS_${PN}-crypt = "openssl"
 
 # package libpython2
-PACKAGES =+ "lib${BPN}2"
-FILES_lib${BPN}2 = "${libdir}/libpython*.so.*"
+PACKAGES =+ "lib${BPN}2${PKGSUFFIX}"
+FILES_lib${BPN}2${PKGSUFFIX} = "${libdir}/libpython*.so.*"
 
 # catch debug extensions (isn't that already in python-core-dbg?)
 FILES_${PN}-dbg += "${libdir}/python${PYTHON_MAJMIN}/lib-dynload/.debug"
@@ -148,3 +162,6 @@ PACKAGES += "${PN}-man"
 FILES_${PN}-man = "${datadir}/man"
 
 BBCLASSEXTEND = "nativesdk"
+
+PKGSUFFIX = ""
+PKGSUFFIX_virtclass-nativesdk = "-nativesdk"

meta/recipes-devtools/qemu/qemu-0.15.1/a4d1f142542935b90d2eb30f3aead4edcf455fe6.patch

@@ -0,0 +1,66 @@
+From a4d1f142542935b90d2eb30f3aead4edcf455fe6 Mon Sep 17 00:00:00 2001
+From: Aurelien Jarno <aurelien@aurel32.net>
+Date: Sat, 7 Jan 2012 15:20:11 +0100
+Subject: [PATCH 1/1] target-i386: fix {min,max}{pd,ps,sd,ss} SSE2 instructions
+
+minpd, minps, minsd, minss and maxpd, maxps, maxsd, maxss SSE2
+instructions have been broken when switching target-i386 to softfloat.
+It's not possible to use comparison instructions on float types anymore
+to softfloat, so use the floatXX_lt function instead, as the
+float_XX_min and float_XX_max functions can't be used due to the Intel
+specific behaviour.
+
+As it implements the correct NaNs behaviour, let's remove the
+corresponding entry from the TODO.
+
+It fixes GDM screen display on Debian Lenny.
+
+Thanks to Peter Maydell and Jason Wessel for their analysis of the
+problem.
+
+Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
+---
+ target-i386/TODO      |    1 -
+ target-i386/ops_sse.h |    9 +++++++--
+ 2 files changed, 7 insertions(+), 3 deletions(-)
+
+This fixes scrollbar issues in matchbox-terminal/vte on qemux86-64 and
+files not appearing in pcmanfm, as well as glib/gobject errors to do with gdoubles
+on the console [YOCTO #1906]
+
+Upstream-Status: Backport
+
+Index: qemu-0.15.1/target-i386/TODO
+===================================================================
+--- qemu-0.15.1.orig/target-i386/TODO	2011-10-12 16:41:43.000000000 +0000
++++ qemu-0.15.1/target-i386/TODO	2012-04-19 07:30:38.704073075 +0000
+@@ -15,7 +15,6 @@
+ - DRx register support
+ - CR0.AC emulation
+ - SSE alignment checks
+-- fix SSE min/max with nans
+ 
+ Optimizations/Features:
+ 
+Index: qemu-0.15.1/target-i386/ops_sse.h
+===================================================================
+--- qemu-0.15.1.orig/target-i386/ops_sse.h	2011-10-12 16:41:43.000000000 +0000
++++ qemu-0.15.1/target-i386/ops_sse.h	2012-04-19 07:30:38.712073076 +0000
+@@ -584,10 +584,15 @@
+ #define FPU_SUB(size, a, b) float ## size ## _sub(a, b, &env->sse_status)
+ #define FPU_MUL(size, a, b) float ## size ## _mul(a, b, &env->sse_status)
+ #define FPU_DIV(size, a, b) float ## size ## _div(a, b, &env->sse_status)
+-#define FPU_MIN(size, a, b) (a) < (b) ? (a) : (b)
+-#define FPU_MAX(size, a, b) (a) > (b) ? (a) : (b)
+ #define FPU_SQRT(size, a, b) float ## size ## _sqrt(b, &env->sse_status)
+ 
++/* Note that the choice of comparison op here is important to get the
++ * special cases right: for min and max Intel specifies that (-0,0),
++ * (NaN, anything) and (anything, NaN) return the second argument.
++ */
++#define FPU_MIN(size, a, b) float ## size ## _lt(a, b, &env->sse_status) ? (a) : (b)
++#define FPU_MAX(size, a, b) float ## size ## _lt(b, a, &env->sse_status) ? (a) : (b)
++
+ SSE_HELPER_S(add, FPU_ADD)
+ SSE_HELPER_S(sub, FPU_SUB)
+ SSE_HELPER_S(mul, FPU_MUL)

meta/recipes-devtools/qemu/qemu_0.15.1.bb

@@ -3,7 +3,7 @@ require qemu.inc
 LIC_FILES_CHKSUM = "file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \
                     file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913"
 
-PR = "r5"
+PR = "r6"
 
 FILESPATH = "${FILE_DIRNAME}/qemu-${PV}"
 FILESDIR = "${WORKDIR}"
@@ -18,6 +18,7 @@ SRC_URI = "\
     file://fallback-to-safe-mmap_min_addr.patch \
     file://larger_default_ram_size.patch \
     file://arm-bgr.patch \
+    file://a4d1f142542935b90d2eb30f3aead4edcf455fe6.patch \
     "
 
 # Only use the GL passthrough patches for native/nativesdk versions

meta/recipes-devtools/quilt/quilt-0.51.inc

@@ -24,11 +24,6 @@ RDEPENDS_${PN} = "bash"
 # quilt ignores DESTDIR
 do_install () {
 	oe_runmake 'BUILD_ROOT=${D}' install
-	if [ "${BUILD_ARCH}" == "${HOST_ARCH}" ]; then
-		# Dummy quiltrc file for patch.bbclass
-		install -d ${D}${bindir}/
-		touch ${D}${bindir}/quiltrc
-	fi
 	# cleanup unpackaged files
 	rm -rf ${D}/${datadir}/emacs
 }

meta/recipes-devtools/quilt/quilt-native.inc

@@ -11,3 +11,9 @@ EXTRA_OECONF = "--disable-nls"
 do_configure () {
 	oe_runconf
 }
+
+do_install_append () {
+	# Dummy quiltrc file for patch.bbclass
+	install -d ${D}${sysconfdir}/
+	touch ${D}${sysconfdir}/quiltrc
+}