documentation/poky-ref-manual/extendpoky.xml: removed pokylinux.org link

There was a link whose URL was http://autobuilder.pokylinux.org:8010.
I changed the link to use yoctoproject.org.  Note that this URL
was not visible to the reader in the manual.  However, it was there
in the DocBook code.

(From yocto-docs rev: ca1cf9fb404f148fe4f0868630dc4f109231c5c3)

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

README.hardware

@@ -149,15 +149,26 @@ The Beagleboard is an ARM Cortex-A8 development board with USB, DVI-D, S-Video,
 faster CPU, more RAM, an ethernet port, more USB ports, microSD, and removes
 the NAND flash. The beagleboard MACHINE is tested on the following platforms:
 
-  o Beagleboard xM
+  o Beagleboard C4
+  o Beagleboard xM Rev A
 
-TODO: need someone with a Beagleboard C4 to verify these instructions.
+The Beagleboard C4 has NAND, while the xM does not. For the sake of simplicity,
+these instructions assume you have erased the NAND on the C4 so its boot
+behavior matches that of the xM. To do this, issue the following commands from
+the u-boot prompt (note that the unlock may be unecessary depending on the
+version of u-boot installed on your board and only one of the erase commands
+will succeed):
 
-Due to the lack of NAND on the xM, the install and boot process varies a bit
-between boards.  The C4 can run the x-loader and u-boot binaries from NAND or
-the SD, while the xM can only run them from the SD. The following instructions
-apply to both the C4 and the xM, but the C4 can skip step 2 (as noted below),
-and may require modification of the NAND environment.
+    # nand unlock
+    # nand erase
+    # nand erase.chip
+
+To further tailor these instructions for your board, please refer to the
+documentation at http://www.beagleboard.org.
+
+From a Linux system with access to the image files perform the following steps
+as root, replacing mmcblk0* with the SD card device on your machine (such as sdc
+if used via a usb card reader):
 
   1. Partition and format an SD card:
      # fdisk -lu /dev/mmcblk0
@@ -173,14 +184,14 @@ and may require modification of the NAND environment.
      # mkfs.vfat -F 16 -n "boot" /dev/mmcblk0p1
      # mke2fs -j -L "root" /dev/mmcblk0p2
 
-   The following assumes the SD card partition 1 and 2 are mounted at
-   /media/boot and /media/root respectively. The files referenced here
-   are made available after the build in build/tmp/deploy/images.
+  The following assumes the SD card partition 1 and 2 are mounted at
+  /media/boot and /media/root respectively. Removing the card and reinserting
+  it will do just that on most modern Linux desktop environments.
+  
+  The files referenced below are made available after the build in
+  build/tmp/deploy/images.
 
   2. Install the boot loaders
-     This step can be omitted for the C4 as it can have the x-loader and
-     u-boot installed in NAND.
-
      # cp MLO-beagleboard /media/boot/MLO
      # cp u-boot-beagleboard.bin /media/boot/u-boot.bin
 
@@ -205,14 +216,15 @@ and may require modification of the NAND environment.
      boot
      EOF
      ) > serial-boot.cmd
-     # mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Poky Minimal" -d ./serial-boot.cmd ./boot.scr
+     # mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Core Minimal" -d ./serial-boot.cmd ./boot.scr
      # cp boot.scr /media/boot
 
-   6. Unmount the SD partitions and boot the Beagleboard
+   6. Unmount the SD partitions, insert the SD card into the Beagleboard, and
+      boot the Beagleboard
 
 Note: As of the 2.6.37 linux-yocto kernel recipe, the Beagleboard uses the
       OMAP_SERIAL device (ttyO2). If you are using an older kernel, such as the
-      2.6.35 linux-yocto-stable, be sure replace ttyO2 with ttyS2 above. You
+      2.6.34 linux-yocto-stable, be sure to replace ttyO2 with ttyS2 above. You
       should also override the machine SERIAL_CONSOLE in your local.conf in
       order to setup the getty on the serial line:
 
@@ -234,32 +246,7 @@ You will need the following:
 * nfs root setup on your workstation
 * tftp server installed on your workstation
 
-The original U-Boot image on board can't boot kernel versions 2.6.34 or later
-successfully, so the U-Boot image should be upgraded to the latest U-Boot.
-
- 1. First build a new U-Boot image for mpc8315e-rdb, u-boot.bin.mpc8315erdb,
-    then make it available on your tftp server. To compile the new u-boot:
-
- $ git clone git://git.denx.de/u-boot.git
- $ cd u-boot
- $ git checkout -b v2010.09-mpc8315erdb v2010.09
- $ make ARCH=powerpc CROSS_COMPILE=<powerpc cross compiler path> MPC8315ERDB_config
- $ make ARCH=powerpc CROSS_COMPILE=<powerpc cross compiler path> all
- $ cp u-boot.bin u-boot.bin.mpc8315erdb
-
- 2. Set up the environment in U-Boot:
-
- =>setenv ipaddr <board ip>
- =>setenv serverip <tftp server ip>
-
- 3. Flash the new U-Boot image:
-
- =>tftp 200000 u-boot.bin.mpc8315erdb
- =>protect off all
- =>erase fe000000 +60000
- =>cp.b 200000 fe000000 60000
-
-Then the kernel can be booted successfully:
+Load the kernel and boot it as follows:
 
  1. Get the kernel (uImage.mpc8315erdb) and dtb (mpc8315erdb.dtb) files from
     the Poky build tmp/deploy directory, and make them available on your tftp
@@ -267,6 +254,8 @@ Then the kernel can be booted successfully:
 
  2. Set up the environment in U-Boot:
 
+ =>setenv ipaddr <board ip>
+ =>setenv serverip <tftp server ip>
  =>setenv bootargs root=/dev/nfs rw nfsroot=<nfsroot ip>:<rootfs path> ip=<board ip>:<server ip>:<gateway ip>:255.255.255.0:mpc8315e:eth0:off console=ttyS0,115200
 
  3. Download kernel and dtb to boot kernel.
@@ -415,3 +404,25 @@ To boot the flashed kernel perform the following steps.
 (-e means 'elf', -d 'decompress')
 
 2) Execute the kernel using the exec command as above.
+
+--- Automating the boot process ---
+
+After writing the kernel to flash and testing the load and exec commands
+manually, you can automate the boot process with a boot script.
+
+1) RedBoot> fconfig
+   (Answer the questions not specified here as they pertain to your environment)
+2) Run script at boot: true
+  Boot script: 
+  .. fis load -d -e kernel
+  .. exec
+  Enter script, terminate with empty line
+  >> fis load -d -e kernel
+  >> exec -c "console=ttyS0,115200 root=/dev/sda1 rw rootdelay=2 board=UBNT-RSPRO"
+  >> 
+3) Answer the remaining questions and write the changes to flash:
+  Update RedBoot non-volatile configuration - continue (y/n)? y
+  ... Erase from 0xbfff0000-0xc0000000: .
+  ... Program from 0x87ff0000-0x88000000 at 0xbfff0000: .
+4) Power cycle the board.
+

bitbake/doc/manual/Makefile

@@ -45,7 +45,7 @@ endif
 	$(call command,xsltproc --stringparam base.dir $@/ $(if $(htmlcssfile),--stringparam html.stylesheet $(htmlcssfile)) $(htmlxsl) $(manual),XSLTPROC $@ $(manual))
 
 $(xmltotypes): $(manual)
-	$(call command,xmlto --extensions -o $(topdir)/$@ $@ $(manual),XMLTO $@ $(manual))
+	$(call command,xmlto --with-dblatex --extensions -o $(topdir)/$@ $@ $(manual),XMLTO $@ $(manual))
 
 clean:
 	rm -rf $(cleanfiles)

bitbake/doc/manual/usermanual.xml

@@ -97,7 +97,7 @@ share common metadata between many packages.</para></listitem>
                 <title>Setting a default value (??=)</title>
                 <para><screen><varname>A</varname> ??= "somevalue"</screen></para>
                 <para><screen><varname>A</varname> ??= "someothervalue"</screen></para>
-                <para>If <varname>A</varname> is set before the above, it will retain that value.  If <varname>A</varname> is unset prior to the above, <varname>A</varname> will be set to <literal>someothervalue</literal>.  This is a lazy version of ??=, in that the assignment does not occur until the end of the parsing process, so that the last, rather than the first, ??= assignment to a given variable will be used.</para>
+                <para>If <varname>A</varname> is set before the above, it will retain that value.  If <varname>A</varname> is unset prior to the above, <varname>A</varname> will be set to <literal>someothervalue</literal>.  This is a lazy version of ?=, in that the assignment does not occur until the end of the parsing process, so that the last, rather than the first, ??= assignment to a given variable will be used.</para>
             </section>
             <section>
                 <title>Immediate variable expansion (:=)</title>

bitbake/lib/bb/fetch2/__init__.py

@@ -555,15 +555,6 @@ class FetchData(object):
         if not self.method:
             raise NoMethodError(url)
 
-        if self.method.supports_srcrev():
-            self.revisions = {}
-            for name in self.names:
-                self.revisions[name] = srcrev_internal_helper(self, d, name)
-
-            # add compatibility code for non name specified case
-            if len(self.names) == 1:
-                self.revision = self.revisions[self.names[0]]
-
         if hasattr(self.method, "urldata_init"):
             self.method.urldata_init(self, d)
 
@@ -579,6 +570,15 @@ class FetchData(object):
         self.donestamp = basepath + '.done'
         self.lockfile = basepath + '.lock'
 
+    def setup_revisons(self, d):
+        self.revisions = {}
+        for name in self.names:
+            self.revisions[name] = srcrev_internal_helper(self, d, name)
+
+        # add compatibility code for non name specified case
+        if len(self.names) == 1:
+            self.revision = self.revisions[self.names[0]]
+
     def setup_localpath(self, d):
         if not self.localpath:
             self.localpath = self.method.localpath(self.url, self, d)

bitbake/lib/bb/fetch2/bzr.py

@@ -45,6 +45,8 @@ class Bzr(FetchMethod):
         relpath = self._strip_leading_slashes(ud.path)
         ud.pkgdir = os.path.join(data.expand('${BZRDIR}', d), ud.host, relpath)
 
+        ud.setup_revisons(d)
+
         if not ud.revision:
             ud.revision = self.latest_revision(ud.url, ud, d)
 

bitbake/lib/bb/fetch2/git.py

@@ -72,15 +72,18 @@ class Git(FetchMethod):
 
         ud.basecmd = data.getVar("FETCHCMD_git", d, True) or "git"
 
-        for name in ud.names:
-            # Ensure anything that doesn't look like a sha256 checksum/revision is translated into one
-            if not ud.revisions[name] or len(ud.revisions[name]) != 40  or (False in [c in "abcdef0123456789" for c in ud.revisions[name]]):
-                ud.revisions[name] = self.latest_revision(ud.url, ud, d, name)
-
         ud.write_tarballs = (data.getVar("BB_GENERATE_MIRROR_TARBALLS", d, True) or "0") != "0"
 
         ud.localfile = ud.clonedir
 
+        ud.setup_revisons(d)
+
+        for name in ud.names:
+            # Ensure anything that doesn't look like a sha256 checksum/revision is translated into one
+            if not ud.revisions[name] or len(ud.revisions[name]) != 40  or (False in [c in "abcdef0123456789" for c in ud.revisions[name]]):
+                ud.branches[name] = ud.revisions[name]
+                ud.revisions[name] = self.latest_revision(ud.url, ud, d, name)
+
     def localpath(self, url, ud, d):
         return ud.clonedir
 

bitbake/lib/bb/fetch2/hg.py

@@ -57,6 +57,8 @@ class Hg(FetchMethod):
         ud.pkgdir = os.path.join(data.expand('${HGDIR}', d), ud.host, relpath)
         ud.moddir = os.path.join(ud.pkgdir, ud.module)
 
+        ud.setup_revisons(d)
+
         if 'rev' in ud.parm:
             ud.revision = ud.parm['rev']
         elif not ud.revision:

bitbake/lib/bb/fetch2/svn.py

@@ -56,6 +56,8 @@ class Svn(FetchMethod):
         ud.pkgdir = os.path.join(data.expand('${SVNDIR}', d), ud.host, relpath)
         ud.moddir = os.path.join(ud.pkgdir, ud.module)
 
+        ud.setup_revisons(d)
+
         if 'rev' in ud.parm:
             ud.revision = ud.parm['rev']
 

bitbake/lib/bb/persist_data.py

@@ -112,7 +112,7 @@ class SQLData(object):
         bb.utils.mkdirhier(os.path.dirname(filename))
 
         self.filename = filename
