documentation/bsp: update to reference FILESEXTRAPATHS

It's no longer neccesarry to define THISDIR and FILESPATH in each bbappend
recipe. Should you need to reference extra files you should use FILESEXTRAPATHS

Signed-off-by: Joshua Lock <josh@linux.intel.com>

bitbake/lib/bb/fetch/__init__.py

@@ -225,6 +225,12 @@ def init(urls, d, setup = True):
 def mirror_from_string(data):
     return [ i.split() for i in (data or "").replace('\\n','\n').split('\n') if i ]
 
+def removefile(f):
+    try:
+        os.remove(f)
+    except:
+        pass
+
 def go(d, urls = None):
     """
     Fetch all urls
@@ -237,32 +243,14 @@ def go(d, urls = None):
     for u in urls:
         ud = urldata[u]
         m = ud.method
-        premirror_fetch = True
         localpath = ""
 
-        if ud.localfile:
+        if not ud.localfile:
-            if not m.try_premirror(u, ud, d):
+            continue
-                premirror_fetch = False
-                # File already present along with md5 stamp file
-                # Touch md5 file to show activity
-                try:
-                    os.utime(ud.md5, None)
-                except:
-                    # Errors aren't fatal here
-                    pass
 
-            lf = bb.utils.lockfile(ud.lockfile)
+        lf = bb.utils.lockfile(ud.lockfile)
-            if not m.try_premirror(u, ud, d):
-                premirror_fetch = False
-                # If someone else fetched this before we got the lock,
-                # notice and don't try again
-                try:
-                    os.utime(ud.md5, None)
-                except:
-                    # Errors aren't fatal here
-                    pass
 
-        if premirror_fetch:
+        if m.try_premirror(u, ud, d):
             # First try fetching uri, u, from PREMIRRORS
             mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', d, True))
             localpath = try_mirrors(d, u, mirrors, False, m.forcefetch(u, ud, d))
@@ -276,20 +264,26 @@ def go(d, urls = None):
                 m.go(u, ud, d)
                 localpath = ud.localpath
             except FetchError:
+                # Remove any incomplete file
+                removefile(ud.localpath)
                 # Finally, try fetching uri, u, from MIRRORS
                 mirrors = mirror_from_string(bb.data.getVar('MIRRORS', d, True))
                 localpath = try_mirrors (d, u, mirrors)
                 if not localpath or not os.path.exists(localpath):
                     raise FetchError("Unable to fetch URL %s from any source." % u)
 
-        if localpath:
+        ud.localpath = localpath
-            ud.localpath = localpath
+        if os.path.exists(ud.md5):
-
+            # Touch the md5 file to show active use of the download
-        if ud.localfile:
+            try:
-            if not m.forcefetch(u, ud, d):
+                os.utime(ud.md5, None)
-                Fetch.write_md5sum(u, ud, d)
+            except:
-            bb.utils.unlockfile(lf)
+                # Errors aren't fatal here
+                pass
+        else:
+            Fetch.write_md5sum(u, ud, d)
 
+        bb.utils.unlockfile(lf)
 
 def checkstatus(d):
     """
@@ -301,7 +295,7 @@ def checkstatus(d):
     for u in urldata:
         ud = urldata[u]
         m = ud.method
-        bb.msg.note(1, bb.msg.domain.Fetcher, "Testing URL %s" % u)
+        bb.msg.debug(1, bb.msg.domain.Fetcher, "Testing URL %s" % u)
         # First try checking uri, u, from PREMIRRORS
         mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', d, True))
         ret = try_mirrors(d, u, mirrors, True)
@@ -484,6 +478,7 @@ def try_mirrors(d, uri, mirrors, check = False, force = False):
                 import sys
                 (type, value, traceback) = sys.exc_info()
                 bb.msg.debug(2, bb.msg.domain.Fetcher, "Mirror fetch failure: %s" % value)
+                removefile(ud.localpath)
                 continue
     return None
 

bitbake/lib/bb/fetch/git.py

@@ -86,13 +86,23 @@ class Git(Fetch):
         return os.path.join(data.getVar("DL_DIR", d, True), ud.localfile)
 
     def forcefetch(self, url, ud, d):
-        if not self._contains_ref(ud.tag, d) or 'fullclone' in ud.parm:
+        if 'fullclone' in ud.parm:
+            return True
+        if 'noclone' in ud.parm:
+            return False
+        if os.path.exists(ud.localpath):
+            return False
+        if not self._contains_ref(ud.tag, d):
             return True
         return False
 
     def try_premirror(self, u, ud, d):
+        if 'noclone' in ud.parm:
+            return False
         if os.path.exists(ud.clonedir):
             return False
+        if os.path.exists(ud.localpath):
+            return False
 
         return True
 
@@ -109,24 +119,37 @@ class Git(Fetch):
         coname = '%s' % (ud.tag)
         codir = os.path.join(ud.clonedir, coname)
 
-        if not os.path.exists(ud.clonedir):
+        # If we have no existing clone and no mirror tarball, try and obtain one
+        if not os.path.exists(ud.clonedir) and not os.path.exists(repofile):
             try:
                 Fetch.try_mirrors(ud.mirrortarball)
-                bb.mkdirhier(ud.clonedir)
-                os.chdir(ud.clonedir)
-                runfetchcmd("tar -xzf %s" % (repofile), d)
             except:
-                runfetchcmd("%s clone -n %s://%s%s%s %s" % (ud.basecmd, ud.proto, username, ud.host, ud.path, ud.clonedir), d)
+                pass
+
+        # If the checkout doesn't exist and the mirror tarball does, extract it
+        if not os.path.exists(ud.clonedir) and os.path.exists(repofile):
+            bb.mkdirhier(ud.clonedir)
+            os.chdir(ud.clonedir)
+            runfetchcmd("tar -xzf %s" % (repofile), d)
+
+        # If the repo still doesn't exist, fallback to cloning it
+        if not os.path.exists(ud.clonedir):
+            runfetchcmd("%s clone -n %s://%s%s%s %s" % (ud.basecmd, ud.proto, username, ud.host, ud.path, ud.clonedir), d)
 
         os.chdir(ud.clonedir)
+        # Update the checkout if needed
         if not self._contains_ref(ud.tag, d) or 'fullclone' in ud.parm:
             # Remove all but the .git directory
             runfetchcmd("rm * -Rf", d)
-            runfetchcmd("%s fetch %s://%s%s%s %s" % (ud.basecmd, ud.proto, username, ud.host, ud.path, ud.branch), d)
+            if 'fullclone' in ud.parm:
+                runfetchcmd("%s fetch --all" % (ud.basecmd), d)
+            else:
+                runfetchcmd("%s fetch %s://%s%s%s %s" % (ud.basecmd, ud.proto, username, ud.host, ud.path, ud.branch), d)
             runfetchcmd("%s fetch --tags %s://%s%s%s" % (ud.basecmd, ud.proto, username, ud.host, ud.path), d)
             runfetchcmd("%s prune-packed" % ud.basecmd, d)
             runfetchcmd("%s pack-redundant --all | xargs -r rm" % ud.basecmd, d)
 
+        # Generate a mirror tarball if needed
         os.chdir(ud.clonedir)
         mirror_tarballs = data.getVar("BB_GENERATE_MIRROR_TARBALLS", d, True)
         if mirror_tarballs != "0" or 'fullclone' in ud.parm:

bitbake/lib/bb/runqueue.py

@@ -1066,6 +1066,10 @@ class RunQueueExecute:
                 for var in envvars:
                     comps = var.split("=")
                     env[comps[0]] = comps[1]
+                fakedirs = (the_data.getVar("FAKEROOTDIRS", True) or "").split()
+                for p in fakedirs:
+                    bb.mkdirhier(p)
+                bb.msg.debug(2, bb.msg.domain.RunQueue, "Running %s:%s under fakeroot, state dir is %s" % (fn, taskname, fakedirs))
 
             env['BB_TASKHASH'] = self.rqdata.runq_hash[task]
             env['PATH'] = self.cooker.configuration.initial_path

documentation/poky-ref-manual/Makefile

@@ -23,7 +23,7 @@ html:
 	xsltproc $(XSLTOPTS) -o bsp-guide.html $(XSL_XHTML_URI) bsp-guide.xml
 
 tarball: html
-	tar -cvzf poky-ref-manual.tgz poky-ref-manual.html style.css screenshots/ss-sato.png poky-beaver.png poky-ref-manual.png
+	tar -cvzf poky-ref-manual.tgz poky-ref-manual.html style.css figures/yocto-project-transp.png figures/poky-ref-manual.png
 
 validate:
 	xmllint --postvalid --xinclude --noout poky-ref-manual.xml

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

@@ -37,7 +37,7 @@
 
     <copyright>
       <year>2010</year>
-      <holder>Intel Corporation</holder>
+      <holder>Linux Foundation</holder>
     </copyright>
 
     <legalnotice>

documentation/poky-ref-manual/bsp.xml

@@ -105,8 +105,8 @@ meta-bsp/prebuilds/
 # We have a conf directory, add to BBPATH
 BBPATH := "${BBPATH}${LAYERDIR}"
 
-# We have a packages directory, add to BBFILES
+# We have a recipes directory containing .bb and .bbappend files, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/packages/*/*.bb"
+BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb ${LAYERDIR}/recipes/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "bsp"
 BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
@@ -115,7 +115,7 @@ BBFILE_PRIORITY_bsp = "5"
             </para>
 
             <para>
-                which simply makes bitbake aware of the packages and conf directories.
+                which simply makes bitbake aware of the recipes and conf directories.
             </para>
 
             <para>
@@ -284,13 +284,13 @@ meta-bsp/packages/image-creator/image-creator-native_0.1.bb
             This allows the BSP layer to poke around and do whatever it might want to customise
             the original recipe.
 
-            .bbappend is expected to include the below two lines in the head (which may be changed
+            If your recipe needs to reference extra files it can use the FILESEXTRAPATH variable
-            in the future):
+            to specify their location. The example below shows extra files contained in a folder
+            called ${PN} (the package name).
             </para>
 
             <programlisting>
-THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
+FILESEXTRAPATHS := "${THISDIR}/${PN}"
-FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
             </programlisting>
 
             <para>

documentation/poky-ref-manual/development.xml

@@ -4,14 +4,14 @@
 <chapter id="platdev">
 <title>Platform Development with Poky</title>
 
-<section id="platdev-appdev">
+    <section id="platdev-appdev">
     <title>Software development</title>
     <para>
         Poky supports several methods of software development. You can use the method that is 
         best for you.  This chapter describes each development method.
     </para>
 
-    <section id="platdev-appdev-external-sdk">
+        <section id="platdev-appdev-external-sdk">
         <title>External Development Using the Poky SDK</title>
         <para>
             The meta-toolchain and meta-toolchain-sdk targets (<link linkend='ref-images'>see
@@ -27,7 +27,6 @@
             autotools are also set so that, for example, configure can find pre-generated test 
             results for tests that need target hardware on which to run.
         </para>
-
         <para>
             Using the toolchain with autotool-enabled packages is straightforward - just pass the 
             appropriate host option to configure as in the following example:
@@ -39,187 +38,367 @@
      CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld
             </literallayout>
         </para>
-    </section>
-
-    <section id="platdev-appdev-external-anjuta">
-        <title>Developing externally using the Anjuta plugin</title>
-
-        <para>
-            An Anjuta IDE plugin exists to make developing software within the Poky framework
-            easier for the application developer. It presents a graphical IDE from which the 
-            developer can cross compile an application then deploy and execute the output in a QEMU 
-            emulation session. It also supports cross debugging and profiling.
-        </para>
-<!-- DISBALED, TOO BIG!
-        <screenshot>
-        <mediaobject>
-            <imageobject>
-                <imagedata fileref="screenshots/ss-anjuta-poky-1.png" format="PNG"/>
-            </imageobject>
-            <caption>
-                <para>The Anjuta Poky SDK plugin showing an active QEMU session running Sato</para>
-            </caption>
-         </mediaobject>
-         </screenshot>
--->
-        <para>
-            To use the plugin, a toolchain and SDK built by Poky is required along with Anjuta it's development
-            headers and the Anjuta plugin. The Poky Anjuta plugin is available to download as a tarball at the
-            <ulink url='http://labs.o-hand.com/anjuta-poky-sdk-plugin/'>OpenedHand labs</ulink> page or
-            directly from the Poky Git repository located at git://git.pokylinux.org/anjuta-poky; a web interface
-            to the repository can be accessed at <ulink url='http://git.pokylinux.org/?p=anjuta-poky.git;a=summary'/>.
-        </para>
-        <para>
-            See the README file contained in the project for more information on dependencies and building
-            the plugin. If you want to disable remote gdb debugging, please pass --diable-gdb-integration
-            switch when doing configure.
-        </para>
-
-        <section id="platdev-appdev-external-anjuta-setup">
-          <title>Setting up the Anjuta plugin</title>
-
-            <para>Extract the tarball for the toolchain into / as root. The
-              toolchain will be installed into
-              <filename class="directory">/opt/poky</filename>.</para>
-
-            <para>To use the plugin, first open or create an existing
-              project. If creating a new project the "C GTK+" project type
-              will allow itself to be cross-compiled.  However you should be
-              aware that this uses glade for the UI.</para>
-
-            <para>To activate the plugin go to
-              <menuchoice><guimenu>Edit</guimenu><guimenuitem>Preferences</guimenuitem></menuchoice>,
-              then choose <guilabel>General</guilabel> from the left hand side. Choose the
-              Installed plugins tab, scroll down to <guilabel>Poky
-                SDK</guilabel> and check the
-              box. The plugin is now activated but first it must be
-              configured.</para> 
         </section>
 
-        <section id="platdev-appdev-external-anjuta-configuration">
+        <section id="using-the-eclipse-and-anjuta-plug-ins">
-          <title>Configuring the Anjuta plugin</title>
+        <title>Using the Eclipse and Anjuta Plug-ins</title>
+        <para>
+            Yocto Project supports both Anjuta and Eclipse IDE plug-ins to make developing software
+            easier for the application developer. The plug-ins provide capability
+            extensions to the graphical IDE allowing for cross compilation, 
+            deployment and execution of the output in a QEMU emulation session. 
+            Support of these plug-ins also supports cross debugging and
+            profiling.  Additionally, the Eclipse plug-in provides a suite of tools 
+            that allows the developer to perform remote profiling, tracing, collection of 
+            power data, collection of latency data and collection of performance data.
+        </para>
 
-          <para>The configuration options for the SDK can be found by choosing
+            <section id="the-eclipse-plug-in">
-            the <guilabel>Poky SDK</guilabel> icon from the left hand side. The following options
+            <title>The Eclipse Plug-in</title>
-            need to be set:</para>
+            <para>
+                To use the Eclipse plug-in, a toolchain and SDK built by Poky is required along with 
+                the Eclipse Framework (Helios 3.6). 
+                To install the plug-in you need to be in the Eclipse IDE and select 
+                the following menu:
+                <literallayout class='monospaced'>
+     Help -> Install New Software
+                </literallayout>
+                Specify the target URL as http://yocto./download (real link needed).
+            </para>
+            <para>
+                If you want to download the source code for the plug-in you can find it in the Poky 
+                git repository, which has a web interface, and is located at
+                <ulink url="http://git.pokylinux.org/cgit.cgi/eclipse-poky"></ulink>.
+            </para>
+  
+                <section id="installing-and-setting-up-the-eclipse-ide">
+                <title>Installing and Setting up the Eclipse IDE</title>
+                <para>
+                    If you don't have the Eclipse IDE (Helios 3.6) on your system you need to 
+                    download and install it from <ulink url="http://www.eclipse.org/downloads"></ulink>.
+                    Choose the Eclipse Classic, which contains the Eclipse Platform, Java Development 
+                    Tools (JDT), and the Plug-in Development Environment.
+                </para>
+                <para>
+                    NOTE: Due to the Java Virtual Machine's garbage collection (GC) process the 
+                    permanent generation space (PermGen) is not cleaned up.  This space is used 
+                    to store meta-data descriptions of classes.  The default value is set too small
+                    and it could trigger an out of memory error like the following:
+                    <literallayout class='monospaced'>
+     Java.lang.OutOfMemoryError: PermGen space
+                    </literallayout>
+                    This error causes the applications to hang.  
+                </para>
+                <para>
+                    To fix this issue you can use the <command>-vmargs</command>
+                    option when you start Eclipse to increase the size of the permenant generation space:
+                    <literallayout class='monospaced'>
+     Eclipse -vmargs -XX:PermSize=256M
+                    </literallayout>
+                </para>
+                </section>
 
-          <itemizedlist>
+                <section id="installing-the-yocto-plug-in">
-            
+                <title>Installing the Yocto Plug-in</title>
-            <listitem><para><guilabel>SDK root</guilabel>: If we use external toolchain, we need to set SDK root.
+                    <para>
-                this is the root directory of the SDK's sysroot. For an i586 SDK this will be <filename
+                        Once you have the Eclipse IDE installed and configure you need to install the 
-                  class="directory">/opt/poky/</filename>.
+                        Yocto plug-in.  You do this similar to installing the Eclipse plug-ins in the 
-                This directory will contain directories named like "bin",
+                        previous section.
-                "include", "var", etc. under your selected target architecture subdirectory<filename class="directory">
+                    </para>
-                /opt/poky/sysroot/i586-poky-linux/</filename>. Needed cross compile tools are under
+                    <para>
-                <filename class ="directory">/opt/poky/sysroot/i586-pokysdk-linux/</filename>
+                        Do the following to install the Yocto plug-in into the Eclipse IDE:
-                </para></listitem>
+                    <itemizedlist>
+                        <listitem>Select the "Help -> Install New Software" item.</listitem>
+                        <listitem>In the "Work with:" area click "Add..." and enter the URL for 
+                            the Yocto plug-in (we need to supply this URL).</listitem>
+                        <listitem>Finish out the installation of the update similar to any other
+                            Eclipse plug-in.</listitem>
+                    </itemizedlist>
+                    </para>
+                </section>
+         
+                <section id="configuring-yocto-eclipse-plug-in">
+                <title>Configuring Yocto Eclipse plug-in</title>
+                <para>
+                    To configure the Yocto Eclipse plug-in you need to select the mode and then the
+                    architecture with which you will be working.  Start by selecting "Preferences" 
+                    from the "Window" menu and then selecting "Yocto SDK".
+                </para>
+                <para>
+                    If you normally will use an installed Yocto 
+                    SDK (under /opt/poky) select “SDK Root Mode”.  Otherwise, if your crosstool chain 
+                    and sysroot are within your poky tree, select “Poky Tree Mode”.  
+                    If you are in SDK Root Mode you will need to provide your poky tree path, for
+                    example, $&lt;Poky_tree&gt;/build/. 
+                </para>
+                <para>
+                    Now you need to select the architecture. 
+                    Use the drop down list and select the architecture that you’ll be primarily 
+                    working against.
+                    For target option, select your typical target QEMU vs External HW.  If you 
+                    choose QEMU, you’ll need to specify your QEMU kernel file with full path and the 
+                    rootfs mount point.  Yocto QEMU boots off user mode NFS, Please refer to QEMU
+                    section for how to set it up. (Section TBD)
+                </para>
+                <para>
+                    Save all your settings and they become your defaults for every new Yocto project
+                    created using the Eclipse IDE.
+                </para>
+                </section>
 
-            <listitem><para><guilabel>Poky root</guilabel>: If we have local poky build tree, we need to set the Poky root.
+                <section id="using-the-yocto-eclipse-plug-in">
-                this is the root directory of the poky build tree, if you build your i586 target architecture
+                <title>Using the Yocto Eclipse Plug-in</title>
-                under the subdirectory of build_x86 within your poky tree, the Poky root directory should be 
+                <para>
-                <filename class="directory">${Poky_tree}/build_x86/</filename>.
+                    As an example, this section shows you how to cross-compile a Yocto C autotools
-               </para></listitem>
+                    based project, deploy it into QEMU, and then run the debugger against it.
+                    You need to configure the project, trigger <command> autogen.sh</command>, build 
+                    the image, start QEMU, and then debug.
+                </para>
+                <orderedlist>
+                    <listitem>Creating a Yocto Autotools Based Project Using a Template:  
+                        Get to the Wizard selection by selecting the File -> New -> Project 
+                        menu.  Expand "C/C++" and select "C Project".  Click "Next" and select a template 
+                        to start with, for example "Hello World ANSI C Project".  Complete the steps
+                        to create a new Yocto autotools based project using this template.</listitem>
+                    <listitem>Specify Specific Toolchain Configurations:  By default the project 
+                        uses the Yocto preferences settings as defined using the procedure in 
+                        <link linkend="configuring-yocto-eclipse-plug-in"> the previous section</link>.
+                        If there are any specific setup requirements for the newly created project
+                        you need to reconfigure the Yocto plug-in through the menu selection
+                        Project -> Invoke Yocto Tools -> Reconfigure Yocto.  Use this dialogue
+                        to specify specific toolchain and QEMU setups for the project.</listitem>
+                    <listitem>Building the Project:  Trigger <command>autogen.sh</command> through 
+                        Project -> Reconfigure Project.  Then build the project using 
+                        Project -> Build.</listitem>
+                    <listitem>Starting QEMU:  Use the Run -> External Tools menu and see if there is 
+                        a QEMU instance for the desired target.  If there is click on the instance
+                        to start QEMU.  If your target is not there then click "External Tools
+                        Configuration".  You should find an instance of QEMU for your architecture
+                        under the entry under "Program".  After the boot completes you are ready to 
+                        deploy the image into QEMU.</listitem>
+                    <listitem>Debugging:  To bring up your remote debugging configuration in the 
+                        right-hand window highlight your project in “Project Explorer”, select 
+                        the Run -> Debug Configurations menu item and expand “C/C++ Remote Application”.
+                        Next, select projectname_ gdb_target-poky-linux.  
+                        You need to be sure that there is an
+                        entry for the remote target you want to deploy and cross debug with.  If there
+                        is no entry then click "New..." to bring up the wizard.  Using the wizard
+                        select TCF and enter the IP address of you remote target in the 
+                        “Host name:” field.  Back in the remote debug configure window, 
+                        you need to specify the absolute path for the program on the remote target 
+                        in the “Remote Absolute File Path for C/C++ Application” field.  By default, 
+                        the program deploys into the remote target.  If you don't want this then check
+                        “Skip download to target path”.  Finally, click "Debug” to start the remote
+                        debugging session.</listitem>
+                </orderedlist>
+                </section>
 
-            <listitem><para><guilabel>Target Architecture</guilabel>: this is the cross compile
+                <section id="using-yocto-eclipse-plug-in-remote-tools-suite">
-                triplet, e.g. "i586-poky-linux". This target triplet is the prefix extracted from
+                <title>Using Yocto Eclipse plug-in Remote Tools Suite</title>
-                the set up script file name. For examle, "i586-poky-linux" is extracted from set up script file
+                <para>
-                <filename>/opt/poky/environment-setup-i586-poky-linux</filename>
+                    Remote tools let you do things like perform system profiling, kernel tracing, 
-               </para></listitem>
+                    examine power consumption, and so forth.  To see and access the remote tools use the 
-
+                    Window -> YoctoTools menu.
-            <listitem><para><guilabel>Kernel</guilabel>: use the file chooser to select the kernel
+                </para>
-                to use with QEMU</para></listitem>
+                <para>
-
+                    Once you pick a tool you need to configure it for the remote target.  Every tool 
-            <listitem><para><guilabel>Root filesystem</guilabel>: use the file chooser to select
+                    needs to have the connection configured.  You have to select an existing TCF-based
-                the root filesystem directory, this is the directory where you use "poky-extract-sdk" command to 
+                    RSE connection to the remote target.  If one does not exist you need to create one
-                extract the poky-image-sdk tarball.</para></listitem>
+                    by clicking "New"
-          </itemizedlist>
+                </para>
-<!-- DISBALED, TOO BIG!
+                <para>
-        <screenshot>
+                    Here are some specifics about the remote tools:
-        <mediaobject>
+                <itemizedlist>
-            <imageobject>
+                    <listitem>Oprofile:  Selecting this tool causes the oprofile-server on the remote
-                <imagedata fileref="screenshots/ss-anjuta-poky-2.png" format="PNG"/>
+                        target to launch on the local host machine.  To use the oprofile the oprofile-viewer
-            </imageobject>
+                        must be installed on the local host machine and the oprofile-server must be
-            <caption>
+                        installed on the remote target.</listitem>
-                <para>Anjuta Preferences Dialog</para>
+                    <listitem>lttng:  Selecting this tool runs ustrace on the remote target, transfers
-            </caption>
+                        the output data back to the local host machine and uses lttv-gui to graphically
-         </mediaobject>
+                        display the output.  To use this tool the lttv-gui must be installed on the 
-         </screenshot>
+                        local host machine.  See <ulink url="http://lttng.org/files/ust/manual/ust.html">
--->
+                        </ulink> for information on how to use <command>lttng</command> to trace an 
+                        application.
+                        <para>
+                            For "Application" you must supply the absolute path name to the application to 
+                            be traced by user mode lttng.  For example, typing <command>/path/to/foo"
+                            </command> triggers <command>usttrace /path/to/foo</command> on the 
+                            remote target to trace the program <command>/path/to/foo</command>.
+                        </para>
+                        <para>
+                            "Argument" is passed to "usttrace" running on the remote target.
+                        </para>
+                    </listitem>  
+                    <listitem>powertop:  Selecting this tool runs <command>powertop</command> on the 
+                        remote target machine and displays the result in a new view called "powertop".
+                        <para>
+                            "Time to gather data(sec):" is the time passed in seconds before data is 
+                            gathered from the remote target for analysis.
+                        </para>
+                        <para>
+                            "show pids in wakeups list:" corresponds to the <command>-p</command>
+                            argument passed to <command>powertop</command>
+                        </para>
+                    </listitem>
+                    <listitem>latencytop and perf:  The <command>latencytop</command> identifies 
+                        system latency, while <command>perf</command> monitors the system's performance 
+                        counter registers.  Selecting either of these tools causes an RSE
+                        terminal view to appear in which you can run the tools.  Both tools refresh the 
+                        entire screen to display results while they run.</listitem>
+                </itemizedlist>
+                </para>
+                </section>
+            </section>
 
+            <section id="the-anjuta-plug-in">
+            <title>The Anjuta Plug-in</title>
+            <para>
+                <emphasis>Note:</emphasis>  We will stop Anjuta plug-in support after 
+                Yocto project 0.9 release.  Its source 
+                code can be downloaded from git respository listed below, and free for the community to 
+                continue supporting it moving forward.
+            </para>
+            <para>
+                An Anjuta IDE plugin exists to make developing software within the Poky framework
+                easier for the application developer. 
+                It presents a graphical IDE with which you can cross compile an application 
+                then deploy and execute the output in a 
+                QEMU emulation session. 
+                It also supports cross debugging and profiling.
+            </para>
+            <para>
+                To use the plugin, a toolchain and SDK built by Poky is required,  
+                Anjuta, it's development headers and the Anjuta plugin. 
+                The Poky Anjuta plugin is available to download as a tarball at the
+                OpenedHand 
+                labs <ulink url="http://labs.o-hand.com/anjuta-poky-sdk-plugin/"></ulink> page or 
+                directly from the Poky Git repository located at 
+                <ulink url="git://git.pokylinux.org/anjuta-poky"></ulink>.
+                You can also access a web interface to the repository at
+                <ulink url="http://git.pokylinux.org/?p=anjuta-poky.git;a=summary"></ulink>.
+             </para>
+             <para>
+                See the README file contained in the project for more information on 
+                Anjuta dependencies and building the plugin. 
+                If you want to disable remote gdb debugging,
+                please pass the <command>--diable-gdb-integration</command> switch when doing 
+                configure.
+            </para>
+                <section id="setting-up-the-anjuta-plugin">
+                <title>Setting Up the Anjuta Plug-in</title>
+                <para>
+                    Follow these steps to set up the plug-in:
+                    <orderedlist>
+                        <listitem>Extract the tarball for the toolchain into / as root. 
+                        The toolchain will be installed into <command>/opt/poky</command>.</listitem>
+                        <listitem>To use the plug-in, first open or create an existing project. 
+                        If you are creating a new project, the "C GTK+"
+                        project type will allow itself to be cross-compiled. 
+                        However you should be aware that this uses glade for the UI.</listitem>
+                        <listitem>To activate the plug-in go to Edit -> Preferences, then choose
+                        General from the left hand side. 
+                        Choose the Installed plug-ins tab, scroll down to Poky SDK and 
+                        check the box.</listitem>
+                    </orderedlist>
+                    The plug-in is now activated but not configured.  
+                    See the next section to learn how to configure it.
+                </para>
+                </section>
+                <section id="configuring-the-anjuta-plugin">
+                <title>Configuring the Anjuta Plugin</title>
+                <para>
+                    You can find the configuration options for the SDK by choosing the Poky 
+                    SDK icon from the left hand side. 
+                    You need to set the following options:
+                    <itemizedlist>
+                        <listitem>SDK root: If you use an external toolchain you need to set 
+                        SDK root. This is the root directory of the
+                        SDK's sysroot. 
+                        For an i586 SDK this will be <command>/opt/poky/</command>. 
+                        This directory will contain <command>bin</command>, <command>include
+                        </command>, <command>var</command> and so forth under your 
+                        selected target architecture subdirectory 
+                        <command>/opt/poky/sysroot/i586-poky-linux/</command>. 
+                        The cross comple tools you need are in 
+                        <command>/opt/poky/sysroot/i586-pokysdk-linux/</command>.</listitem>
+                        <listitem>Poky root: If you have a local poky build tree, you need to 
+                        set the Poky root. 
+                        This is the root directory of the poky build tree.
+                        If you build your i586 target architecture under the subdirectory of 
+                        <command>build_x86</command> within your poky tree, the Poky root directory
+                        should be <command>$&lt;poky_tree&gt;/build_x86/</command>.</listitem>
+                        <listitem>Target Architecture: This is the cross compile triplet, 
+                        for example, "i586-poky-linux". 
+                        This target triplet is the prefix extracted from the set up script file 
+                        name. 
+                        For example, "i586-poky-linux" is extracted from the
+                        set up script file 
+                        <command>/opt/poky/environment-setup-i586-poky-linux</command>.</listitem>
+                        <listitem>Kernel: Use the file chooser to select the kernel to use 
+                        with QEMU.</listitem>
+                        <listitem>Root filesystem: Use the file chooser to select the root 
+                        filesystem directory.  This directory is where you use the 
+                        <command>poky-extract-sdk</command> to extract the poky-image-sdk 
+                        tarball.</listitem>
+                     </itemizedlist>
+                </para>
+                </section>
+                <section id="using-the-anjuta-plug-in">
+                <title>Using the Anjuta Plug-in</title>
+                <para>
+                    This section uses an example that cross-compiles a project, deploys it into
+                    QEMU, runs a debugger against it and then does a system wide profile.
+                <orderedlist>
+                    <listitem>Choose Build -> Run Configure or Build -> Run Autogenerate to run
+                    "configure" or autogen, respectively for the project. 
+                    Either command passes command-line arguments to instruct the 
+                    cross-compile.</listitem>
+                    <listitem>Select Build -> Build Project to build and compile the project. 
+                    If you have previously built the project in the same tree without using 
+                    the cross-compiler you might find that your project fails to link. 
+                    If this is the case, simply select Build -> Clean Project to remove the 
+                    old binaries. 
+                    After you clean the project you can then try building it again.</listitem>
+                    <listitem>Start QEMU by selecting Tools -> Start QEMU.  This menu selection
+                    starts QEMU and will show any error messages in the message view. 
+                    Once Poky has fully booted within QEMU you can now deploy the project 
+                    into it.</listitem>
+                    <listitem>Once the project is built and you have QEMU running choose 
+                    Tools -> Deploy.  
+                    This selection installs the package into a temporary
+                    directory and then copies using rsync over SSH into the target. 
+                    Progress and messages appear in the message view.</listitem>
+                    <listitem>To debug a program installed onto the target choose 
+                    Tools -> Debug remote. 
+                    This selection prompts you for the local binary to debug and also the 
+                    command line to run on the target. 
+                    The command line to run should include the full path to the to binary 
+                    installed in the target. 
+                    This will start a gdbserver over SSH on the target and also an instance 
+                    of a cross-gdb in a local terminal. 
+                    This will be preloaded to connect to the server and use the SDK root to 
+                    find symbols. 
+                    This gdb will connect to the target and load in various libraries and the 
+                    target program. 
+                    You should setup any breakpoints or watchpoints now since you might not 
+                    be able to interrupt the execution later. 
+                    You can stop the debugger on the target using Tools -> Stop debugger.</listitem>
+                    <listitem>It is also possible to execute a command in the target over SSH, 
+                    the appropriate environment will be be set for the execution. 
+                    Choose Tools -> Run remote to do this. 
+                    This selection opens a terminal with the SSH command inside.</listitem>
+                    <listitem>To do a system wide profile against the system running in QEMU choose 
+                    Tools -> Profile remote. 
+                    This selection starts up OProfileUI with the appropriate parameters to 
+                    connect to the server running inside QEMU and also supplies the path 
+                    to the debug information necessary to get a useful profile.</listitem>
+                </orderedlist>
+                </para>
+                </section>
+            </section>
         </section>
 
-        <section id="platdev-appdev-external-anjuta-usage">
+        <section id="platdev-appdev-qemu">
-            <title>Using the Anjuta plugin</title>
-
-            <para>As an example, cross-compiling a project, deploying it into
-              QEMU and running a debugger against it and then doing a system
-              wide profile.</para>
-
-            <para>Choose <menuchoice><guimenu>Build</guimenu><guimenuitem>Run
-                  Configure</guimenuitem></menuchoice> or
-              <menuchoice><guimenu>Build</guimenu><guimenuitem>Run
-                  Autogenerate</guimenuitem></menuchoice> to run "configure"
-              (or to run "autogen") for the project. This passes command line
-              arguments to instruct it to cross-compile.</para>
-
-            <para>Next do
-              <menuchoice><guimenu>Build</guimenu><guimenuitem>Build
-                  Project</guimenuitem></menuchoice> to build and compile the
-              project. If you have previously built the project in the same
-              tree without using the cross-compiler you may find that your
-              project fails to link. Simply do
-              <menuchoice><guimenu>Build</guimenu><guimenuitem>Clean
-                  Project</guimenuitem></menuchoice> to remove the old
-              binaries. You may then try building again.</para>
-
-            <para>Next start QEMU by using
-              <menuchoice><guimenu>Tools</guimenu><guimenuitem>Start
-                  QEMU</guimenuitem></menuchoice>, this will start QEMU and
-              will show any error messages in the message view. Once Poky has
-              fully booted within QEMU you may now deploy into it.</para>
-
-            <para>Once built and QEMU is running, choose
-              <menuchoice><guimenu>Tools</guimenu><guimenuitem>Deploy</guimenuitem></menuchoice>,
-              this will install the package into a temporary directory and
-              then copy using rsync over SSH into the target.  Progress and
-              messages will be shown in the message view.</para>
-
-            <para>To debug a program installed into onto the target choose
-              <menuchoice><guimenu>Tools</guimenu><guimenuitem>Debug
-                  remote</guimenuitem></menuchoice>. This prompts for the
-              local binary to debug and also the command line to run on the
-              target. The command line to run should include the full path to
-              the to binary installed in the target. This will start a
-              gdbserver over SSH on the target and also an instance of a
-              cross-gdb in a local terminal. This will be preloaded to connect
-              to the server and use the <guilabel>SDK root</guilabel> to find
-              symbols. This gdb will connect to the target and load in
-              various libraries and the target program.  You should setup any
-              breakpoints or watchpoints now since you might not be able to
-              interrupt the execution later. You may stop
-              the debugger on the target using
-              <menuchoice><guimenu>Tools</guimenu><guimenuitem>Stop
-                  debugger</guimenuitem></menuchoice>.</para>
-
-            <para>It is also possible to execute a command in the target over
-              SSH, the appropriate environment will be be set for the
-              execution. Choose
-              <menuchoice><guimenu>Tools</guimenu><guimenuitem>Run
-                  remote</guimenuitem></menuchoice> to do this. This will open
-              a terminal with the SSH command inside.</para>
-
-            <para>To do a system wide profile against the system running in
-              QEMU choose
-              <menuchoice><guimenu>Tools</guimenu><guimenuitem>Profile
-                  remote</guimenuitem></menuchoice>. This will start up
-              OProfileUI with the appropriate parameters to connect to the
-              server running inside QEMU and will also supply the path to the
-              debug information necessary to get a useful profile.</para>
-
-        </section>
-    </section>
-
-    <section id="platdev-appdev-qemu">
         <title>Developing externally in QEMU</title>
         <para>
             Running Poky QEMU images is covered in the <link 
@@ -348,9 +527,9 @@ $ bitbake matchbox-desktop -c devshell
             environmental variables such as CC to assist applications, such as make,
             find the correct tools.
         </para>
-    </section>
+        </section>
 
-    <section id="platdev-appdev-srcrev">
+        <section id="platdev-appdev-srcrev">
         <title>Developing within Poky with an external SCM based package</title>
 
         <para>
@@ -369,8 +548,8 @@ $ bitbake matchbox-desktop -c devshell
             is the name of the package for which you want to enable automatic source 
             revision updating.
         </para>
+        </section>
     </section>
-</section>
 
 <section id="platdev-gdb-remotedebug">
     <title>Debugging with GDB Remotely</title>
@@ -458,8 +637,8 @@ $ bitbake matchbox-desktop -c devshell
                 A suitable gdb cross binary is required which runs on your host computer but
                 knows about the the ABI of the remote target. This can be obtained from
                 the the Poky toolchain, e.g. 
-                <filename>/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb</filename> 
+                <filename>/usr/local/poky/eabi-glibc/arm/bin/arm-poky-linux-gnueabi-gdb</filename> 
-                which "x86_64" is the host architecture, "arm" is the target architecture and "linux-gnueabi" the target ABI.
+                which "arm" is the target architecture and "linux-gnueabi" the target ABI.
             </para>
 
             <para>
@@ -467,8 +646,7 @@ $ bitbake matchbox-desktop -c devshell
                 the gdb-cross package so for example you would run:
                 <programlisting>bitbake gdb-cross</programlisting>
                 Once built, the cross gdb binary can be found at
-                <programlisting>tmp/sysroots/&lt;host-arch&gt;/usr/bin/\
+                <programlisting>tmp/sysroots/&lt;host-arch&lt;/usr/bin/&lt;target-abi&gt;-gdb </programlisting>
-&lt;target-arch&gt;-poky-&lt;target-abi&gt;/&lt;target-arch&gt;-poky-&lt;target-abi&gt;-gdb </programlisting>
             </para>
 
         </section>
@@ -505,17 +683,17 @@ $ bitbake matchbox-desktop -c devshell
                 by doing:
                 </para>
                 <programlisting>tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
-tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/opkg.conf -o \
+tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/temp/opkg.conf -o \
 tmp/rootfs/ update</programlisting>
                <para>
                 then,
                 </para>
                 <programlisting>tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
-tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/opkg.conf \
+tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/temp/opkg.conf \
 -o tmp/rootfs install foo
 
 tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
-tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/opkg.conf \
+tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/temp/opkg.conf \
 -o tmp/rootfs install foo-dbg</programlisting>
              <para>
                 which installs the debugging information too.
@@ -528,7 +706,7 @@ tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/opkg.conf \
             <para>
                 To launch the host GDB, run the cross gdb binary identified above with
                 the inferior binary specified on the commandline:
-                <programlisting>&lt;target-arch&gt;-poky-&lt;target-abi&gt;-gdb rootfs/usr/bin/foo</programlisting>
+                <programlisting>&lt;target-abi&gt;-gdb rootfs/usr/bin/foo</programlisting>
                 This loads the binary of program <emphasis>foo</emphasis>
                 as well as its debugging information. Once the gdb prompt
                 appears, you must instruct GDB to load all the libraries
@@ -650,10 +828,9 @@ $ opreport -cl
 
         <para>
             A graphical user interface for OProfile is also available. You can
-            either use prebuilt Debian packages from the <ulink
+            download and build it from svn at
-                url='http://debian.o-hand.com/'>OpenedHand repository</ulink> or
+            <ulink url="http://svn.o-hand.com/repos/oprofileui/trunk/"></ulink>. 
-            download and build from svn at
+            If the
-            http://svn.o-hand.com/repos/oprofileui/trunk/. If the
             "tools-profile" image feature is selected, all necessary binaries
             are installed onto the target device for OProfileUI interaction.
         </para>
@@ -819,6 +996,8 @@ $ opreport -cl
     </section>
 </section>
 
+
+
 </chapter> 
 <!-- 
 vim: expandtab tw=80 ts=4 

documentation/poky-ref-manual/extendpoky.xml

@@ -606,7 +606,7 @@ BBLAYERS = " \
 
           <para>
                Bitbake parses the conf/layer.conf of each of the layers in BBLAYERS
-               to add the layers packages, classes and configuration to Poky.
+               to add the recipes, classes and configuration contained within the layer to Poky.
                To create your own layer, independent of the main Poky repository,
                you need only create a directory with a conf/layer.conf file and
                add the directory to your bblayers.conf.
@@ -617,9 +617,9 @@ BBLAYERS = " \
                <literallayout class='monospaced'># We have a conf and classes directory, add to BBPATH
 BBPATH := "${BBPATH}:${LAYERDIR}"
 
-# We have a packages directory, add to BBFILES
+# We have a recipes directory containing both .bb and .bbappend files, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/packages/*/*.bb \
+BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \
-        ${LAYERDIR}/packages/*/*.bbappend"
+        ${LAYERDIR}/recipes/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "emenlow"
 BBFILE_PATTERN_emenlow := "^${LAYERDIR}/"

documentation/poky-ref-manual/introduction.xml

@@ -4,43 +4,39 @@
 <chapter id='intro'>
 <title>Introduction</title>
 
-<section id='intro-what-is'>
+<section id='intro-welcome'>
+    <title>Welcome to Poky!</title>
+
+    <para>
+        Poky is the the build tool in Yocto Project.
+        It is at the heart of Yocto Project.
+        You use Poky within Yocto Project to build the images (kernel software) for targeted hardware.
+    </para>
+
+    <para>
+        Before jumping into Poky you should have an understanding of Yokto Project.
+        Be sure you are familiar with the information in the Yocto Project Quick Start.
+        You can find this documentation on the public <ulink rul='http://yoctoproject.org/'>Yocto Project Website</ulink>.
+    </para>
+</section>
+
+<section>
     <title>What is Poky?</title>
 
     <para>
-
+        Poky provides an open source Linux, X11, Matchbox, GTK+, Pimlico, Clutter, and other <ulink url='http://gnome.org/mobile'>GNOME Mobile</ulink> technologies based full platform build tool within Yocto Project.
-        Poky is an open source platform build tool. It is a complete
+        It creates a focused, stable, subset of OpenEmbedded that can be easily and reliably built and developed upon.
-        software development environment for the creation of Linux
+        Poky fully supports a wide range of x86 ARM, MIPS and PowerPC hardware and device virtulisation.
-        devices. It aids the design, development, building, debugging,
-        simulation and testing of complete modern software stacks
-        using Linux, the X Window System and GNOME Mobile
-        based application frameworks. It is based on <ulink
-        url='http://openembedded.org/'>OpenEmbedded</ulink> but has
-        been customised with a particular focus.
-
     </para>
 
-    <para> Poky was setup to:</para>
-
-    <itemizedlist>
-        <listitem>
-            <para>Provide an open source Linux, X11, Matchbox, GTK+, Pimlico, Clutter, and other <ulink url='http://gnome.org/mobile'>GNOME Mobile</ulink> technologies based full platform build and development tool.</para>
-        </listitem>
-        <listitem>
-            <para>Create a focused, stable, subset of OpenEmbedded that can be easily and reliably built and developed upon.</para>
-        </listitem>
-        <listitem>
-            <para>Fully support a wide range of x86, ARM, MIPS, PowerPC hardware and device virtulisation</para>
-        </listitem>
-    </itemizedlist>
-
     <para>
         Poky is primarily a platform builder which generates filesystem images
         based on open source software such as the Kdrive X server, the Matchbox
         window manager, the GTK+ toolkit and the D-Bus message bus system. Images
         for many kinds of devices can be generated, however the standard example
-        machines target QEMU full system emulation(x86, ARM, MIPS and PowerPC) and the ARM based
+        machines target QEMU full system emulation(x86, ARM, MIPS and PowerPC) and
-        Sharp Zaurus series of devices. Poky's ability to boot inside a QEMU
+        real reference boards for each of these architectures.
+        Poky's ability to boot inside a QEMU
         emulator makes it particularly suitable as a test platform for development
         of embedded software.
     </para>
@@ -76,222 +72,32 @@
 
 <section id='intro-manualoverview'>
     <title>Documentation Overview</title>
-
     <para>
-        The handbook is split into sections covering different aspects of Poky. 
+        The Poky User Guide is split into sections covering different aspects of Poky. 
-        The <link linkend='usingpoky'>'Using Poky' section</link> gives an overview 
+        The <link linkend='usingpoky'>'Using Poky' section</link> gives an overview of the components that make up Poky followed by information about using Poky and debugging images created in Yocto Project. 
-        of the components that make up Poky followed by information about using and
+        The <link linkend='extendpoky'>'Extending Poky' section</link> gives information about how to extend and customise Poky along with advice on how to manage these changes. 
-        debugging the Poky build system. The <link linkend='extendpoky'>'Extending Poky' section</link> 
+        The <link linkend='platdev'>'Platform Development with Poky' section</link> gives information about interaction between Poky and target hardware for common platform development tasks such as software development, debugging and profiling. 
-        gives information about how to extend and customise Poky along with advice 
+        The rest of the manual consists of several reference sections each giving details on a specific section of Poky functionality.
-        on how to manage these changes.
-        The <link linkend='bsp'>'Board Support Packages (BSP) - Developers Guide' section</link>
-        gives information about how to develop BSP such as the common layout, the
-        software hardware configuration options etc.
-        The <link linkend='platdev'>'Platform Development with Poky' 
-        section</link> gives information about interaction between Poky and target
-        hardware for common platform development tasks such as software development, 
-        debugging and profiling. The rest of the manual
-        consists of several reference sections each giving details on a specific
-        section of Poky functionality.
     </para>
 
     <para>
         This manual applies to Poky Release 3.3 (Green).
     </para>
-
 </section>
 
 
 <section id='intro-requirements'>
     <title>System Requirements</title>
-
     <para>
         We recommend Debian-based distributions, in particular a recent Ubuntu 
         release (10.04 or newer), as the host system for Poky. Nothing in Poky is
-        distribution specific and
+        distribution specific and other distributions will most likely work as long 
-        other distributions will most likely work as long as the appropriate
+        as the appropriate prerequisites are installed - we know of Poky being used 
-        prerequisites are installed - we know of Poky being used successfully on Redhat,
+        successfully on Redhat, SUSE, Gentoo and Slackware host systems.
-        SUSE, Gentoo and Slackware host systems.
+        For information on what you need to develop images using Yocto Project and Poky 
+        you should see the Yocto Project Quick Start on the public 
+        <ulink rul='http://yoctoproject.org/'>Yocto Project Website</ulink>.
     </para>
-
-    <para>On a Debian-based system, you need the following packages installed:</para>
-
-    <itemizedlist>
-        <listitem>
-            <para>build-essential</para>
-        </listitem>
-        <listitem>
-            <para>python (version 2.6 or later)</para>
-        </listitem>
-        <listitem>
-            <para>diffstat</para>
-        </listitem>
-        <listitem>
-            <para>texinfo</para>
-        </listitem>
-        <listitem>
-            <para>texi2html</para>
-        </listitem>
-        <listitem>
-            <para>cvs</para>
-        </listitem>
-        <listitem>
-            <para>subversion</para>
-        </listitem>
-        <listitem>
-            <para>wget</para>
-        </listitem>
-        <listitem>
-            <para>gawk</para>
-        </listitem>
-        <listitem>
-            <para>help2man</para>
-        </listitem>
-        <listitem>
-            <para>chrpath</para>
-        </listitem>
-        <listitem>
-            <para>mercurial</para>
-        </listitem>
-    </itemizedlist>
-    <para>Furthermore if you wish to run an emulated Poky image using <ulink url='http://qemu.org'>QEMU</ulink> (as in the quickstart below) you will need the following packages installed:</para>
-    <itemizedlist>
-        <listitem>
-            <para>libgl1-mesa-dev</para>
-        </listitem>
-        <listitem>
-            <para>libglu1-mesa-dev</para>
-        </listitem>
-        <listitem>
-            <para>libsdl1.2-dev</para>
-        </listitem>
-        <listitem>
-            <para>bochsbios (only to run qemux86 images)</para>
-        </listitem>
-    </itemizedlist>
-
-    <para>
-        Debian users can add debian.o-hand.com to their APT sources (See
-        <ulink url='http://debian.o-hand.com'/>
-        for instructions on doing this) and then run <command>
-        "apt-get install qemu poky-depends poky-scripts"</command> which will
-        automatically install all these dependencies. Virtualisation images with 
-        Poky and all dependencies can also easily be built if required.
-    </para>
-
-    <para>
-        Poky can use a system provided QEMU or build its own depending on how it's
-        configured. See the options in <filename>local.conf</filename> for more details.
-    </para>
-</section>
-
-<section id='intro-quickstart'>
-    <title>Quick Start</title>
-
-    <section id='intro-quickstart-build'>
-        <title>Building and Running an Image</title>
-
-        <para>
-            If you want to try Poky, you can do so in a few commands. The example below
-            checks out the Poky source code, sets up a build environment, builds an
-            image and then runs that image under the QEMU emulator in x86 system emulation mode:
-        </para>
-
-        <para>
-            <literallayout class='monospaced'>
-$ wget http://pokylinux.org/releases/poky-green-3.3.tar.bz2
-$ tar xjvf poky-green-3.3.tar.bz2
-$ cd green-3.3/
-$ source poky-init-build-env
-$ bitbake poky-image-sato
-$ bitbake qemu-native
-$ runqemu qemux86
-</literallayout>
-        </para>
-
-        <note>
-        <para>
-            This process will need Internet access, about 20 GB of disk space
-            available, and you should expect the build to take about 4 - 5 hours since
-            it is building an entire Linux system from source including the toolchain!
-        </para>
-        </note>
-
-        <para>
-            To build for other machines see the <glossterm><link
-                    linkend='var-MACHINE'>MACHINE</link></glossterm> variable in build/conf/local.conf.
-            This file contains other useful configuration information and the default version
-            has examples of common setup needs and is worth 
-            reading. To take advantage of multiple processor cores to speed up builds for example, set the 
-            <glossterm><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></glossterm>
-            and <glossterm><link linkend='var-PARALLEL_MAKE'>PARALLEL_MAKE</link></glossterm> variables.
-
-            The images/kernels built by Poky are placed in the <filename class="directory">tmp/deploy/images</filename>
-            directory.
-        </para>
-
-        <para>
-            You could also run <command>"poky-qemu zImage-qemuarm.bin poky-image-sato-qemuarm.ext2"
-            </command> within the images directory if you have the poky-scripts Debian package
-            installed from debian.o-hand.com. This allows the QEMU images to be used standalone
-            outside the Poky build environment.
-        </para>
-        <para>
-            To setup networking within QEMU see the <link linkend='usingpoky-install-qemu-networking'>
-            QEMU/USB networking with IP masquerading</link> section.
-        </para>
-
-    </section>
-    <section id='intro-quickstart-qemu'>
-        <title>Downloading and Using Prebuilt Images</title>
-
-        <para>
-            Prebuilt images from Poky are also available if you just want to run the system
-            under QEMU. To use these you need to:
-        </para>
-
-        <itemizedlist>
-            <listitem>
-                <para>
-                     Add debian.o-hand.com to your APT sources (See
-                    <ulink url='http://debian.o-hand.com'/> for instructions on doing this)
-                </para>
-            </listitem>
-            <listitem>
-                <para>Install patched QEMU and poky-scripts:</para>
-                <para>
-                    <literallayout class='monospaced'>
-$ apt-get install qemu poky-scripts
-</literallayout>
-                </para>
-            </listitem>
-
-            <listitem>
-                <para>
-                    Download a Poky QEMU release kernel (*zImage*qemu*.bin) and compressed
-                    filesystem image (poky-image-*-qemu*.ext2.bz2) which
-                    you'll need to decompress with 'bzip2 -d'. These are available from the
-                    <ulink url='http://pokylinux.org/releases/green-3.3/'>last release</ulink>
-                    or from the <ulink url='http://autobuilder.pokylinux.org/'>autobuilder</ulink>.
-                </para>
-            </listitem>
-            <listitem>
-                <para>Start the image:</para>
-                <para>
-                    <literallayout class='monospaced'>
-$ poky-qemu &lt;kernel&gt; &lt;image&gt;
-</literallayout>
-                </para>
-            </listitem>
-        </itemizedlist>
-
-        <note><para>
-            A patched version of QEMU is required at present. A suitable version is available from 
-            <ulink url='http://debian.o-hand.com'/>, it can be built 
-            by poky (bitbake qemu-native) or can be downloaded/built as part of the toolchain/SDK tarballs.
-        </para></note>
-
-    </section>
 </section>
 
 <section id='intro-getit'>

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

@@ -6,10 +6,10 @@
       xmlns="http://docbook.org/ns/docbook"
       >
     <bookinfo>
-
+ 
         <mediaobject>
             <imageobject>
-                <imagedata fileref='poky-ref-manual.png' 
+                <imagedata fileref='figures/poky-ref-manual.png' 
                     format='SVG' 
                     align='center' scalefit='1' width='100%'/>
             </imageobject>    
@@ -17,7 +17,6 @@
 
         <title>Poky Reference Manual</title>
         <subtitle>A Guide and Reference to Poky</subtitle>
-
         <authorgroup>
             <author>
                 <firstname>Richard</firstname> <surname>Purdie</surname>
@@ -44,15 +43,15 @@
 
         <revhistory>
             <revision>
-                <revnumber>3.3+git</revnumber>
+                <revnumber>4.0+git</revnumber>
-                <date>20 Sept 2010</date>
+                <date>27 Oct 2010</date>
                 <revremark>Poky Master Documentation</revremark>
             </revision>
         </revhistory>
 
     <copyright>
       <year>2007-2010</year>
-      <holder>Intel Corporation</holder>
+      <holder>Linux Foundation</holder>
     </copyright>
 
     <legalnotice>

documentation/poky-ref-manual/style.css

@@ -118,14 +118,13 @@ h6 {
   background-color: transparent;
   background-repeat: no-repeat;
   padding-top: 256px;
-  background-image: url("poky-beaver.png");
+  background-image: url("figures/poky-ref-manual.png");
-  background-position: right top;
+  background-position: left top;
-  float: right; 
   margin-top: -256px;
   padding-right: 50px;
   margin-left: 50px;
   text-align: right;
-  width: 200px;
+  width: 600px;
 }
 
 h3.author {

documentation/yocto-project-qs/Makefile

@@ -0,0 +1,32 @@
+XSLTOPTS = --stringparam html.stylesheet style.css \
+         --xinclude
+
+XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
+XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
+
+all: html tarball
+
+##
+# These URI should be rewritten by your distribution's xml catalog to
+# match your localy installed XSL stylesheets.
+
+html:
+#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html 
+
+#	xsltproc $(XSLTOPTS) -o yocto-project-qs.html $(XSL_XHTML_URI) yocto-project-qs.xml
+	xsltproc $(XSLTOPTS) -o yocto-project-qs.html yocto-project-qs-customization.xsl yocto-project-qs.xml
+
+tarball: html
+	tar -cvzf yocto-project-qs.tgz yocto-project-qs.html style.css figures/yocto-environment.png figures/building-an-image.png figures/using-a-pre-built-image.png figures/yocto-project-transp.png
+
+validate:
+	xmllint --postvalid --xinclude --noout yocto-project-qs.xml
+
+OUTPUTS = yocto-project-qs.tgz yocto-project-qs.html
+SOURCES = *.png *.xml *.css
+
+publish:
+	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
+
+clean:
+	rm -f $(OUTPUTS)

documentation/yocto-project-qs/style.css

@@ -0,0 +1,963 @@
+/* 
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+   
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+	  Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+ 
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color:#999999;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: normal;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: normal;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: normal;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110.000%;
+  border-bottom: 1px solid black;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 80%;
+  font-weight: normal;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("../figures/yocto-project-bw.png");
+  background-position: top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 50px;
+  text-align: center;
+  width: 600px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+  color: black; font-size: 100%;
+  
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+} 
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption, 
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;  
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+  
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #aaa;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #aaa;
+}
+
+
+.warning {
+  background-color: #fea;
+}
+
+.caution {
+  background-color: #fea;
+}
+
+.tip {
+  background-color: #eff;
+}
+
+.note {
+  background-color: #dfc;
+}
+
+.glossary dl dt, 
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title, 
+div.colophon .title, 
+div.chapter .titlepage .title,
+div.article .titlepage .title 
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-image: url("figures/yocto-project-bw.png");
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #91ae35;
+   color: #fff;   
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #fff;   
+}
+
+.tip a,
+.note a {
+   color: #fff;   
+   text-decoration: underline;
+}

documentation/yocto-project-qs/yocto-project-qs-customization.xsl

@@ -0,0 +1,8 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+  
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+
+  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>
+
+</xsl:stylesheet>

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

@@ -0,0 +1,365 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<article id='intro'>
+   <imagedata fileref="figures/yocto-project-transp.png" width="6in" depth="1in" align="right" scale="25" />
+
+<section id='fake-title'>
+    <title>Yocto Project Quick Start</title>
+</section>
+
+<section id='welcome'>
+    <title>Welcome!</title>
+    <para>
+        Welcome to the Yocto Project!  
+        The Yocto Project (YP) is an open-source collaboration project focused on embedded Linux
+        developers.
+        Amongst other things, YP uses the Poky build tool to construct complete Linux images.
+    </para>
+    <para>
+        This short document will give you some basic information about the environment as well 
+        as 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.  
+        This document steps you through a simple example showing you how to build a small image 
+        and run it using the QEMU emulator.
+    </para>
+    <para>
+        For complete information on the Yocto Project you should check out the 
+        <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>.
+        You can find the latest builds, breaking news, full development documentation, and a 
+        rich Yocto Project Development Community into which you can tap.
+    </para>
+</section>
+
+<section id='yp-intro'>
+    <title>Introducing the Yocto Project Development Environment</title>
+    <para>
+        The Yocto Project through the Poky build tool provides an open source development 
+        environment targeting the ARM, MIPS, PowerPC and x86 architectures for a variety of 
+        platforms including x86-64 and emulated ones.
+        You can use components from the the Yocto Project to design, develop, build, debug, simulate,
+        and test the complete software stack using Linux, the X Window System, GNOME Mobile-based
+        application frameworks, and Qt frameworks.
+    </para>
+
+    <para></para>
+    <para></para>
+
+    <mediaobject>
+        <imageobject>
+            <imagedata fileref="figures/yocto-environment.png" 
+                format="PNG" align='center' scalefit='1' width="100%"/>
+        </imageobject>
+        <caption>
+            <para>The Yocto Project Development Environment</para>
+        </caption>
+     </mediaobject>
+
+    <para>
+        Yocto Project:
+    </para>
+
+    <itemizedlist>
+        <listitem>
+            <para>Provides a recent Linux kernel along with a set of system commands and libraries suitable for the embedded environment.</para>
+        </listitem>
+        <listitem>
+            <para>Makes available system components such as X11, Matchbox, GTK+, Pimlico, Clutter,
+            GuPNP and Qt (among others) so you can create a richer user interface experience on 
+            devices that use displays or have a GUI.
+            For devices that don't have a GUI or display you simply would not employ these 
+            components.</para>
+        </listitem>
+        <listitem>
+            <para>Creates a focused and stable core compatible with the OpenEmbedded 
+            project with which you can easily and reliably build and develop.</para>
+        </listitem>
+        <listitem>
+            <para>Fully supports a wide range of hardware and device emulation through the QEMU
+            Emulator.</para>
+        </listitem>
+    </itemizedlist>
+
+    <para>
+        Yocto Project can generate images for many kinds of devices.  
+        However, the standard example machines target QEMU full system emulation for x86, ARM, MIPS,
+        and PPC based architectures as well as specific hardware such as the Intel Desktop Board
+        DH55TC.  
+        Because an image developed with Yocto Project can boot inside a QEMU emulator, the 
+        development environment works nicely as a test platform for developing embedded software.
+    </para>
+
+    <para>
+        Another important Yocto Project feature is the Sato reference User Interface. 
+        This optional GNOME mobile-based UI, which is intended for devices with
+        resolution but restricted size screens, sits neatly on top of a device using the 
+        GNOME Mobile Stack providing a well defined user experience. 
+        Implemented in its own layer, it makes it clear to developers how they can implement 
+        their own UIs on top of Yocto Linux.
+    </para>
+</section>
+
+<section id='resources'>
+    <title>What You Need and How You Get It</title>
+
+    <para>
+        You need these things to develop in the Yocto Project environment:
+    </para>
+
+    <itemizedlist>
+        <listitem>
+            <para>A host system running a supported Linux distribution (i.e. recent releases of
+                Fedora, OpenSUSE, Debian, and Ubuntu).</para>
+        </listitem>
+        <listitem>
+            <para>The right packages.</para>
+        </listitem>
+        <listitem>
+            <para>A release of Yocto Project.</para>
+        </listitem>
+    </itemizedlist>
+
+    <section id='the-linux-distro'>
+        <title>The Linux Distribution</title>
+
+        <para>
+            This document assumes you are running a reasonably current Linux-based host system. 
+            The examples work for both Debian-based and RPM-based distributions.
+        </para>
+    </section>
+
+    <section id='packages'>
+        <title>The Packages</title>
+
+        <para>
+            The packages you need for a Debian-based host are shown in the following command:
+        </para>
+
+            <literallayout class='monospaced'>
+     $ sudo apt-get install sed wget cvs subversion git-core coreutils \
+     unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
+     python-pysqlite2 diffstat help2man make gcc build-essential \
+     g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
+     mercurial
+            </literallayout>
+
+        <para>
+            The packages you need for an RPM-based host like Fedora are shown in these commands:
+        </para>
+
+            <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 \
+     docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
+     docbook-utils sed bc glibc-devel ccache pcre pcre-devel quilt \
+     groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
+     perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
+     SDL-devel mesa-libGL-devel mesa-libGLU-devel
+            </literallayout>
+ 
+       <para>
+            <emphasis>NOTE:</emphasis>  Packages vary in number and name for other Linux distributions.  
+            The commands here should work.  We are interested, though, to learn what works for you.
+            You can find more information for package requirements on common Linux distributions 
+            at <ulink url="http://wiki.openembedded.net/index.php/OEandYourDistro"></ulink>.
+            However, you should be careful when using this information as the information applies
+            to old Linux distributions that are known to not work with a current Poky install.
+        </para>
+    </section>
+
+    <section id='releases'>
+        <title>Yocto Project Release</title>
+            
+        <para>
+            The latest release images for the Yocto Project are kept at 
+            <ulink url="http://yoctoproject.org/downloads/yoctolinux-0.9/"></ulink>.
+            Nightly and developmental builds are also maintained.  However, for this 
+            document a released version of Yocto Project is used.
+        </para>
+    </section>
+</section>
+
+<section id='test-run'>
+    <title>A Quick Test Run</title>
+
+    <para>
+        Now that you have your system requirements in order you can give Yocto Project a try.  
+        This section presents some steps that let you do the following:
+    </para>
+
+    <itemizedlist>
+        <listitem>
+            <para>Build an image and run it in the emulator</para>
+        </listitem>
+        <listitem>
+            <para>Or, use a pre-built image and run it in the emulator</para>
+        </listitem>
+    </itemizedlist>
+
+    <section id='building-image'>
+        <title>Building an Image</title>
+ 
+        <para>
+            In the development environment you will need to build an image whenever you change hardware support, add or change system libraries, or add or change services that have dependencies.
+        </para>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref="figures/building-an-image.png" format="PNG" align='center' scalefit='1'/>
+            </imageobject>
+            <caption>
+                <para>Building an Image</para>
+            </caption>
+         </mediaobject>
+
+         <para>
+             Use the following commands from a shell on your Debian-based host to build your image.  
+             The build creates an entire Linux system including the Toolchain from the source.
+         </para>
+
+         <para><emphasis>NOTE:</emphasis>  The build process using Sato currently consumes 
+             50GB of disk space.
+             To allow for variations in the build process and for future package expansion we 
+             recommend 100GB of free disk space.
+         </para>
+
+         <para>
+             <literallayout class='monospaced'>
+     $ wget http://www.yoctoproject.org/downloads/poky/poky-laverne-4.0.tar.bz2
+     $ tar xjf poky-laverne-4.0.tar.bz2
+     $ source poky-4.0/poky-init-build-env poky-4.0-build
+             </literallayout>
+         </para>
+         <itemizedlist>
+             <listitem><para>The first two commands extract the Yocto Project files from the 
+             release area and place them into a subdirectory of your current directory 
+             (<command>poky-4.0-build</command> in this example).</para></listitem>
+             <listitem><para>The <command>$ source</command> command creates the directory and places 
+             you there.  
+             The build directory contains all the object files used during the build.   
+             The default build directory is <command>poky-4.0-build</command>.  
+             Note that you can change the target architecture by editing the 
+             <command>&lt;build_directory&gt;/conf/local.conf</command> file. 
+             By default the target architecture is qemux86.</para></listitem>
+         </itemizedlist>
+         <para>
+             Now might be a good time to edit the <command>conf/local.conf</command>
+             file.  
+             The defaults should all be fine.  However, you might want to look at the variables
+             BB_NUMBER_THREADS and PARALLEL_MAKE.
+             By default, these variables are commented out.
+         </para>
+         <para>
+             Continue with the following command to build the OS image for the target, which is 
+             poky-image-sato in this example.
+             <literallayout class='monospaced'>
+     $ bitbake poky-image-sato
+             </literallayout>
+             <emphasis>NOTE:</emphasis>  If you are running Fedora 14 or another distribution 
+             with GNU make 3.82 you might have to run the following two 
+             <command>$bitbake</command> commands instead:
+             <literallayout class='monospaced'>
+     $ bitbake make-native
+     $ bitbake poky-image-sato
+             </literallayout>
+             The final command runs the image:
+             <literallayout class='monospaced'>
+     $ poky-qemu qemux86
+             </literallayout>
+             The build process could take several hours the first time you run it. 
+             Depending on the number of processor and cores, the amount or RAM, the speed of your
+             internet connection and other factors.
+             After the initial build, subsequent builds run much faster.
+         </para>
+    </section>
+
+    <section id='using-pre-built'>
+        <title>Using a Pre-Built Binaries and QEMU</title>
+        <para>
+            If hardware, libraries and services are stable you can use a pre-built image of the image, kernel and toolchain and just run it on the target using the emulator QEMU.  
+            This situation is perfect for developing application software.
+        </para>
+
+        <para></para>
+        <para></para>
+        <para></para>
+
+        <mediaobject>
+            <imageobject>
+            <imagedata fileref="figures/using-a-pre-built-image.png" format="PNG" align='center' scalefit='1'/>
+            </imageobject>
+            <caption>
+                <para>Using a Pre-Built Image</para>
+            </caption>
+         </mediaobject>
+
+         <para>
+             For this scenario you need to do three things:
+         </para>
+
+         <itemizedlist>
+             <listitem>
+                 <para>
+                     Install the standalone Yocto toolchain tarball
+                 </para>
+             </listitem>
+             <listitem>
+                 <para>
+                     Download the pre-built kernel that will run on QEMU.  
+                     You need to be sure to get the QEMU image that matches your target machine’s architecture (e.g. x86, ARM, etc.).
+                 </para>
+             </listitem>
+             <listitem>
+                 <para>
+                     Download and decompress the file image system.
+                 </para>
+             </listitem>
+         </itemizedlist>
+
+         <para>
+             You can download the pre-built toolchain which includes the poky-qemu script and support files from <ulink url='http://yoctoproject.org/downloads/yoctolinux-0.9/toolchain/'></ulink>.  These are available for i586 (32-bit) and x86_64 (64 bit) host machines, targeting each of the 5 supported target architectures. The tarballs are self contained and install into /opt/poky.
+             Use these commands to install the toolchain tarball (taking the 64 bit host, 32 bit i586 target as an example):
+         </para>
+
+         <para>
+             <literallayout class='monospaced'>
+     $ cd /
+     $ sudo tar -xvjf yoctolinux-eglibc-x86_64-i586-toolchain-sdk-0.9.tar.bz2
+             </literallayout>
+         </para>
+
+         <para>
+             You can download the pre-built Linux kernel and the file image system from <ulink url='http://yoctoproject.org/downloads/yoctolinux-0.9/'></ulink>.  
+             The kernel and file image system have the following forms, respectively:
+         </para>
+
+          <literallayout class='monospaced'>
+     *zImage*qemu*.bin
+     poky-image-*-qemu*.ext2.bz2
+          </literallayout>
+
+         <para>
+             You must decompress the file image system using the following command:
+         </para>
+
+         <literallayout class='monospaced'>
+     $ bzip2 -d
+         </literallayout>
+
+         <para>
+             You can now start the emulator using these commands (assuming an 32 bit i586 target):
+         </para>
+
+         <literallayout class='monospaced'>
+     $ source /opt/poky/environment-setup-i586-poky-linux 
+     $ poky-qemu &lt;<emphasis>kernel</emphasis>&gt; &lt;<emphasis>image</emphasis>&gt;
+         </literallayout>
+    </section>
+</section>
+
+</article>
+<!--
+vim: expandtab tw=80 ts=4
+-->

meta/classes/base.bbclass

@@ -135,7 +135,6 @@ python base_do_setscene () {
 		bb.build.make_stamp("do_setscene", d)
 }
 do_setscene[selfstamp] = "1"
-do_setscene[dirs] = "${PSEUDO_LOCALSTATEDIR}"
 addtask setscene before do_fetch
 
 addtask fetch
@@ -438,6 +437,9 @@ base_do_package() {
 addtask build after do_populate_sysroot
 do_build = ""
 do_build[func] = "1"
+do_build () {
+	:
+}
 
 python () {
     import exceptions, string
@@ -483,6 +485,7 @@ python () {
         deps.append('virtual/fakeroot-native:do_populate_sysroot')
         bb.data.setVarFlag('do_package', 'depends', " ".join(deps),d)
         bb.data.setVarFlag('do_package', 'fakeroot', 1, d)
+        bb.data.setVarFlag('do_package_setscene', 'fakeroot', 1, d)
     source_mirror_fetch = bb.data.getVar('SOURCE_MIRROR_FETCH', d, 0)
     if not source_mirror_fetch:
         need_host = bb.data.getVar('COMPATIBLE_HOST', d, 1)
@@ -621,4 +624,32 @@ def check_gcc3(data):
 	
 	return False
 
+addtask cleanall after do_clean
+python do_cleanall() {
+        sstate_clean_cachefiles(d)
+
+	localdata = bb.data.createCopy(d)
+	bb.data.update_data(localdata)
+
+	dl_dir = bb.data.getVar('DL_DIR', localdata, True)
+	dl_dir = os.path.realpath(dl_dir)
+
+	src_uri = bb.data.getVar('SRC_URI', localdata, True)
+	if not src_uri:
+		return
+	for url in src_uri.split():
+		try:
+			local = bb.data.expand(bb.fetch.localpath(url, localdata), localdata)
+		except bb.MalformedUrl, e:
+			raise FuncFailed('Unable to generate local path for malformed uri: %s' % e)
+		if local is None:
+			continue
+		local = os.path.realpath(local)
+                if local.startswith(dl_dir):
+			bb.note("Removing %s*" % local)
+			oe.path.remove(local + "*")
+}
+do_cleanall[nostamp] = "1"
+
+
 EXPORT_FUNCTIONS do_setscene do_fetch do_unpack do_configure do_compile do_install do_package

meta/classes/metadata_scm.bbclass

@@ -70,8 +70,11 @@ def base_get_metadata_git_branch(path, d):
 	return "<unknown>"
 
 def base_get_metadata_git_revision(path, d):
-	rev = os.popen("cd %s; git log -n 1 --pretty=oneline -- 2>&1" % path).read().split(" ")[0]
+	f = os.popen("cd %s; git log -n 1 --pretty=oneline -- 2>&1" % path)
-	if len(rev) != 0:
+	data = f.read()
-		return rev
+	if f.close() is None:        
+		rev = data.split(" ")[0]
+		if len(rev) != 0:
+			return rev
 	return "<unknown>"
 

meta/classes/package_deb.bbclass

@@ -280,7 +280,6 @@ python () {
         deps.append('dpkg-native:do_populate_sysroot')
         deps.append('virtual/fakeroot-native:do_populate_sysroot')
         bb.data.setVarFlag('do_package_write_deb', 'depends', " ".join(deps), d)
-        bb.data.setVarFlag('do_package_write_ipk', 'fakeroot', "1", d)
 }
 
 python do_package_write_deb () {

meta/classes/package_ipk.bbclass

@@ -325,6 +325,7 @@ python () {
         deps.append('virtual/fakeroot-native:do_populate_sysroot')
         bb.data.setVarFlag('do_package_write_ipk', 'depends', " ".join(deps), d)
         bb.data.setVarFlag('do_package_write_ipk', 'fakeroot', "1", d)
+        bb.data.setVarFlag('do_package_write_ipk_setscene', 'fakeroot', "1", d)
 }
 
 python do_package_write_ipk () {

meta/classes/package_rpm.bbclass

@@ -437,18 +437,13 @@ python do_package_rpm () {
 
 	workdir = bb.data.getVar('WORKDIR', d, True)
 	outdir = bb.data.getVar('DEPLOY_DIR_IPK', d, True)
-	dvar = bb.data.getVar('D', d, True)
 	tmpdir = bb.data.getVar('TMPDIR', d, True)
 	pkgd = bb.data.getVar('PKGD', d, True)
 	pkgdest = bb.data.getVar('PKGDEST', d, True)
-	if not workdir or not outdir or not dvar or not tmpdir:
+	if not workdir or not outdir or not pkgd or not tmpdir:
 		bb.error("Variables incorrectly set, unable to package")
 		return
 
-	if not os.path.exists(dvar):
-		bb.debug(1, "Nothing installed, nothing to do")
-		return
-
 	packages = bb.data.getVar('PACKAGES', d, True)
 	if not packages or packages == '':
 		bb.debug(1, "No packages; nothing to do")
@@ -550,6 +545,7 @@ python () {
         deps.append('virtual/fakeroot-native:do_populate_sysroot')
         bb.data.setVarFlag('do_package_write_rpm', 'depends', " ".join(deps), d)
         bb.data.setVarFlag('do_package_write_rpm', 'fakeroot', 1, d)
+        bb.data.setVarFlag('do_package_write_rpm_setscene', 'fakeroot', 1, d)
 }
 
 SSTATETASKS += "do_package_write_rpm"

meta/classes/rm_work.bbclass

@@ -11,7 +11,9 @@ BB_DEFAULT_TASK = "rm_work_all"
 
 do_rm_work () {
     # Ensure pseudo is no longer active
-    ${FAKEROOT} -S
+    if [ -d ${WORKDIR}/pseudo ]; then
+        ${FAKEROOT} -S
+    fi
     cd ${WORKDIR}
     for dir in *
     do

meta/classes/sstate.bbclass

@@ -44,11 +44,12 @@ def sstate_init(name, d):
     ss['lockfiles'] = []
     return ss
 
-def sstate_state_fromvars(d):
+def sstate_state_fromvars(d, task = None):
-    task = bb.data.getVar('BB_CURRENTTASK', d, True)
+    if task is None:
-    if not task:
+        task = bb.data.getVar('BB_CURRENTTASK', d, True)
-        bb.fatal("sstate code running without task context?!")
+        if not task:
-    task = task.replace("_setscene", "")
+            bb.fatal("sstate code running without task context?!")
+        task = task.replace("_setscene", "")
 
     name = bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-name', d), d)
     inputs = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-inputdirs', d) or "", d)).split()
@@ -153,11 +154,25 @@ def sstate_installpkg(ss, d):
     sstate_install(ss, d)
 
     for plain in ss['plaindirs']:
-        bb.mkdirhier(sstateinst + plain)
+        workdir = d.getVar('WORKDIR', True)
-        oe.path.copytree(sstateinst + plain, bb.data.getVar('WORKDIR', d, True) + plain)
+        src = sstateinst + "/" + plain.replace(workdir, '')
+        dest = plain
+        bb.mkdirhier(src)
+        bb.mkdirhier(dest)
+        oe.path.copytree(src, dest)
 
     return True
 
+def sstate_clean_cachefile(ss, d):
+    sstatepkg = bb.data.getVar('SSTATE_PKG', d, True) + '_' + ss['name'] + ".tgz"
+    bb.note("Removing %s" % sstatepkg)
+    oe.path.remove(sstatepkg)
+
+def sstate_clean_cachefiles(d):
+    for task in (bb.data.getVar('SSTATETASKS', d, True) or "").split():
+        ss = sstate_state_fromvars(d, task[3:])
+        sstate_clean_cachefile(ss, d)
+
 def sstate_clean_manifest(manifest, d):
     import oe.path
 
@@ -263,6 +278,9 @@ def pstaging_fetch(sstatepkg, d):
 
         dldir = bb.data.expand("${SSTATE_DIR}", localdata)
         srcuri = "file://" + os.path.basename(sstatepkg)
+
+        bb.mkdirhier(dldir)
+
         bb.data.setVar('DL_DIR', dldir, localdata)
         bb.data.setVar('PREMIRRORS', mirrors, localdata)
         bb.data.setVar('SRC_URI', srcuri, localdata)
@@ -270,8 +288,12 @@ def pstaging_fetch(sstatepkg, d):
         # Try a fetch from the sstate mirror, if it fails just return and
         # we will build the package
         try:
-            bb.fetch.init([srcuri], pd)
+            bb.fetch.init([srcuri], localdata)
-            bb.fetch.go(pd, [srcuri])
+            bb.fetch.go(localdata, [srcuri])
+            # Need to optimise this, if using file:// urls, the fetcher just changes the local path
+            # For now work around by symlinking
+            if bb.data.expand(bb.fetch.localpath(srcuri, localdata), localdata) != sstatepkg:
+                os.symlink(bb.data.expand(bb.fetch.localpath(srcuri, localdata), localdata), sstatepkg)
         except:
             pass
 
@@ -362,10 +384,10 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn, d):
 
             srcuri = "file://" + os.path.basename(sstatefile)
             bb.data.setVar('SRC_URI', srcuri, localdata)
-            bb.note(str(srcuri))
+            #bb.note(str(srcuri))
 
             try:
-                bb.fetch.init(srcuri.split(), d)
+                bb.fetch.init(srcuri.split(), localdata)
                 bb.fetch.checkstatus(localdata)
                 ret.append(task)
             except:

meta/conf/bitbake.conf

@@ -171,7 +171,7 @@ DESCRIPTION_${PN}-dbg ?= "${SUMMARY_${PN}-dbg}"
 DESCRIPTION_${PN}-dev ?= "${SUMMARY_${PN}-dev}"
 DESCRIPTION_${PN}-doc ?= "${SUMMARY_${PN}-doc}"
 LICENSE = "INVALID"
-MAINTAINER = "Poky Team <poky@openedhand.com>"
+MAINTAINER = "Yocto Project Team <poky@yoctoproject.org>"
 HOMEPAGE = "unknown"
 
 # Package dependencies and provides.
@@ -546,6 +546,7 @@ SRC_URI = "file://${FILE}"
 PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/"
 FAKEROOT = "PSEUDO_PREFIX=${STAGING_DIR_NATIVE}${prefix_native} PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_NOSYMLINKEXP=1 pseudo"
 FAKEROOTENV = "PSEUDO_PREFIX=${STAGING_DIR_NATIVE}${prefix_native} PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_NOSYMLINKEXP=1 LD_PRELOAD=libpseudo.so LD_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE}/pseudo/lib64:${STAGING_LIBDIR_NATIVE}/pseudo/lib"
+FAKEROOTDIRS = "${PSEUDO_LOCALSTATEDIR}"
 PREFERRED_PROVIDER_virtual/fakeroot-native ?= "pseudo-native"
 
 

meta/conf/distro/poky.conf

@@ -1,11 +1,11 @@
 #@TYPE: Distribution#@NAME: Poky
-#@DESCRIPTION: Distribution configuration for OpenedHand (Poky)
+#@DESCRIPTION: Distribution configuration for the Yocto Project build by Poky
 
 DISTRO = "poky"
-DISTRO_NAME = "OpenedHand Linux (Poky)"
+DISTRO_NAME = "Yocto Linux (Built by Poky 4.0)"
-DISTRO_VERSION = "3.3+snapshot-${DATE}"
+DISTRO_VERSION = "0.9"
 
-MAINTAINER = "Poky <poky@openedhand.com>"
+MAINTAINER = "Poky <poky@yoctoproject.org>"
 
 USER_CLASSES ?= ""
 

meta/conf/local.conf.sample

@@ -159,3 +159,8 @@ ENABLE_BINARY_LOCALE_GENERATION = "1"
 # wish to perform the time-consuming step of generating all LIBC locales.
 # WARNING: this may break localisation!
 #GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8"
+
+# Default to not build 32 bit libs on 64 bit systems, comment this
+# out if that is desired
+NO32LIBS = "1"
+

meta/conf/machine/mpc8315e-rdb.conf

@@ -2,7 +2,7 @@
 #@DESCRIPTION: Machine configuration for running 
 
 TARGET_ARCH = "powerpc"
-PACKAGE_EXTRA_ARCHS = "ppce300"
+PACKAGE_EXTRA_ARCHS = "ppc603e"
 TARGET_FPU = "spe"
 
 require conf/machine/include/tune-ppc603e.inc

meta/recipes-multimedia/libtheora/libtheora_1.1.1.bb

@@ -4,7 +4,9 @@ BUGTRACKER = "https://trac.xiph.org/newticket"
 SECTION = "libs"
 LICENSE = "BSD"
 
-PR = "r0"
+DEPENDS = "libogg"
+
+PR = "r1"
 
 SRC_URI = "http://downloads.xiph.org/releases/theora/libtheora-${PV}.tar.bz2 \
            file://no-docs.patch"