-        self.connection = sqlite3.connect(filename, timeout=5,
+        self.connection = sqlite3.connect(filename, timeout=30,
                                           isolation_level=None)
         self.cursor = self.connection.cursor()
         self._tables = {}

bitbake/lib/bb/runqueue.py

@@ -1188,6 +1188,25 @@ class RunQueueExecuteTasks(RunQueueExecute):
                     self.rq.scenequeue_covered.add(task)
                     found = True
 
+        # Detect when the real task needs to be run anyway by looking to see
+        # if any of its dependencies within the same package are scheduled
+        # to be run.
+        covered_remove = set()
+        for task in self.rq.scenequeue_covered:
+            task_fnid = self.rqdata.runq_fnid[task]
+            for dep in self.rqdata.runq_depends[task]:
+                if self.rqdata.runq_fnid[dep] == task_fnid:
+                    if dep not in self.rq.scenequeue_covered:
+                        covered_remove.add(task)
+                        break
+
+        for task in covered_remove:
+            fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
+            taskname = self.rqdata.runq_task[task] + '_setscene'
+            bb.build.del_stamp(taskname, self.rqdata.dataCache, fn)
+            logger.debug(1, 'Not skipping task %s because it will have to be run anyway', task)
+            self.rq.scenequeue_covered.remove(task)
+
         logger.debug(1, 'Full skip list %s', self.rq.scenequeue_covered)
 
         for task in self.rq.scenequeue_covered:

bitbake/lib/bb/ui/goggle.py

@@ -105,6 +105,8 @@ def main (server, eventHandler):
         # ignore interrupted io
         if ioerror.args[0] == 4:
             pass
+    except KeyboardInterrupt:
+        pass
     finally:
         server.runCommand(["stateStop"])
 

bitbake/lib/bb/utils.py

@@ -407,13 +407,12 @@ def lockfile(name, shared=False):
     Use the file fn as a lock file, return when the lock has been acquired.
     Returns a variable to pass to unlockfile().
     """
-    path = os.path.dirname(name)
-    if not os.path.isdir(path):
-        logger.error("Lockfile destination directory '%s' does not exist", path)
-        sys.exit(1)
+    dirname = os.path.dirname(name)
+    mkdirhier(dirname)
 
-    if not os.access(path, os.W_OK):
-        logger.error("Error, lockfile path is not writable!: %s" % path)
+    if not os.access(dirname, os.W_OK):
+        logger.error("Unable to acquire lock '%s', directory is not writable",
+                     name)
         sys.exit(1)
 
     op = fcntl.LOCK_EX
@@ -449,7 +448,7 @@ def unlockfile(lf):
     Unlock a file locked using lockfile()
     """
     try:
-        # If we had a shared lock, we need to promote to exclusive before 
+        # If we had a shared lock, we need to promote to exclusive before
         # removing the lockfile. Attempt this, ignore failures.
         fcntl.flock(lf.fileno(), fcntl.LOCK_EX|fcntl.LOCK_NB)
         os.unlink(lf.name)

documentation/Makefile

@@ -0,0 +1,142 @@
+# This is a single Makefile to handle all generated Yocto Project documents.
+# The Makefile needs to live in the documents directory and all figures used
+# in any manuals must be PNG files and live in the individual book's figures
+# directory.
+#
+# The Makefile has these targets:
+#
+#    pdf: generates a PDF version of a manual.  Not valid for the Quick Start
+#    html: generates an HTML version of a manual.
+#    tarball: creates a tarball for the doc files.
+#    validate: validates 
+#    publish: pushes generated files to the Yocto Project website
+#    clean: removes files
+#
+# The Makefile generates an HTML and PDF version of every document except the
+# Yocto Project Quick Start.  The Quick Start is in HTML form only.  The variable
+# The command-line argument DOC represents the folder name in which a particular 
+# document is stored.  The command-line argument VER represents the distro 
+# version of the Yocto Release for which the manuals are being generated.
+# You must invoke the Makefile with the DOC and VER arguments.
+# Examples:
+#
+#     make DOC=bsp-guide VER=1.1
+#     make DOC=yocto-project-qs VER=1.1
+#     make pdf DOC=yocto-project-qs VER=1.1
+#
+# The first example generates the HTML and PDF versions of the BSP Guide for 
+# the Yocto Project 1.1 Release.  The second example generates the HTML version
+# of the Quick Start.  The third example generates an error because you cannot
+# generate a PDF version of the Quick Start.
+#
+# Use the publish target to push the generated manuals to the Yocto Project 
+# website.  All files needed for the manual's HTML form are pushed as well as the 
+# PDF version (if applicable).  
+# Examples:
+#
+#    make publish DOC=bsp-guide VER=1.1
+#    make publish DOC=adt-manual VER=1.1
+#
+
+ifeq ($(DOC),bsp-guide)
+XSLTOPTS = --stringparam html.stylesheet style.css \
+           --stringparam  chapter.autolabel 1 \
+           --stringparam  section.autolabel 1 \
+           --stringparam  section.label.includes.component.label 1 \
+           --xinclude
+ALLPREQ = html pdf tarball
+TARFILES = style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+
+endif
+
+ifeq ($(DOC),yocto-project-qs)
+XSLTOPTS = --stringparam html.stylesheet style.css \
+           --xinclude
+ALLPREQ = html tarball
+TARFILES = 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
+MANUALS = $(DOC)/$(DOC).html
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+endif
+
+ifeq ($(DOC),poky-ref-manual)
+XSLTOPTS = --stringparam html.stylesheet style.css \
+           --stringparam  chapter.autolabel 1 \
+           --stringparam  appendix.autolabel A \
+           --stringparam  section.autolabel 1 \
+           --stringparam  section.label.includes.component.label 1 \
+           --xinclude
+ALLPREQ = html pdf tarball
+TARFILES = poky-ref-manual.html style.css figures/poky-title.png figures/ss-sato.png
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+endif
+
+
+ifeq ($(DOC),adt-manual)
+XSLTOPTS = --stringparam html.stylesheet style.css \
+           --stringparam  chapter.autolabel 1 \
+           --stringparam  appendix.autolabel A \
+           --stringparam  section.autolabel 1 \
+           --stringparam  section.label.includes.component.label 1 \
+           --xinclude
+ALLPREQ = html pdf tarball
+TARFILES = adt-manual.html adt-manual.pdf style.css figures/adt-title.png
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+endif
+
+ifeq ($(DOC),kernel-manual)
+XSLTOPTS = --stringparam html.stylesheet style.css \
+           --stringparam  chapter.autolabel 1 \
+           --stringparam  appendix.autolabel A \
+           --stringparam  section.autolabel 1 \
+           --stringparam  section.label.includes.component.label 1 \
+           --xinclude
+ALLPREQ = html pdf tarball
+TARFILES = kernel-manual.html kernel-manual.pdf style.css figures/kernel-title.png figures/kernel-architecture-overview.png
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+endif
+
+
+##
+# These URI should be rewritten by your distribution's xml catalog to
+# match your localy installed XSL stylesheets.
+XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
+XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
+
+all: $(ALLPREQ)
+
+pdf:
+ifeq ($(DOC),yocto-project-qs)
+	@echo " "
+	@echo "ERROR: You cannot generate a PDF file for the Yocto Project Quick Start"
+	@echo " "
+else
+	cd $(DOC); ../tools/poky-docbook-to-pdf $(DOC).xml ../template; cd ..
+endif
+    
+html:
+#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html 
+	cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
+
+tarball: html
+	cd $(DOC); tar -cvzf $(DOC).tgz $(TARFILES); cd ..
+
+validate:
+	cd $(DOC); xmllint --postvalid --xinclude --noout $(DOC).xml; cd ..
+
+
+publish:
+	scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/$(VER)/$(DOC)
+	cd $(DOC); scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/$(VER)/$(DOC)/figures
+
+clean:
+	rm -f $(MANUALS)

documentation/adt-manual/Makefile

@@ -1,42 +0,0 @@
-XSLTOPTS = --stringparam html.stylesheet style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  appendix.autolabel A \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-         --xinclude
-
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your localy installed XSL stylesheets.
-XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
-XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
-
-all: html pdf tarball
-
-pdf:
-	../tools/poky-docbook-to-pdf adt-manual.xml ../template
-
-##
-# 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 adt-manual.html $(XSL_XHTML_URI) adt-manual.xml
-	xsltproc $(XSLTOPTS) -o adt-manual.html adt-manual-customization.xsl adt-manual.xml
-
-tarball: html
-	tar -cvzf adt-manual.tgz adt-manual.html style.css figures/adt-title.png figures/yocto-project-transp.png
-
-validate:
-	xmllint --postvalid --xinclude --noout adt-manual.xml
-
-OUTPUTS = adt-manual.tgz adt-manual.html adt-manual.pdf
-SOURCES = *.png *.xml *.css
-
-publish:
-	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
-
-clean:
-	rm -f $(OUTPUTS)

documentation/adt-manual/adt-eclipse.xml

@@ -99,11 +99,11 @@
                 “Remote System Explorer Extended SDK”, “Remote System Explorer User Actions”, 
                 “RSE Core”, “RSE Terminals UI”, and “Target Management Terminal”.</para></listitem>
                 <listitem><para><emphasis>Autotools</emphasis> – 
-                <ulink url='http://www.download.eclipse.org/technology/linuxtools/update/'></ulink>:
+                <ulink url='http://download.eclipse.org/technology/linuxtools/update/'></ulink>:
                 Expand the items under “Linux Tools” and select “Autotools support for 
                 CDT (Incubation)”.</para></listitem>
                 <listitem><para><emphasis>Yocto Plug-in</emphasis> – 
-                <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink>:
+                <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/1.0'></ulink>:
                 Check the box next to “Development tools &amp; SDKs for Yocto Linux” 
                 to select all the items.</para></listitem>
             </orderedlist>
@@ -395,7 +395,7 @@
             oprofile-server must be installed on the remote target, respectively, in order 
             to use.  
             You can locate both the viewer and server from 
-            <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/oprofileui/'></ulink>.  
+            <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/oprofileui/'></ulink>.  
             You need to compile and install the oprofile-viewer from the source code 
             on your local host machine.  
             The oprofile-server is installed by default in the image.</para></listitem>

documentation/adt-manual/adt-manual.xml

@@ -33,6 +33,16 @@
                 <date>6 April 2011</date>
                 <revremark>Initial Document released with Yocto Project 1.0 on 6 April 2011.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.0.1</revnumber>
+                <date>23 May 2011</date>
+                <revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0.2</revnumber>
+                <date>20 December 2011</date>
+                <revremark>Released with Yocto Project 1.0.2 on 20 December 2011.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/adt-manual/adt-prepare.xml

@@ -232,7 +232,7 @@
             architectures (x86, x86-64, mips, powerpc, and arm) that can be used 
             unaltered in the QEMU emulator.  
             These kernels and filesystem images reside in the Yocto Project release 
-            area - <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-0.9/'></ulink>
+            area - <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.0/'></ulink>
             and are ideal for experimentation within Yocto Project.
         </note>
     </para>

documentation/bsp-guide/Makefile

@@ -1,35 +0,0 @@
-XSLTOPTS = --stringparam html.stylesheet style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-	   --xinclude
-
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your localy installed XSL stylesheets.
-XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
-XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
-
-all: html pdf tarball
-
-pdf:
-	../tools/poky-docbook-to-pdf bsp-guide.xml ../template
-
-html:
-#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html 
-	xsltproc $(XSLTOPTS) -o bsp-guide.html bsp-guide-customization.xsl bsp-guide.xml
-
-tarball: html
-	tar -cvzf bsp-guide.tgz style.css bsp-guide.html figures/bsp-title.png
-
-validate:
-	xmllint --postvalid --xinclude --noout bsp-guide.xml
-
-OUTPUTS = bsp-guide.pdf bsp-guide.html
-SOURCES = *.png *.xml *.css *.svg
-
-publish:
-	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
-
-clean:
-	rm -f $(OUTPUTS)

documentation/bsp-guide/bsp-guide.xml

@@ -39,6 +39,16 @@
                 <date>6 April 2011</date>
                 <revremark>This manual revision corresponds to the Yocto Project 1.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.0.1</revnumber>
+                <date>23 May 2011</date>
+                <revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0.2</revnumber>
+                <date>20 December 2011</date>
+                <revremark>Released with Yocto Project 1.0.2 on 20 December 2011.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/bsp-guide/bsp.xml

@@ -60,15 +60,35 @@
                 <literallayout class='monospaced'>
      meta-&lt;bsp_name&gt;
                 </literallayout>
+            </para>
+
+            <para>
                 "bsp_name" is a placeholder for the machine or platform name.
                 Here are some example base directory names:
                 <literallayout class='monospaced'>
      meta-emenlow
-     meta-intel_n450
+     meta-n450
      meta-beagleboard
                 </literallayout>
             </para>
 
+            <para>
+                The base directory (<filename>meta-&lt;bsp_name&gt;</filename>) is the root of the BSP layer.
+                This root is what you add to the BBLAYERS variable in <filename>build/conf/bblayers.conf</filename>
+                so that the build system recognizes the BSP definition and from it can build an image.
+                Here is an example:
+                <literallayout class='monospaced'>
+     BBLAYERS = " \
+        /usr/local/src/yocto/meta \
+        /usr/local/src/yocto/meta-yocto \
+        /usr/local/src/yocto/meta-&lt;bsp_name&gt; \
+        "
+                </literallayout>
+                For more detailed information on layers, see the 
+                <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-layers'>
+                BitBake Layers</ulink> section of the Poky Reference Manual.
+            </para>
+
             <para>
                 Below is the common form for the file structure inside a base directory.
                 While you can use this basic form for the standard, realize that the actual structures
@@ -162,8 +182,8 @@ meta-&lt;bsp_name&gt;/binary/&lt;bootable_images&gt;
             <para>
                 This optional area contains useful pre-built kernels and user-space filesystem 
                 images appropriate to the target system.
-                This directory contains the Application Development Toolkit (ADT) and minimal
-                live images when the BSP is has been "tar-balled" and placed on the Yocto Project website. 
+                This directory typically contains graphical (e.g. sato) and minimal live images 
+                when the BSP tarball has been created and made available in the Yocto Project website. 
                 You can use these kernels and images to get a system running and quickly get started 
                 on development tasks.
             </para>
@@ -197,7 +217,8 @@ meta-&lt;bsp_name&gt;/conf/layer.conf
 BBPATH := "${BBPATH}:${LAYERDIR}"
 
 # We have a recipes directory containing .bb and .bbappend files, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ ${LAYERDIR}/recipes/*/*.bbappend"
+BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ 
+            ${LAYERDIR}/recipes/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "bsp"
 BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
@@ -535,14 +556,14 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
 
             <para>
 	      For cases where you can substitute something and still maintain functionality, 
-              the Yocto Project website at 
-              <ulink url='http://yoctoproject.org/download/board-support-package-bsp-downloads'></ulink> 
-              will make available a 'de-featured' BSP completely free of the encumbered IP.
-              In that case you can use the substitution directly and without any further licensing
+              the Yocto Project website's  
+              <ulink url='http://www.yoctoproject.org/download/all?keys=&amp;download_type=1&amp;download_version='>BSP Download Page</ulink> 
+              makes available 'de-featured' BSPs that are completely free of any IP encumbrances.
+              For these cases you can use the substitution directly and without any further licensing
               requirements.  
-              If present, this fully 'de-featured' BSP will be named appropriately different 
-              than the normal encumbered BSP.
-              If available, this substitution is the simplest and most preferred option.
+              If present, these fully 'de-featured' BSPs are named appropriately different 
+              as compared to the names of the respective encumbered BSPs.
+              If available, these substitutions are the simplest and most preferred options.
               This, of course, assumes the resulting functionality meets requirements.
             </para>
 

documentation/kernel-manual/Makefile

@@ -1,42 +0,0 @@
-XSLTOPTS = --stringparam html.stylesheet style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  appendix.autolabel A \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-         --xinclude
-
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your localy installed XSL stylesheets.
-XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
-XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
-
-all: html pdf tarball
-
-pdf:
-	../tools/poky-docbook-to-pdf kernel-manual.xml ../template
-
-##
-# 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 kernel-manual.html yocto-project-kernel-manual-customization.xsl kernel-manual.xml
-
-tarball: html
-	tar -cvzf kernel-manual.tgz kernel-manual.html style.css figures/kernel-title.png figures/kernel-big-picture.png figures/kernel-architecture-overview.png
-
-validate:
-	xmllint --postvalid --xinclude --noout kernel-manual.xml
-
-OUTPUTS = kernel-manual.tgz kernel-manual.html kernel-manual.pdf
-SOURCES = *.png *.xml *.css
-
-publish:
-	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
-
-clean:
-	rm -f $(OUTPUTS)

documentation/kernel-manual/kernel-how-to.xml

@@ -1022,7 +1022,7 @@ That's it. Configure and build.
                     You can start with something in <filename>meta/conf/machine</filename> - <filename>
                     meta/conf/machine/atom-pc.conf</filename> for example.  Or, you can start with a machine 
                     configuration from any of the BSP layers in the meta-intel repository at 
-                    <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/meta-intel/'></ulink>, such as 
+                    <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/'></ulink>, such as 
                     <filename>meta-intel/meta-emenlow/conf/machine/emenlow.conf</filename>.
                 </para>
                 
@@ -1073,7 +1073,7 @@ That's it. Configure and build.
                     To create this branch first create a bare clone of the Yocto Project git repository.
                     Next, create a local clone of that:
                     <literallayout class='monospaced'>
-     $ git clone --bare git://git.pokylinux.org/linux-yocto-2.6.37.git
+     $ git clone --bare git://git.yoctoproject.org/linux-yocto-2.6.37.git
      linux-yocto-2.6.37.git
      $ git clone linux-yocto-2.6.37.git linux-yocto-2.6.37
                     </literallayout>

documentation/kernel-manual/kernel-manual.xml

@@ -39,6 +39,16 @@
                 <date>6 April 2011</date>
                 <revremark>This revision corresponds with the Yocto Project 1.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.0.1</revnumber>
+                <date>23 May 2011</date>
+                <revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0.2</revnumber>
+                <date>20 December 2011</date>
+                <revremark>Released with Yocto Project 1.0.2 on 20 December 2011.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/poky-ref-manual/Makefile

@@ -1,36 +0,0 @@
-XSLTOPTS = --stringparam html.stylesheet style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  appendix.autolabel A \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-	   --xinclude
-
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your localy installed XSL stylesheets.
-XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
-XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
-
-all: html pdf tarball
-
-pdf:
-	../tools/poky-docbook-to-pdf poky-ref-manual.xml ../template
-
-html:
-#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html 
-	xsltproc $(XSLTOPTS) -o poky-ref-manual.html poky-ref-manual-customization.xsl poky-ref-manual.xml
-
-tarball: html
-	tar -cvzf poky-ref-manual.tgz poky-ref-manual.html style.css figures/yocto-project-transp.png figures/poky-ref-manual.png screenshots/ss-sato.png
-
-validate:
-	xmllint --postvalid --xinclude --noout poky-ref-manual.xml
-
-OUTPUTS = poky-ref-manual.tgz poky-ref-manual.html poky-ref-manual.pdf 
-SOURCES = *.png *.xml *.css *.svg
-
-publish:
-	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
-
-clean:
-	rm -f $(OUTPUTS)

documentation/poky-ref-manual/development.xml

@@ -12,7 +12,7 @@
     </para>
 
         <section id="platdev-appdev-external-sdk">
-        <title>External Development Using the Poky SDK</title>
+        <title>External Development Using the Application Development Toolkit (ADT)</title>
         <para>
             The meta-toolchain and meta-toolchain-sdk targets build tarballs that contain toolchains and 
             libraries suitable for application development outside of Poky. 
@@ -45,17 +45,41 @@
         </section>
 
         <section id="using-the-eclipse-and-anjuta-plug-ins">
-        <title>Using the Eclipse and Anjuta Plug-ins</title>
+        <title>Using the Eclipse Plug-in</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 allows for cross debugging and
-            profiling.  Additionally, the Eclipse plug-in provides a suite of tools 
+            The current release of the Yocto Project supports the Eclipse IDE plug-in
+            to make developing software easier for the application developer. 
+            The plug-in provides capability extensions to the graphical IDE to allow
+            for cross compilation, deployment and execution of the output in a QEMU 
+            emulation session. 
+            Support of the Eclipse plug-in also allows for 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>
+        <note>
+            The current release of the Yocto Project no longer supports the Anjuta plug-in.
+            However, the Poky Anjuta Plug-in is available to download directly from the Poky 
+            Git repository located through the web interface at
+            <ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins.
+            The community is free to continue supporting it beyond the Yocto Project 0.9
+            Release.            
+        </note>
+        <para>
+            To use the Eclipse plug-in you need the Eclipse Framework (Helios 3.6.1) along 
+            with other plug-ins installed into the Eclipse IDE.
+            Once you have your environment setup you need to configure the Eclipse plug-in.
+            For information on how to install and configure the Eclipse plug-in, see the
+            <ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html#adt-eclipse'>
+            "Working Within Eclipse"</ulink> chapter in the 
+            <ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html'>
+            "Application Development Toolkit (ADT) User's Guide."</ulink>
+         </para>
+
+
+
+<!--
 
             <section id="the-eclipse-plug-in">
             <title>The Eclipse Plug-in</title>
@@ -309,7 +333,7 @@
              <para>
                 See the README file contained in the project for more information on 
                 Anjuta dependencies and building the plug-in. 
-                If you want to disable remote gdb debugging, pass the "--disable-gdb-integration" switch when 
+                If you want to disable remote gdb debugging, pass the "&dash;&dash;disable-gdb-integration" switch when 
                 you configure the plug-in.
             </para>
                 <section id="setting-up-the-anjuta-plugin">
@@ -416,6 +440,10 @@
                 </para>
                 </section>
             </section>
+
+
+-->
+
         </section>
 
         <section id="platdev-appdev-qemu">
@@ -691,7 +719,7 @@
                 </literallayout>
                 Once the binary is built you can find it here: 
                 <programlisting>
-tmp/sysroots/&lt;host-arch&lt;/usr/bin/&lt;target-abi&gt;-gdb 
+tmp/sysroots/&lt;host-arch&gt;/usr/bin/&lt;target-abi&gt;-gdb 
                 </programlisting>
             </para>
 
@@ -909,8 +937,8 @@ $ opreport -cl
 
         <para>
             A graphical user interface for OProfile is also available. 
-            You can download and build it from svn at
-            <ulink url="http://svn.o-hand.com/repos/oprofileui/trunk/"></ulink>. 
+            You can download and build it from the Yocto Project at
+            <ulink url="http://git.yoctoproject.org/cgit.cgi/oprofileui/"></ulink>. 
             If the "tools-profile" image feature is selected, all necessary binaries
             are installed onto the target device for OProfileUI interaction.
         </para>
@@ -926,7 +954,7 @@ $ opreport -cl
             </caption>
          </mediaobject>
          </screenshot>
--->
+
         <para>
             In order to convert the data in the sample format from the target
             to the host you need the <filename>opimport</filename> program. 
@@ -935,13 +963,12 @@ $ opreport -cl
             <ulink url='http://debian.o-hand.com/'>OpenedHand repository</ulink>.
             We recommend using OProfile 0.9.3 or greater. 
         </para>
+-->
         <para>
             Even though Poky usually includes all needed patches on the target device, you 
             might find you need other OProfile patches for recent OProfileUI features.
-            If so, see the <ulink url='http://svn.o-hand.com/repos/oprofileui/trunk/README'>
+            If so, see the <ulink url='http://git.yoctoproject.org/cgit.cgi/oprofileui/tree/README'>
             OProfileUI README</ulink> for the most recent information.
-            You can also see <ulink url="http://labs.o-hand.com/oprofileui">OProfileUI website
-            </ulink> for general information on the OProfileUI project. 
         </para>
 
         <section id="platdev-oprofile-oprofileui-online">
@@ -1038,7 +1065,7 @@ $ opreport -cl
                 a "vmlinux" file that matches the running kernel is available. 
                 In Poky, that file is usually located in 
                 <filename>/boot/vmlinux-KERNELVERSION</filename>, where KERNEL-version is the 
-                version of the kernel (e.g. 2.6.23). 
+                version of the kernel. 
                 Poky generates separate vmlinux packages for each kernel
                 it builds so it should be a question of just making sure a matching package is 
                 installed - for example: <filename>opkg install kernel-vmlinux</filename>. 

documentation/poky-ref-manual/extendpoky.xml

@@ -87,7 +87,7 @@ do_install() {
                 The result of the build is automatically packaged. 
                 And, if the application uses NLS for localization, packages with local information are 
                 generated (one package per language). 
-                Following is one example: (<filename>hello_2.2.bb</filename>)
+                Following is one example: (<filename>hello_2.3.bb</filename>)
             </para>
             <programlisting>
 DESCRIPTION = "GNU Helloworld application"
@@ -349,9 +349,9 @@ RRECOMMENDS_task-custom-tools = "\
         </section>
 
         <section id='usingpoky-extend-customimage-imagefeatures'>
-            <title>Customizing Images Using Custom IMAGE_FEATURES</title>
+            <title>Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES</title>
             <para>
-                Ultimately users might want to add extra image "features" as used by Poky with the 
+                Ultimately users might want to add extra image "features" to the set used by Poky with the 
                 <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>
                 variable. 
                 To create these features, the best reference is 
@@ -363,6 +363,9 @@ RRECOMMENDS_task-custom-tools = "\
                 </glossterm> variable is generated automatically. 
                 Users can add extra features by extending the class or creating a custom class for use 
                 with specialized image <filename>.bb</filename> files.
+                You can also add more features by configuring the 
+                <glossterm><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></glossterm>
+                variable in the <filename>local.conf</filename> file.
             </para>
             <para>
                 Poky ships with two SSH servers you can use in your images: Dropbear and OpenSSH. 
@@ -754,7 +757,7 @@ BBFILE_PRIORITY_emenlow = "6"
                 Experience shows that buildbot is a good fit for this role. 
                 What works well is to configure buildbot to make two types of builds:
                 incremental and full (from scratch).  
-                See <ulink url='http://autobuilder.pokylinux.org:8010'>poky autobuilder</ulink>
+                See <ulink url='http://autobuilder.yoctoproject.org:8010'>poky autobuilder</ulink>
                 for an example implementation that uses buildbot.
             </para>
             <para>

documentation/poky-ref-manual/faq.xml

@@ -413,6 +413,57 @@
         </answer>
     </qandaentry>
 
+    <qandaentry>
+        <question>
+            <para>
+                Why don't you support directories with spaces in the pathnames?
+            </para>
+        </question>
+        <answer>
+            <para>
+                We have tried to do this before but too many of the tools we depend on such as autoconf 
+                break when they find spaces in pathnames.  
+                Until that situation changes we will not support spaces in pathnames.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I use an external toolchain?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The toolchain configuration is very flexible and customizable.
+                It is primarily controlled with the TCMODE variable.
+                This variable controls which file to include 
+                (<filename>conf/distro/include/tcmode-*.inc</filename>).
+            </para>
+            <para>
+                The default value of TCMODE is "default".
+                However, other patterns are accepted.
+                In particular, "external-*" refers to external toolchains of which there are some basic examples
+                included with the core.
+                A user can use their own custom toolchain definition in their own layer 
+                (or <filename>local.conf</filename> directory) at the location 
+                <filename>conf/distro/include/tcmode-*.inc</filename>.
+            </para>
+            <para>
+                In addition to the toolchain configuration, you also need a corresponding toolchain recipe file.
+                This recipe file needs to package up any pre-built objects in the toolchain such as 
+                <filename>libgcc</filename>, <filename>libstdcc++</filename>, 
+                any locales and <filename>libc</filename>.
+                An example is the <filename>external-csl-toolchain_2008q3-72.bb</filename>, which reuses the core 
+                <filename>libc</filename> packaging class to do most of the work.
+            </para>
+        </answer>
+    </qandaentry>
+
+
+
+
     <qandaentry>
         <question>
             <para>

documentation/poky-ref-manual/introduction.xml

@@ -59,7 +59,7 @@
     <screenshot>
     <mediaobject>
         <imageobject>
-            <imagedata fileref="screenshots/ss-sato.png" format="PNG" align='center' scalefit='1' width="100%" contentdepth="100%"/>
+            <imagedata fileref="figures/ss-sato.png" format="PNG" align='center' scalefit='1' width="100%" contentdepth="100%"/>
         </imageobject>
         <caption>
             <para>The Sato Desktop - A screenshot from a machine running a Poky built image</para>

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

@@ -9,14 +9,14 @@
  
         <mediaobject>
             <imageobject>
-                <imagedata fileref='figures/poky-ref-manual.png' 
+                <imagedata fileref='figures/poky-title.png' 
                     format='SVG' 
-                    align='center' scalefit='1' width='100%'/>
+                    align='left' scalefit='1' width='100%'/>
             </imageobject>    
         </mediaobject>
 
-        <title>Poky Reference Manual</title>
-        <subtitle>A Guide and Reference to Poky</subtitle>
+        <title></title>
+
         <authorgroup>
             <author>
                 <firstname>Richard</firstname> <surname>Purdie</surname>
@@ -48,9 +48,19 @@
                 <revremark>Poky Master Documentation</revremark>
             </revision>
             <revision>
-                <revnumber>1.0</revnumber>
+                <revnumber>5.0+git</revnumber>
                 <date>6 April 2011</date>
-                <revremark>Poky documentation releasing with the Yocto Project 1.0 Release.</revremark>
+                <revremark>Released with Yocto Project 1.0 (Bernard 5.0).</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0.1</revnumber>
+                <date>23 May 2011</date>
+                <revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0.2</revnumber>
+                <date>20 December 2011</date>
+                <revremark>Released with Yocto Project 1.0.2 on 20 December 2011.</revremark>
             </revision>
         </revhistory>
 

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

@@ -33,16 +33,16 @@
 
         <para>
             The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
-            Poky keeps this file in <filename class="directory">meta/conf/</filename>.
-            BitBake finds it by examining the <varname>BBPATH</varname> environment 
-            variable and looking for the <filename class="directory">meta/conf/</filename> 
+            Poky keeps this file in <filename>meta/conf/</filename>.
+            BitBake finds it by examining the <filename>BBPATH</filename> environment 
+            variable and looking for the <filename>meta/conf/</filename> 
             directory.
         </para>
 
         <para>
             In Poky, <filename>bitbake.conf</filename> lists other configuration 
-            files to include from a <filename class="directory">conf/</filename> 
-            directory below the directories listed in <varname>BBPATH</varname>. 
+            files to include from a <filename>conf/</filename> 
+            directory below the directories listed in <filename>BBPATH</filename>. 
             In general the most important configuration file from a user's perspective 
             is <filename>local.conf</filename>, which contains a user's customized 
             settings for Poky. 
@@ -54,11 +54,11 @@
             The DISTRO and MACHINE environment variables are both usually set in 
             the <filename>local.conf</filename> file. 
             Valid distribution 
-            configuration files are available in the <filename class="directory">
+            configuration files are available in the <filename>
             meta/conf/distro/</filename> directory and valid machine configuration 
-            files in the <filename class="directory">meta/conf/machine/</filename> 
+            files in the <filename>meta/conf/machine/</filename> 
             directory. 
-            Within the <filename class="directory">meta/conf/machine/include/</filename> 
+            Within the <filename>meta/conf/machine/include/</filename> 
             directory are various <filename>tune-*.inc</filename> configuration files that provide common 
             "tuning" settings specific to and shared between particular architectures and machines.
         </para>
@@ -70,7 +70,7 @@
             <glossterm><link linkend='var-INHERIT'>INHERIT</link></glossterm>
             variable are also inculded. 
             Class files are searched for in a classes subdirectory 
-            under the paths in <varname>BBPATH</varname> in the same way as
+            under the paths in <filename>BBPATH</filename> in the same way as
             configuration files.
         </para>
 
@@ -79,31 +79,29 @@
             variable <glossterm><link linkend='var-BBFILES'>BBFILES</link></glossterm> 
             is set, usually in
             <filename>local.conf</filename>, and defines the list of places to search for 
-            <filename class="extension">.bb</filename> files. 
-            By default, the BBFILES variable specifies the <filename class="directory">meta/packages/
-            </filename> directory within Poky, but other directories such as
-            <filename class="directory">meta-extras/</filename> can be included 
-            too. 
+            <filename>.bb</filename> files. 
+            By default, the BBFILES variable specifies the <filename>meta/recipes-*/
+            </filename> directory within Poky. 
             Adding extra content to BBFILES is best achieved through the use of BitBake
             <link linkend='usingpoky-changes-layers'>"layers"</link>.
         </para>
 
         <para>
-            BitBake parses each <filename class="extension">.bb</filename> file in BBFILES and 
+            BitBake parses each <filename>.bb</filename> file in BBFILES and 
             stores the values of various variables.  
-            In summary, for each <filename class="extension">.bb</filename> 
+            In summary, for each <filename>.bb</filename> 
             file the configuration plus the base class of variables are set, followed 
-            by the data in the <filename class="extension">.bb</filename> file 
+            by the data in the <filename>.bb</filename> file 
             itself, followed by any inherit commands that
-            <filename class="extension">.bb</filename> file might contain.
+            <filename>.bb</filename> file might contain.
         </para>
 
         <para>
-            Because parsing <filename class="extension">.bb</filename> files is a time 
+            Because parsing <filename>.bb</filename> files is a time 
             consuming process, a cache is kept to speed up subsequent parsing. 
-            This cache is invalid if the timestamp of the <filename class="extension">.bb</filename> 
+            This cache is invalid if the timestamp of the <filename>.bb</filename> 
             file itself changes, or if the timestamps of any of the include, 
-            configuration or class files the <filename class="extension">.bb</filename>
+            configuration or class files the <filename>.bb</filename>
             file depends on changes.
         </para>
     </section>
@@ -112,7 +110,7 @@
         <title>Preferences and Providers</title>
 
         <para>
-            Once all the <filename class="extension">.bb</filename> files have been 
+            Once all the <filename>.bb</filename> files have been 
             parsed, BitBake starts to build the target (poky-image-sato in the previous section's 
             example) and looks for providers of that target.
             Once a provider is selected, BitBake resolves all the dependencies for  
@@ -125,7 +123,7 @@
 
         <para>
             Sometimes a target might have multiple providers.
-            An common example is "virtual/kernel", which is provided by each kernel package. 
+            A common example is "virtual/kernel", which is provided by each kernel package. 
             Each machine often elects the best kernel provider by using a line similar to the 
             following in the machine configuration file:
         </para>
@@ -195,18 +193,18 @@ PREFERRED_PROVIDER_virtual/kernel = "linux-rp"
             The build now starts with BitBake forking off threads up to the limit set in the 
             <glossterm><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></glossterm> variable.
             BitBake continues to fork threads as long as there are tasks ready to run,
-            those taksks have all their dependencies met, and the thread threshold has not been 
+            those tasks have all their dependencies met, and the thread threshold has not been 
             exceeded.
         </para>
 
         <para>
             As each task completes, a timestamp is written to the directory specified by the 
             <glossterm><link linkend='var-STAMPS'>STAMPS</link></glossterm> variable (usually 
-            <filename class="directory">build/tmp/stamps/*/</filename>). 
+            <filename>build/tmp/stamps/*/</filename>). 
             On subsequent runs, BitBake looks at the STAMPS directory and does not rerun 
             tasks that are already completed unless a timestamp is found to be invalid. 
             Currently, invalid timestamps are only considered on a per 
-            <filename class="extension">.bb</filename> file basis.
+            <filename>.bb</filename> file basis.
             So, for example, if the configure stamp has a timestamp greater than the 
             compile timestamp for a given target then the compile task would rerun.
             Running the compile task again, however, has no effect on other providers 

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

@@ -6,16 +6,16 @@
 
 <para>
     Class files are used to abstract common functionality and share it amongst multiple 
-    <filename class="extension">.bb</filename> files. Any metadata usually found in a 
-    <filename class="extension">.bb</filename> file can also be placed in a class 
+    <filename>.bb</filename> files. Any metadata usually found in a 
+    <filename>.bb</filename> file can also be placed in a class 
     file. Class files are identified by the extension 
-    <filename class="extension">.bbclass</filename> and are usually placed 
-    in a <filename class="directory">classes/</filename> directory beneath the 
-    <filename class="directory">meta*/</filename> directory or the directory pointed
-    by BUILDDIR (e.g. <filename class="directory">build/</filename>)in the same way as
-    <filename class="extension">.conf</filename> files in the <filename 
+    <filename>.bbclass</filename> and are usually placed 
+    in a <filename>classes/</filename> directory beneath the 
+    <filename>meta*/</filename> directory or the directory pointed
+    by BUILDDIR (e.g. <filename>build/</filename>)in the same way as
+    <filename>.conf</filename> files in the <filename 
     class="directory">conf</filename> directory. Class files are searched for 
-    in BBPATH in the same was as <filename class="extension">.conf</filename> files too.
+    in BBPATH in the same was as <filename>.conf</filename> files too.
 </para>
 
 <para>
@@ -28,14 +28,14 @@
     <title>The base class - <filename>base.bbclass</filename></title>
 
     <para>
-        The base class is special in that every <filename class="extension">.bb</filename> 
+        The base class is special in that every <filename>.bb</filename> 
         file inherits it automatically. It contains definitions of standard basic 
         tasks such as fetching, unpacking, configuring (empty by default), compiling 
         (runs any Makefile present), installing (empty by default) and packaging 
         (empty by default). These are often overridden or extended by other classes 
         such as <filename>autotools.bbclass</filename> or 
         <filename>package.bbclass</filename>. The class also contains some commonly
-        used functions such as <function>oe_runmake</function>.
+        used functions such as <filename>oe_runmake</filename>.
     </para>
 </section>
 
@@ -43,13 +43,13 @@
     <title>Autotooled Packages - <filename>autotools.bbclass</filename></title>
 
     <para>
-        Autotools (autoconf, automake, libtool) brings standardisation and this
-        class aims to define a set of tasks (configure, compile etc.) that will
-        work for all autotooled packages.  It should usually be enough to define
-        a few standard variables as documented in the <link
-        linkend='usingpoky-extend-addpkg-autotools'>simple autotools
-        example</link> section and then simply "inherit autotools". This class
-        can also work with software that emulates autotools.
+        Autotools (autoconf, automake, libtool) bring standardization. 
+        This class defines a set of tasks (configure, compile etc.) that 
+        work for all autotooled packages.  
+        It should usually be enough to define a few standard variables as documented in the 
+        <link linkend='usingpoky-extend-addpkg-autotools'>simple autotools
+        example</link> section and then simply "inherit autotools". 
+        This class can also work with software that emulates autotools.
     </para>
 
     <para>
@@ -60,26 +60,29 @@
     <itemizedlist>
       <listitem>
         <para>
-            'do_configure' regenerates the configure script (using autoreconf) and
-            then launches it with a standard set of arguments used during
-            cross-compilation. Additional parameters can be passed to 
-            <command>configure</command> through the <glossterm><link 
-            linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></glossterm> variable.
+            <filename>do_configure</filename> &dash; regenerates the configure script (using autoreconf) 
+            and then launches it with a standard set of arguments used during
+            cross-compilation. 
+            You can pass additional parameters to 
+            <filename>configure</filename> through the 
+            <glossterm><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></glossterm> variable.
         </para>
       </listitem>
       <listitem>
         <para>
-            'do_compile' runs <command>make</command> with arguments specifying 
-            the compiler and linker. Additional arguments can be passed through 
+            <filename>do_compile</filename> &dash; runs <filename>make</filename> with 
+            arguments that specify the compiler and linker. 
+            You can pass additional arguments through 
             the <glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link>
             </glossterm> variable.
         </para>
       </listitem>
       <listitem>
         <para>
-            'do_install' runs <command>make install</command> passing a DESTDIR 
-            option taking its value from the standard <glossterm><link
-            linkend='var-DESTDIR'>DESTDIR</link></glossterm> variable.
+            <filename>do_install</filename> &dash; runs <filename>make install</filename> 
+            and passes a <filename>DESTDIR</filename> 
+            option, which takes its value from the standard 
+            <glossterm><link linkend='var-DESTDIR'>DESTDIR</link></glossterm> variable.
         </para>
       </listitem>
     </itemizedlist>
@@ -91,54 +94,31 @@
 
     <para>
         Several programs can fulfill the same or similar function and
-        they can be installed with the same name. For example the <command>ar</command> 
+        be installed with the same name. 
+        For example, the <filename>ar</filename> 
         command is available from the "busybox", "binutils" and "elfutils" packages. 
-        This class handles the renaming of the binaries so multiple packages 
-        can be installed which would otherwise conflict and yet the 
-        <command>ar</command> command still works regardless of which are installed
-        or subsequently removed. It renames the conflicting binary in each package 
+        The <filename>update-alternatives.bbclass</filename> class handles renaming the 
+        binaries so that multiple packages can be installed without conflicts. 
+        The <filename>ar</filename> command still works regardless of which packages are installed
+        or subsequently removed. 
+        The class renames the conflicting binary in each package 
         and symlinks the highest priority binary during installation or removal 
         of packages.
-
+    </para>
+    <para>
         Four variables control this class:
     </para>
-
-
-    <variablelist>
-    <varlistentry>
-    <term>ALTERNATIVE_NAME</term>
-    <listitem>
-       <para>
-            Name of binary which will be replaced (<command>ar</command> in this example)
-       </para>
-    </listitem>
-    </varlistentry>
-    <varlistentry>
-    <term>ALTERNATIVE_LINK</term>
-    <listitem>
-        <para>
-            Path to resulting binary ("/bin/ar" in this example)
-        </para>
-    </listitem>
-    </varlistentry>
-    <varlistentry>
-    <term>ALTERNATIVE_PATH</term>
-    <listitem>
-        <para>
-            Path to real binary ("/usr/bin/ar.binutils" in this example)
-        </para>
-    </listitem>
-    </varlistentry>
-    <varlistentry>
-    <term>ALTERNATIVE_PRIORITY</term>
-    <listitem>
-        <para>
-            Priority of binary, the version with the most features should have the highest priority
-        </para>
-    </listitem>
-    </varlistentry>
-    </variablelist>
-
+    <itemizedlist>
+        <listitem><para><filename>ALTERNATIVE_NAME</filename> &dash; The name of the 
+        binary that is replaced (<filename>ar</filename> in this example).</para></listitem>
+        <listitem><para><filename>ALTERNATIVE_LINK</filename> &dash; The path to 
+        the resulting binary (<filename>/bin/ar</filename> in this example).</para></listitem>
+        <listitem><para><filename>ALTERNATIVE_PATH</filename> &dash; The path to the 
+        real binary (<filename>/usr/bin/ar.binutils</filename> in this example).</para></listitem>
+        <listitem><para><filename>ALTERNATIVE_PRIORITY</filename> &dash; The priority of 
+        the binary. 
+        The version with the most features should have the highest priority.</para></listitem>
+    </itemizedlist>
     <para>
 	Currently, only one binary per package is supported.
     </para>
@@ -172,7 +152,7 @@
     <para>
         During staging Bitbake installs such scripts into the <filename 
         class="directory">sysroots/</filename> directory. It also changes all
-        paths to point into the <filename class="directory">sysroots/</filename>
+        paths to point into the <filename>sysroots/</filename>
         directory so all builds which use the script will use the correct 
         directories for the cross compiling layout.
     </para>
@@ -215,7 +195,7 @@
     </para>
 
     <para>
-        Result of their work are <filename class="directory">tmp/deploy/source/</filename> 
+        Result of their work are <filename>tmp/deploy/source/</filename> 
         subdirs with sources sorted by <glossterm><link linkend='var-LICENSE'>LICENSE</link>
         </glossterm> field. If recipe lists few licenses (or has entries like "Bitstream Vera") source archive is put in each
         license dir.
@@ -319,7 +299,7 @@
     </para>
     <para>
         This means that each kernel module built is packaged separately and inter-module dependencies are
-        created by parsing the <command>modinfo</command> output. If all modules are
+        created by parsing the <filename>modinfo</filename> output. If all modules are
         required then installing the "kernel-modules" package will install all
         packages with modules and various other kernel packages such as "kernel-vmlinux".
     </para>
@@ -403,7 +383,7 @@
 
     <para>
         Only the most useful/important classes are covered here but there are 
-        others, see the <filename class="directory">meta/classes</filename> directory for the rest. 
+        others, see the <filename>meta/classes</filename> directory for the rest. 
     </para>
 </section>
 

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

@@ -211,12 +211,14 @@
         <title>Reference: Images</title>
 
         <para>
-            The contents of images generated by Poky can be controlled by the <glossterm
-        linkend='var-IMAGE_FEATURES'><link
-        linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>
-        variable in local.conf. Through this you can add several different
-        predefined packages such as development utilities or packages with debug
-        information needed to investigate application problems or profile applications.
+            The contents of images generated by Poky can be controlled by the 
+            <glossterm linkend='var-IMAGE_FEATURES'><link linkend='var-IMAGE_FEATURES'>
+            IMAGE_FEATURES</link></glossterm> variable and the in local.conf and the 
+            <glossterm linkend='var-EXTRA_IMAGE_FEATURES'><link linkend='var-EXTRA_IMAGE_FEATURES'>
+            EXTRA_IMAGE_FEATURES</link></glossterm> that you typically configure in your image recipes.
+            Through these varibales you can add several different
+            predefined packages such as development utilities or packages with debug
+            information needed to investigate application problems or profile applications.
         </para>
 
         <para>

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

@@ -20,7 +20,7 @@
         you must make the following changes in the <filename>local.conf</filename> file
         before using the BitBake command to build the minimal or base image:
         <literallayout class='monospaced'>
-     1. Comment out the IMAGE_EXTRA_FEATURES line
+     1. Comment out the EXTRA_IMAGE_FEATURES line
      2. Set INCOMPATIBLE_LICENSE = "GPLv3"
         </literallayout>
     </note>

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

@@ -32,9 +32,8 @@
         </para>
 
         <para>
-            For more information on BitBake, see the BitBake project site at 
-            <ulink url="http://bitbake.berlios.de/"/> 
-            and the BitBake on-line manual at <ulink url="http://bitbake.berlios.de/manual/"/>.
+            For more information on BitBake, see the BitBake on-line manual at 
+            <ulink url="http://bitbake.berlios.de/manual/"/>.
         </para>
     </section>
 
@@ -62,7 +61,7 @@
         </para>
     </section>
 
-    <section id='structure-core-meta-extras'>
+<!--    <section id='structure-core-meta-extras'>
         <title><filename class="directory">meta-extras/</filename></title>
 
         <para>
@@ -71,8 +70,25 @@
             This metadata is disabled by default and is not supported as part of Poky.
         </para>
     </section>
+-->
 
-    <section id='structure-core-meta-***'>
+    <section id='structure-core-meta-demoapps'>
+        <title><filename class="directory">meta-demoapps/</filename></title>
+
+        <para>
+            This directory contains recipes for applications and demos that are not core.
+        </para>
+    </section>
+
+    <section id='structure-core-meta-rt'>
+        <title><filename class="directory">meta-rt/</filename></title>
+
+        <para>
+            This directory contains recipes for RealTime.
+        </para>
+    </section>
+
+<!--    <section id='structure-core-meta-***'>
         <title><filename class="directory">meta-***/</filename></title>
 
         <para>
@@ -80,6 +96,7 @@
             The layers are enabled by adding them to the <filename>conf/bblayers.conf</filename> file.
         </para>
     </section>
+-->
 
     <section id='structure-core-scripts'>
         <title><filename class="directory">scripts/</filename></title>
@@ -92,7 +109,7 @@
         </para>
     </section>
 
-    <section id='structure-core-sources'>
+<!--    <section id='structure-core-sources'>
         <title><filename class="directory">sources/</filename></title>
 
         <para>
@@ -124,6 +141,7 @@
             <filename class="extension">.md5</filename> file as well.
         </para>
     </section>
+-->
 
     <section id='handbook'>
         <title><filename class="directory">documentation</filename></title>
@@ -160,11 +178,28 @@
             like Poky to generate the build output.
         </para>
     </section>
+
+    <section id='structure-basic-top-level'>
+        <title><filename>LICENSE, README, and README.hardware</filename></title>
+
+        <para>
+            These files are standard top-level files. 
+        </para>
+    </section>
 </section>
 
 <section id='structure-build'>
     <title>The Build Directory - <filename class="directory">build/</filename></title>
 
+    <section id='structure-build-pseudodone'>
+        <title><filename>build/pseudodone</filename></title>
+
+        <para>
+            This tag file indicates that the intitial pseudo binar was created. 
+            The first time BitBake is invoked this file is built. 
+        </para>
+    </section>
+
     <section id='structure-build-conf-local.conf'>
         <title><filename>build/conf/local.conf</filename></title>
 
@@ -198,6 +233,36 @@
         </para>
     </section>
 
+    <section id='structure-build-conf-sanity_info'>
+        <title><filename>build/conf/sanity_info</filename></title>
+
+        <para>
+            This file is created during the build to indicate the state of the sanity checks.
+        </para>
+    </section>
+
+    <section id='structure-build-downloads'>
+        <title><filename>build/downloads/</filename></title>
+
+        <para>
+            This directory is used for the upstream source tarballs.
+            The directory can be reused by multiple builds or moved to another location. 
+            You can control the location of this directory through the
+            <glossterm><link linkend='var-DL_DIR'>DL_DIR</link></glossterm> variable.
+        </para>
+    </section>
+
+    <section id='structure-build-sstate-cache'>
+        <title><filename>build/sstate-cache/</filename></title>
+
+        <para>
+            This directory is used for the shared state cache.
+            The directory can be reused by multiple builds or moved to another location. 
+            You can control the location of this directory through the
+            <glossterm><link linkend='var-SSTATE_DIR'>SSTATE_DIR</link></glossterm> variable.
+        </para>
+    </section>
+
     <section id='structure-build-tmp'>
         <title><filename class="directory">build/tmp/</filename></title>
 
@@ -211,6 +276,14 @@
         </para>
     </section>
 
+    <section id='structure-build-tmp-buildstats'>
+        <title><filename class="directory">build/tmp/buildstats/</filename></title>
+
+        <para>
+            This directory stores the build statistics.
+        </para>
+    </section>
+
     <section id='structure-build-tmp-cache'>
         <title><filename class="directory">build/tmp/cache/</filename></title>
 
@@ -231,7 +304,7 @@
         <title><filename class="directory">build/tmp/deploy/deb/</filename></title>
 
         <para>
-            This directory receives any .deb packages produced by Poky.
+            This directory receives any <filename>.deb</filename> packages produced by Poky.
             The packages are sorted into feeds for different architecture types.
         </para>
     </section>
@@ -240,8 +313,8 @@
         <title><filename class="directory">build/tmp/deploy/rpm/</filename></title>
 
         <para>
-            This directory receives any .rpm packages produced by Poky.  
-            The packages re sorted into feeds for different architecture types.
+            This directory receives any <filename>.rpm</filename> packages produced by Poky.  
+            The packages are sorted into feeds for different architecture types.
         </para>
     </section>
 
@@ -257,7 +330,7 @@
     <section id='structure-build-tmp-deploy-ipk'>
         <title><filename class="directory">build/tmp/deploy/ipk/</filename></title>
 
-        <para>This directory receives .ipk packages produced by Poky.</para>
+        <para>This directory receives <filename>.ipk</filename> packages produced by Poky.</para>
     </section>
 
     <section id='structure-build-tmp-sysroots'>
@@ -513,6 +586,15 @@
         </para>
     </section>
 
+    <section id='structure-meta-recipes-support'>
+        <title><filename class="directory">meta/recipes-support/</filename></title>
+
+        <para>
+            This directory contains recipes that used by other recipes, but that are not directly 
+            included in images (i.e. depenendies of other recipes).
+        </para>
+    </section>
+
     <section id='structure-meta-site'>
         <title><filename class="directory">meta/site/</filename></title>
 
@@ -523,6 +605,14 @@
             passed to "autoconf" for the various architectures. 
         </para>
     </section>
+
+    <section id='structure-meta-recipes-txt'>
+        <title><filename class="directory">meta/recipes.txt/</filename></title>
+
+        <para>
+            This file is a description of the contents of <filename>recipes-*</filename>.
+        </para>
+    </section>
 </section>
 
 </appendix>

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

@@ -87,9 +87,22 @@
 
         <glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm>
             <glossdef>
-                <para>Assigns different priorities to recipe files in different layers. 
-                    This variable is useful in situations where the same package might appear in multiple layers.
-                    It allows you to choose what takes precedence.</para>
+                <para>Assigns different priorities to recipe files in different layers.</para>
+                <para>This variable is useful in situations where the same package appears in
+                    more than one layer. 
+                    Setting BBFILE_PRIORITY allows you to prioritize a
+                    layer against other layers that contain the same package - effectively
+                    letting you control the precedence for the multiple layers. 
+                    The precedence established through this variable stands regardless of a
+                    layer's package version (PV variable). 
+                    For example, a layer that has a package with a higher PV value but for 
+                    which the BBFILE_PRIORITY is set to have a lower precedence still has a 
+                    lower precedence.</para>
+                <para>A larger value for the BBFILE_PRIORITY variable results in a higher
+                    precedence. 
+                    For example, the value 6 has a higher precedence than the
+                    value 5. 
+                    By default, the BBFILE_PRIORITY variable is set to the value 5.</para>
             </glossdef>
         </glossentry>
 
@@ -284,6 +297,49 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-EXTRA_IMAGE_FEATURES'><glossterm>EXTRA_IMAGE_FEATURES</glossterm>
+            <glossdef>
+                <para>Allows extra packages to be added to the generated images.
+                    You set this variable in the <filename>local.conf</filename>
+                    configuration file.
+                    Note that some image features are also added using the 
+                    <link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link>
+                    variable generally configured in image recipes.
+                    You can use the EXTRA_IMAGE_FEATURES variable to add more features
+                    in addition to those.
+                    Here are some exmaples of features you can add:</para>
+                    <literallayout class='monospaced'>
+"dbg-pkgs" - Adds -dbg packages for all installed packages
+             including symbol information for debugging and 
+             profiling.
+
+"dev-pkgs" - Adds -dev packages for all installed packages.  
+             This is useful if you want to develop against 
+             the libraries in the image.
+
+"tools-sdk" - Adds development tools such as gcc, make, 
+              pkgconfig and so forth.
+
+"tools-debug" - Adds debugging tools such as gdb and 
+                strace.
+
+"tools-profile" - Adds profiling tools such as oprofile, 
+                  exmap, lttng and valgrind (x86 only).
+
+"tools-testapps" - Adds useful testing tools such as ts_print, 
+                   aplay, arecord and so forth.
+
+"debug-tweaks" - Makes an image suitable for development.  
+                 For example, ssh root access has a blank 
+                 password.  There are other application 
+                 targets too, see meta/classes/poky-image.bbclass
+                 and meta/packages/tasks/task-poky.bb 
+                 for more details.
+                    </literallayout> 
+
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-EXTRA_OECMAKE'><glossterm>EXTRA_OECMAKE</glossterm>
             <glossdef>
                 <para>Additional cmake options</para>
@@ -343,7 +399,11 @@
         <glossentry id='var-IMAGE_FEATURES'><glossterm>IMAGE_FEATURES</glossterm>
             <glossdef>
                 <para><link linkend="ref-features-image">List of
-                features</link> present in resulting images</para>
+                features</link> present in resulting images.
+                Typically you configure this variable in image recipes.
+                Note that you can add extra features to the image by using the
+                <link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link>
+                variable.</para>
             </glossdef>
         </glossentry>
 
@@ -766,6 +826,12 @@ recipes-graphics/xorg-font/fiont-alias_1.0.2.bb:PR - "$(INC_PR).0"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SSTATE_DIR'><glossterm>SSTATE_DIR</glossterm>
+            <glossdef>
+                <para>Directory for the shared state.</para>
+            </glossdef>
+
+        </glossentry>
         <glossentry id='var-SHELLCMDS'><glossterm>SHELLCMDS</glossterm>
             <glossdef>
                 <para>

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

@@ -97,7 +97,7 @@
                 <para><glossterm linkend='var-BBFILES'><link linkend='var-BBFILES'>BBFILES</link></glossterm></para>
             </listitem>
             <listitem>
-                <para><glossterm linkend='var-IMAGE_FEATURES'><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm></para>
+                <para><glossterm linkend='var-EXTRA_IMAGE_FEATURES'><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></glossterm></para>
             </listitem>
             <listitem>
                 <para><glossterm linkend='var-PACKAGE_CLASSES'><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></glossterm></para>

documentation/poky-ref-manual/resources.xml

@@ -74,10 +74,11 @@
             <ulink url='http://yoctoproject.org'>The Yocto Project website</ulink> - The home site
             for Yocto Project.
         </para></listitem>
-        <listitem><para>
+<!--        <listitem><para>
             <ulink url='http://pokylinux.org'>The Poky website</ulink> - The home site
             for Poky Linux.
         </para></listitem>
+-->
         <listitem><para>
             <ulink url='http://www.openedhand.com/'>OpenedHand</ulink> - The
             original company behind Poky.

documentation/poky-ref-manual/style.css

@@ -122,13 +122,13 @@ h6 {
   background-color: transparent;
   background-repeat: no-repeat;
   padding-top: 256px;
-  background-image: url("figures/poky-ref-manual.png");
+  background-image: url("figures/poky-title.png");
   background-position: left top;
   margin-top: -256px;
   padding-right: 50px;
-  margin-left: 50px;
+  margin-left: 0px;
   text-align: right;
-  width: 600px;
+  width: 740px;
 }
 
 h3.author {
@@ -771,12 +771,22 @@ 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 {
-  background-image: url("images/title-bg.png");
-  background-position: bottom;
-  background-repeat: repeat-x;
+div.chapter .titlepage .title,
+div.article .titlepage .title 
+{
 }
 
 div.section div.section .titlepage .title,
@@ -787,7 +797,7 @@ div.sect2 .titlepage .title {
 
 h1.title {
   background-color: transparent;
-  background-image: url("poky-ref-manual.png");
+  background-image: url("figures/poky-title.png");
   background-repeat: no-repeat;
   height: 256px;
   text-indent: -9000px;

documentation/poky-ref-manual/usingpoky.xml

@@ -73,6 +73,14 @@
             So for example, before building <filename>matchbox-desktop</filename> BitBake
             would build a cross compiler and glibc if they had not already been built.
         </para>
+        <para>
+            A useful BitBake option to consider is the <filename>-k</filename> or 
+            <filename>&dash;&dash;continue</filename> option.  
+            This option instructs BitBake to try and continue processing the job as much 
+            as possible even after encountering an error.  When an error occurs the target that
+            failed and those that depend on it cannot be remade.  However, when you use this
+            option other dependencies can still be processed.
+        </para>
 
     </section>
 
@@ -163,6 +171,12 @@
         only supported for minimal and base images.
         See <link linkend='ref-images'>'Reference: Images'</link> for more information.
     </note>
+    <note>
+        When building an image using GPL components you need to maintain your original 
+        settings and not switch back and forth applying different versions of the GNU
+        Public License.  If you rebuild using different versions of GPL you can get 
+        dependency errors due to some components not being rebuilt.
+    </note>
 </section>
 
 <section id='usingpoky-install'>

documentation/yocto-project-qs/Makefile

@@ -1,32 +0,0 @@
-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/yocto-project-qs.xml

@@ -13,9 +13,10 @@
     <title>Welcome!</title>
     <para>
         Welcome to the Yocto Project!  
-        The Yocto Project (YP) is an open-source collaboration project focused on embedded Linux
+        The Yocto Project 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.
+        Amongst other things, the Yocto Project 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 
@@ -46,7 +47,7 @@
         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,
+        You can use components from 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>
@@ -90,11 +91,11 @@
     </itemizedlist>
 
     <para>
-        Yocto Project can generate images for many kinds of devices.  
+        The 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
+        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 
+        Because an image developed with the Yocto Project can boot inside a QEMU emulator, the 
         development environment works nicely as a test platform for developing embedded software.
     </para>
 
@@ -102,7 +103,7 @@
         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. 
+        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>
@@ -118,7 +119,12 @@
     <itemizedlist>
         <listitem>
             <para>A host system running a supported Linux distribution (i.e. recent releases of
-                Fedora, OpenSUSE, Debian, and Ubuntu).</para>
+                Fedora, OpenSUSE, Debian, and Ubuntu).
+            <note>
+                For notes about using the Yocto Project on development systems that use 
+                older Linux distributions see 
+                <ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'></ulink>
+            </note></para>
         </listitem>
         <listitem>
             <para>The right packages.</para>
@@ -182,10 +188,15 @@
         <title>Yocto Project Release</title>
             
         <para>
-            The latest release images for the Yocto Project are kept at 
-            <ulink url="http://yoctoproject.org/downloads/yocto-1.0/"></ulink>.
-            Nightly and developmental builds are also maintained.  However, for this 
-            document a released version of Yocto Project is used.
+            You can download the latest release images for the Yocto Project on the 
+            <ulink url="http://yoctoproject.org/download">Yocto Project Download page</ulink>.
+            Just go to the page and click the "Yocto Downloads" link found in the "Download"
+            navigation pane to the right to view all available Yocto Project releases. 
+            Then, click the "Yocto Release" link for the release you want from the list to 
+            begin the download. 
+            Nightly and developmental builds are also maintained at
+            <ulink url="http://autobuilder.yoctoproject.org/nightly/"></ulink>.  
+            However, for this document a released version of Yocto Project is used.
         </para>
     </section>
 </section>
@@ -247,9 +258,9 @@
 
          <para>
              <literallayout class='monospaced'>
-     $ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2
-     $ tar xjf poky-bernard-5.0.tar.bz2
-     $ source poky-bernard-5.0/poky-init-build-env poky-5.0-build
+     $ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.2.tar.bz2
+     $ tar xjf poky-bernard-5.0.2.tar.bz2
+     $ source poky-bernard-5.0.2/poky-init-build-env poky-5.0.2-build
              </literallayout>
          </para>
 
@@ -259,7 +270,7 @@
              Adding this statement deletes the work directory used for building a package
              once the package is built.
              <literallayout class='monospaced'>
-     INHERIT += "rm_work"
+     INHERIT += rm_work
              </literallayout>
          </para></tip>
 
@@ -267,8 +278,8 @@
              <listitem><para>The first two commands extract the Yocto Project files from the 
              release tarball and place them into a subdirectory of your current directory.</para></listitem>
              <listitem><para>The <command>source</command> command creates the 
-             <filename>poky-5.0-build</filename> directory and executes the <command>cd</command>
-             command to make <filename>poky-5.0-build</filename> the working directory.
+             <filename>poky-5.0.2-build</filename> directory and executes the <command>cd</command>
+             command to make <filename>poky-5.0.2-build</filename> the working directory.
              The resulting build directory contains all the files created during the build.   
              By default the target architecture is qemux86.
              To change this default, edit the value of the MACHINE variable in the 
@@ -284,8 +295,12 @@
          <para>
              Continue with the following command to build an OS image for the target, which is 
              <filename>poky-image-sato</filename> in this example.
+             For information on the <filename>&dash;k</filename> option use the 
+             <filename>bitbake &dash;&dash;help</filename> command or see
+             <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>
+             BitBake</ulink> section in the Poky Reference Manual.
              <literallayout class='monospaced'>
-     $ bitbake poky-image-sato
+     $ bitbake -k poky-image-sato
              </literallayout>
              <note><para>
                  BitBake requires Python 2.6.  For more information on this requirement, 

meta-rt/recipes-kernel/linux-yocto-rt_stablegit.bb

@@ -8,7 +8,10 @@ LINUX_VERSION ?= "2.6.34"
 LINUX_KERNEL_TYPE = "preempt_rt"
 LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE_EXTENSION}"
 
-PR = "r0"
+KMETA = wrs_meta
+KBRANCH = ${KMACHINE}-${LINUX_KERNEL_TYPE}
+
+PR = "r1"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 SRCREV_FORMAT = "meta_machine"
 
@@ -18,16 +21,11 @@ COMPATIBLE_MACHINE = "(qemux86-64|atom-pc)"
 python __anonymous () {
     import bb, re, string
 
-    rev = bb.data.getVar("SRCREV_machine", d, 1)
-    if rev == "standard":
-        bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
-
     kerntype = string.replace(bb.data.expand("${LINUX_KERNEL_TYPE}", d), "_", "-")
     bb.data.setVar("LINUX_KERNEL_TYPE_EXTENSION", kerntype, d)
 }
 
-SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
-           git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
+SRC_URI = "git://git.yoctoproject.org/linux-2.6-windriver.git;protocol=git;nocheckout=1;branch=${KBRANCH},wrs_meta;name=machine,meta"
 
 # Functionality flags
 KERNEL_REVISION_CHECKING ?= "t"

meta-yocto/recipes-core/netbase/netbase-4.45/beagleboard/interfaces

@@ -0,0 +1,27 @@
+# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
+ 
+# The loopback interface
+auto lo
+iface lo inet loopback
+
+# Wireless interfaces
+iface wlan0 inet dhcp
+	wireless_mode managed
+	wireless_essid any
+	wpa-driver wext
+	wpa-conf /etc/wpa_supplicant.conf
+
+iface atml0 inet dhcp
+
+# Wired or wireless interfaces
+auto eth0
+iface eth0 inet dhcp
+iface eth1 inet dhcp
+
+# Ethernet/RNDIS gadget (g_ether) or LAN9514 on BeagleBoard xM
+auto usb0
+iface usb0 inet dhcp
+
+# Bluetooth networking
+iface bnep0 inet dhcp
+

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

@@ -0,0 +1,3 @@
+THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
+FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
+

meta/classes/boot-directdisk.bbclass

@@ -49,7 +49,7 @@ build_boot_dd() {
 	IMAGE=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect
 
 	install -d ${HDDDIR}
-	install -m 0644 ${STAGING_DIR}/${MACHINE}${HOST_VENDOR}-${HOST_OS}/kernel/bzImage ${HDDDIR}/vmlinuz
+	install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage ${HDDDIR}/vmlinuz
 	install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys ${HDDDIR}/ldlinux.sys
 
 	BLOCKS=`du -bks ${HDDDIR} | cut -f 1`

meta/classes/crosssdk.bbclass

@@ -9,6 +9,7 @@ TARGET_VENDOR = "${SDK_VENDOR}"
 TARGET_OS = "${SDK_OS}"
 TARGET_PREFIX = "${SDK_PREFIX}"
 TARGET_CC_ARCH = "${SDK_CC_ARCH}"
+TARGET_FPU = ""
 
 target_libdir = "${SDKPATHNATIVE}${libdir_nativesdk}"
 target_includedir = "${SDKPATHNATIVE}${includedir_nativesdk}"

meta/classes/image.bbclass

@@ -113,7 +113,8 @@ fakeroot do_rootfs () {
 
 	# Run ldconfig on the image to create a valid cache 
 	# (new format for cross arch compatibility)
-	ldconfig -r ${IMAGE_ROOTFS} -c new
+	echo executing: ldconfig -r ${IMAGE_ROOTFS} -c new -v
+	ldconfig -r ${IMAGE_ROOTFS} -c new -v
 
 	# (re)create kernel modules dependencies
 	# This part is done by kernel-module-* postinstall scripts but if image do

meta/classes/insane.bbclass

@@ -346,8 +346,12 @@ def package_qa_check_license(workdir, d):
     sane = True
 
     lic_files = bb.data.getVar('LIC_FILES_CHKSUM', d, True)
+    lic = bb.data.getVar('LICENSE', d, True)
     pn = bb.data.getVar('PN', d, True)
 
+    if lic == "CLOSED":
+        return True
+
     if not lic_files:
         # just throw a warning now. Once licensing data in entered for enough of the recipes,
         # this will be converted into error and False will be returned.

meta/classes/native.bbclass

@@ -22,6 +22,7 @@ TARGET_OS = "${BUILD_OS}"
 TARGET_VENDOR = "${BUILD_VENDOR}"
 TARGET_PREFIX = "${BUILD_PREFIX}"
 TARGET_CC_ARCH = "${BUILD_CC_ARCH}"
+TARGET_FPU = ""
 
 HOST_ARCH = "${BUILD_ARCH}"
 HOST_OS = "${BUILD_OS}"

meta/classes/nativesdk.bbclass

@@ -34,6 +34,7 @@ TARGET_VENDOR = "${SDK_VENDOR}"
 TARGET_OS = "${SDK_OS}"
 TARGET_PREFIX = "${SDK_PREFIX}"
 TARGET_CC_ARCH = "${SDK_CC_ARCH}"
+TARGET_FPU = ""
 
 CPPFLAGS = "${BUILDSDK_CPPFLAGS}"
 CFLAGS = "${BUILDSDK_CFLAGS}"

meta/classes/package_rpm.bbclass

@@ -763,6 +763,7 @@ python do_package_rpm () {
 	targetsys = bb.data.getVar('TARGET_SYS', d, True)
 	pkgwritedir = bb.data.expand('${PKGWRITEDIRRPM}/${PACKAGE_ARCH}', d)
 	pkgarch = bb.data.expand('${PACKAGE_ARCH}', d)
+	magicfile = bb.data.expand('${STAGING_DIR_NATIVE}/usr/share/misc/magic.mgc', d)
 	bb.mkdirhier(pkgwritedir)
 	os.chmod(pkgwritedir, 0755)
 
@@ -775,18 +776,13 @@ python do_package_rpm () {
 	cmd = cmd + " --define '__find_provides " + outprovides + "'"
 	cmd = cmd + " --define '_unpackaged_files_terminate_build 0'"
 	cmd = cmd + " --define 'debug_package %{nil}'"
+	cmd = cmd + " --define '_rpmfc_magic_path " + magicfile + "'"
 	cmd = cmd + " -bb " + outspecfile
 
-	# Take a shared lock, we can write multiple packages at the same time...
-	# but we need to stop the rootfs/solver from running while we do...
-	lf = bb.utils.lockfile(bb.data.expand("${DEPLOY_DIR_RPM}/rpm.lock", d), True)
-
 	# Build the rpm package!
 	bb.data.setVar('BUILDSPEC', cmd + "\n", d)
 	bb.data.setVarFlag('BUILDSPEC', 'func', '1', d)
 	bb.build.exec_func('BUILDSPEC', d)
-
-	bb.utils.unlockfile(lf)
 }
 
 python () {
@@ -803,6 +799,9 @@ SSTATETASKS += "do_package_write_rpm"
 do_package_write_rpm[sstate-name] = "deploy-rpm"
 do_package_write_rpm[sstate-inputdirs] = "${PKGWRITEDIRRPM}"
 do_package_write_rpm[sstate-outputdirs] = "${DEPLOY_DIR_RPM}"
+# Take a shared lock, we can write multiple packages at the same time...
+# but we need to stop the rootfs/solver from running while we do...
+do_package_write_rpm[sstate-lockfile-shared] += "${DEPLOY_DIR_RPM}/rpm.lock"
 
 python do_package_write_rpm_setscene () {
 	sstate_setscene(d)

meta/classes/sanity.bbclass

@@ -168,7 +168,7 @@ def check_sanity(e):
     if not check_app_exists('${BUILD_PREFIX}g++', e.data):
         missing = missing + "C++ Compiler (%sg++)," % data.getVar("BUILD_PREFIX", e.data, True)
 
-    required_utilities = "patch help2man diffstat texi2html makeinfo cvs svn bzip2 tar gzip gawk hg chrpath wget"
+    required_utilities = "patch help2man diffstat texi2html makeinfo cvs svn bzip2 tar gzip gawk hg chrpath wget cpio"
 
     # qemu-native needs gcc 3.x
     if "qemu-native" not in assume_provided and "gcc3-native" in assume_provided:

meta/classes/sstate.bbclass

@@ -39,8 +39,10 @@ python () {
         scan_cmd = "grep -Irl ${STAGING_DIR} ${SSTATE_BUILDDIR}"
         bb.data.setVar('SSTATE_SCAN_CMD', scan_cmd, d)
 
+    unique_tasks = set((bb.data.getVar('SSTATETASKS', d, True) or "").split())
+    d.setVar('SSTATETASKS', " ".join(unique_tasks))
     namemap = []
-    for task in (bb.data.getVar('SSTATETASKS', d, True) or "").split():
+    for task in unique_tasks:
         namemap.append(bb.data.getVarFlag(task, 'sstate-name', d))
         funcs = bb.data.getVarFlag(task, 'prefuncs', d) or ""
         funcs = "sstate_task_prefunc " + funcs
@@ -58,6 +60,7 @@ def sstate_init(name, task, d):
     ss['dirs'] = []
     ss['plaindirs'] = []
     ss['lockfiles'] = []
+    ss['lockfiles-shared'] = []
     return ss
 
 def sstate_state_fromvars(d, task = None):
@@ -72,6 +75,7 @@ def sstate_state_fromvars(d, task = None):
     outputs = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-outputdirs', d) or "", d)).split()
     plaindirs = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-plaindirs', d) or "", d)).split()
     lockfiles = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-lockfile', d) or "", d)).split()
+    lockfilesshared = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-lockfile-shared', d) or "", d)).split()
     interceptfuncs = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-interceptfuncs', d) or "", d)).split()
     if not name or len(inputs) != len(outputs):
         bb.fatal("sstate variables not setup correctly?!")
@@ -80,6 +84,7 @@ def sstate_state_fromvars(d, task = None):
     for i in range(len(inputs)):
         sstate_add(ss, inputs[i], outputs[i], d)
     ss['lockfiles'] = lockfiles
+    ss['lockfiles-shared'] = lockfilesshared
     ss['plaindirs'] = plaindirs
     ss['interceptfuncs'] = interceptfuncs
     return ss
@@ -101,6 +106,8 @@ def sstate_install(ss, d):
         bb.fatal("Package already staged (%s)?!" % manifest)
 
     locks = []
+    for lock in ss['lockfiles-shared']:
+        locks.append(bb.utils.lockfile(lock, True))
     for lock in ss['lockfiles']:
         locks.append(bb.utils.lockfile(lock))
 
@@ -231,6 +238,8 @@ def sstate_clean(ss, d):
 
     if os.path.exists(manifest):
         locks = []
+        for lock in ss['lockfiles-shared']:
+            locks.append(bb.utils.lockfile(lock, True))
         for lock in ss['lockfiles']:
             locks.append(bb.utils.lockfile(lock))
 

meta/conf/bitbake.conf

@@ -92,9 +92,9 @@ SDK_CC_ARCH = "${BUILD_CC_ARCH}"
 
 BASE_PACKAGE_ARCH = "${HOST_ARCH}"
 PACKAGE_ARCH = "${BASE_PACKAGE_ARCH}"
-MACHINE_ARCH = "${@[bb.data.getVar('BASE_PACKAGE_ARCH', d, 1), bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 1))]}"
-MACHINE_ARCH_qemux86-64 = "qemux86_64"
-PACKAGE_ARCHS = "all any noarch ${TARGET_ARCH} ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}"
+MACHINE_ARCH = "${@[bb.data.getVar('BASE_PACKAGE_ARCH', d, 1), bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 1))].replace('-', '_')}"
+PACKAGE_EXTRA_ARCHS ??= "${TARGET_ARCH}"
+PACKAGE_ARCHS = "all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}"
 # MACHINE shouldn't be included here as a variable dependency since machine specific 
 # packages are handled using multimachine
 PACKAGE_ARCHS[vardepsexclude] = "MACHINE"

meta/conf/distro/include/poky-default-revisions.inc

@@ -86,17 +86,17 @@ SRCREV_pn-linux-omap-zoomsync ??= "015cbaf1035cd9a61d33a27de2a22902555db3c5"
 SRCREV_pn-linux-omap2 ??= "d3b3ae0fe6c71641da19c8de466ec366d39847e3"
 SRCREV_pn-linux-omap3 ??= "de1121fdb899f762b9e717f44eaf3fae7c00cd3e"
 SRCREV_pn-linux-omap3-pm ??= "totallybroken"
-SRCREV_machine_pn-linux-yocto-stable_qemuarm ?= "a2fb081b44d6368eff8d28e2fdb991c61b1f428e"
-SRCREV_machine_pn-linux-yocto-stable_qemumips ?= "c32d40f960e3c89d07f079bec4c96dcbfc749f0b"
-SRCREV_machine_pn-linux-yocto-stable_qemuppc ?= "96d6bc31d3caaf62a966255479cc5cee0e76b1e9"
-SRCREV_machine_pn-linux-yocto-stable_qemux86 ?= "72ca49ab08b8eb475cec82a10049503602325791"
-SRCREV_machine_pn-linux-yocto-stable_qemux86-64 ?= "72ca49ab08b8eb475cec82a10049503602325791"
-SRCREV_machine_pn-linux-yocto-stable_atom-pc ?= "72ca49ab08b8eb475cec82a10049503602325791"
-SRCREV_machine_pn-linux-yocto-stable_routerstationpro ?= "49745cd45c92a89e70c6e2334caa80818c134562"
-SRCREV_machine_pn-linux-yocto-stable_mpc8315e-rdb ?= "a1c0ed6bf4060c10874b2a8547d81b3169dcf16a"
-SRCREV_machine_pn-linux-yocto-stable_beagleboard ?= "ef7f944e773950d4016b7643f9ecf052bbe250cd"
-SRCREV_machine_pn-linux-yocto-stable ?= "72ca49ab08b8eb475cec82a10049503602325791"
-SRCREV_meta_pn-linux-yocto-stable ?= "e1f85a470934a0cf6abde5d95533e74501822c6b"
+SRCREV_machine_pn-linux-yocto-stable_qemuarm ?= "24305dfe5a7c4eadb0160b565442991c2a4598e6"
+SRCREV_machine_pn-linux-yocto-stable_qemumips ?= "872453662305b0c14cc87480f7c96168ff36481e"
+SRCREV_machine_pn-linux-yocto-stable_qemuppc ?= "11affb88242d373b5bf4039b771e3872b428e3d2"
+SRCREV_machine_pn-linux-yocto-stable_qemux86 ?= "adea8c9cce0ffff0f10abe3257382c1190f0f569"
+SRCREV_machine_pn-linux-yocto-stable_qemux86-64 ?= "adea8c9cce0ffff0f10abe3257382c1190f0f569"
+SRCREV_machine_pn-linux-yocto-stable_atom-pc ?= "adea8c9cce0ffff0f10abe3257382c1190f0f569"
+SRCREV_machine_pn-linux-yocto-stable_routerstationpro ?= "4e8cefebccb235de37199a7644a89ead1fc0b2fa"
+SRCREV_machine_pn-linux-yocto-stable_mpc8315e-rdb ?= "9bf8e1497b853a5d556e94febf8185c380e6a2d3"
+SRCREV_machine_pn-linux-yocto-stable_beagleboard ?= "f3e11c02c4d62d9a3c00abd2048c0b6cf007d988"
+SRCREV_machine_pn-linux-yocto-stable ?= "adea8c9cce0ffff0f10abe3257382c1190f0f569"
+SRCREV_meta_pn-linux-yocto-stable ?= "ec26387cb168e9e0976999b528b5a9dd62e3157a"
 # development SRCREVs
 SRCREV_machine_pn-linux-yocto_qemuarm ?= "233213a1e09eae3de7047ff406b156608788ec17"
 SRCREV_machine_pn-linux-yocto_qemumips ?= "54bb956f70349923af29f28a4f9471f5658e1787"
@@ -177,12 +177,10 @@ TRACECMDREV ?= "6c696cec3f264a9399241b6e648f58bc97117d49"
 SRCREV_pn-trace-cmd ??= ${TRACECMDREV}
 SRCREV_pn-kernelshark ??= ${TRACECMDREV}
 SRCREV_pn-tidy ??= "e25416e1293e1074bfa6727c80527dcff5b1f3cb"
-SRCREV_pn-u-boot-omap3 ??= "f40f6db278f602b55820693634a7256b0b4e4b80"
-SRCREV_pn-u-boot ??= "v2010.12"
 SRCREV_pn-ubootchart ??= "10"
 SRCREV_pn-webkit-gtk ??= "72836"
 SRCREV_pn-web-webkit ??= "130"
-SRCREV_pn-web ??= "129"
+SRCREV_pn-web ??= "8adaf105a0cbfd835ea5d3915d7dee22586208e7"
 SRCREV_pn-xcb-proto ??= "d81ca233e98be8fa59e8c90d262c0516944c5a66"
 SRCREV_pn-xcb-proto-native ??= "d81ca233e98be8fa59e8c90d262c0516944c5a66"
 SRCREV_pn-xf86-video-intel ??= "87ea531c5dc5b39809395b277c330854aaaaf019"
@@ -200,4 +198,4 @@ SRCDATE_yaffs2-utils-native ??= "20071107"
 SRCDATE_yaffs2-utils ??= "20071107"
 SRCREV_pn-zaurusd ??= "426"
 SRCREV_pn-zypper ??= "2c5bb6ceb99ecd950ef993e43d77bf0569ea0582"
-
+SRCREV_pn-u-boot ??= "19b54a701811220221fc4d5089a2bb18892018ca"

meta/conf/distro/poky.conf

@@ -2,8 +2,8 @@
 #@DESCRIPTION: Distribution configuration for the Yocto Project build by Poky
 
 DISTRO = "poky"
-DISTRO_NAME = "Yocto (Built by Poky 5.0)"
-DISTRO_VERSION = "1.0"
+DISTRO_NAME = "Yocto (Built by Poky 5.0.2)"
+DISTRO_VERSION = "1.0.2"
 SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
 
 MAINTAINER = "Poky <poky@yoctoproject.org>"
@@ -117,6 +117,8 @@ POKY_EXTRA_RDEPENDS = "task-poky-boot"
 POKY_EXTRA_RDEPENDS_qemuarm = "qemu-config"
 POKY_EXTRA_RDEPENDS_qemuarmv6 = "qemu-config"
 POKY_EXTRA_RDEPENDS_qemuarmv7 = "qemu-config"
+POKY_EXTRA_RDEPENDS_qemumips = "qemu-config"
+POKY_EXTRA_RDEPENDS_qemuppc = "qemu-config"
 POKY_EXTRA_RDEPENDS_qemux86 = "qemu-config"
 POKY_EXTRA_RDEPENDS_qemux86-64 = "qemu-config"
 
@@ -151,17 +153,17 @@ BB_GENERATE_MIRROR_TARBALLS ??= "0"
 require conf/distro/include/world-broken.inc
 
 PREMIRRORS ?= "\
-bzr://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
-cvs://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
-git://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
-hg://.*/.*    http://autobuilder.yoctoproject.org/sources/ \n \
-osc://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
-p4://.*/.*    http://autobuilder.yoctoproject.org/sources/ \n \
-svk://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
-svn://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n"
+bzr://.*/.*   http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n \
+cvs://.*/.*   http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n \
+git://.*/.*   http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n \
+hg://.*/.*    http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n \
+osc://.*/.*   http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n \
+p4://.*/.*    http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n \
+svk://.*/.*   http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n \
+svn://.*/.*   http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n"
 
 MIRRORS =+ "\
-ftp://.*/.*      http://autobuilder.yoctoproject.org/sources/ \n \
-http://.*/.*     http://autobuilder.yoctoproject.org/sources/ \n \
-https://.*/.*    http://autobuilder.yoctoproject.org/sources/ \n"
+ftp://.*/.*      http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n \
+http://.*/.*     http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n \
+https://.*/.*    http://downloads.yoctoproject.org/releases/yocto/yocto-1.0/sources/ \n"
 

meta/recipes-bsp/keymaps/keymaps_1.0.bb

@@ -4,8 +4,8 @@ SECTION = "base"
 RDEPENDS_${PN} = "initscripts console-tools"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
-PACKAGE_ARCH = "${MACHINE}"
-PR = "r17"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+PR = "r18"
 
 inherit update-rc.d
 

meta/recipes-bsp/qemu-config/qemu-config.bb

@@ -15,7 +15,7 @@ SRC_URI = "file://distcc.sh \
 
 S = "${WORKDIR}"
 
-COMPATIBLE_MACHINE = "(qemuarm|qemux86)"
+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemumips|qemuppc)"
 PACKAGE_ARCH = "all"
 
 do_install() {

meta/recipes-bsp/uboot/u-boot_git.bb

@@ -6,8 +6,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb \
 
 FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/u-boot-git/${MACHINE}"
 
-PV = "v2010.12+${PR}+git${SRCPV}"
-PR="r1"
+PV = "v2011.03+git${SRCPV}"
+PR="r3"
 
 SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
 

meta/recipes-bsp/zaurusd/zaurusd/fix_makefile.patch

@@ -0,0 +1,19 @@
+Upstream-Status: Pending
+
+Nitin A Kamble <nitin.a.kamble@intel.com> 2011/05/10
+Fix following build error:
+
+| Makefile:716: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
+| ERROR: oe_runmake failed
+
+Index: zaurusd/Makefile.am
+===================================================================
+--- zaurusd.orig/Makefile.am
++++ zaurusd/Makefile.am
+@@ -4,5 +4,5 @@ SUBDIRS = apps config scripts
+ MAINTAINERCLEANFILES = aclocal.m4 compile config.guess config.sub configure depcomp install-sh ltmain.sh Makefile.in missing
+ 
+ snapshot:
+-        $(MAKE) dist distdir=$(PACKAGE)-snap`date +"%Y%m%d"`
++	$(MAKE) dist distdir=$(PACKAGE)-snap`date +"%Y%m%d"`
+ 

meta/recipes-bsp/zaurusd/zaurusd_svn.bb

@@ -5,9 +5,10 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 DEPENDS = "tslib"
 RDEPENDS_${PN} = "xrandr"
 PV = "0.0+svnr${SRCPV}"
-PR = "r2"
+PR = "r3"
 
-SRC_URI = "svn://svn.o-hand.com/repos/misc/trunk;module=zaurusd;proto=http"
+SRC_URI = "svn://svn.o-hand.com/repos/misc/trunk;module=zaurusd;proto=http \
+	file://fix_makefile.patch"
 
 S = "${WORKDIR}/${PN}"
 

meta/recipes-connectivity/avahi/avahi.inc

@@ -22,7 +22,7 @@ RRECOMMENDS_avahi-daemon = "libnss-mdns"
 SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
         file://00avahi-autoipd \
         file://99avahi-autoipd \
-        file://initscript.patch;patch=1"
+        file://initscript.patch"
 
 inherit autotools pkgconfig update-rc.d gettext
 

meta/recipes-connectivity/avahi/avahi_0.6.30.bb

@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
                     file://avahi-client/client.h;endline=23;md5=f4ac741a25c4f434039ba3e18c8674cf"
 
 RDEPENDS_avahi-daemon = "sysvinit-pidof"
-PR = "r2"
+PR = "r0"
 
 EXTRA_OECONF += "--disable-gtk3"
 
@@ -15,5 +15,5 @@ FILES_avahi-autoipd = "${sbindir}/avahi-autoipd \
                        ${sysconfdir}/avahi/avahi-autoipd.action \
 		       ${sysconfdir}/dhcp3/*/avahi-autoipd"
 
-SRC_URI[md5sum] = "d0143a5aa3265019072e53ab497818d0"
-SRC_URI[sha256sum] = "a0d80aac88212b9f9d5331c248091d3c9c9209f0e41985421636ebd14230fc91"
+SRC_URI[md5sum] = "e4db89a2a403ff4c47d66ac66fad1f43"
+SRC_URI[sha256sum] = "f9e4316c2339d0020726edd846d01bee0c39980906db0c247479e5807457ff1f"

meta/recipes-connectivity/avahi/files/initscript.patch

@@ -1,3 +1,5 @@
+Upstream-Status: Pending
+
 diff --git a/initscript/debian/avahi-daemon.in b/initscript/debian/avahi-daemon.in
 index 30a2c2f..b5848a8 100755
 --- a/initscript/debian/avahi-daemon.in

meta/recipes-connectivity/openssl/openssl-0.9.8r/configure-targets.patch

@@ -1,3 +1,4 @@
+Upstream-Status: Inappropriate [embedded specific]
 
 The number of colons are important :)