linux-yocto: add crownbay BSP infrastructure

Updating the meta SRCREV to grab this linux-yocto commit: meta: add crownbay BSP infrastructure Import the 2.6.34 crownbay infrastructure and update for the 2.6.37 kernel. This also brings in the feature/drm-emgd that the crownbay requires. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Merge branch 'bernard' of ssh://git.pokylinux.org/poky into bernard-1.0
2026-02-20 08:29:42 +01:00 · 2011-02-26 14:30:34 -08:00 · 2011-02-26 14:29:21 -08:00 · 2011-02-26 10:50:15 -08:00
2424 changed files with 63990 additions and 771958 deletions
--- a/.gitignore
+++ b/.gitignore
@@ -7,16 +7,31 @@ build/tmp/
 build/sstate-cache
 build/pyshtables.py
 pstage/
-scripts/oe-git-proxy-socks
+scripts/poky-git-proxy-socks
 sources/
 meta-darwin
 meta-maemo
 meta-extras
 meta-m2
 meta-prvt*
+poky-autobuilder*
 *.swp
 *.orig
 *.rej
 *~
+documentation/poky-ref-manual/poky-ref-manual.html
+documentation/poky-ref-manual/poky-ref-manual.pdf
+documentation/poky-ref-manual/poky-ref-manual.tgz
+documentation/poky-ref-manual/bsp-guide.html
+documentation/poky-ref-manual/bsp-guide.pdf
+documentation/bsp-guide/bsp-guide.html
+documentation/bsp-guide/bsp-guide.pdf
+documentation/bsp-guide/bsp-guide.tgz
+documentation/yocto-project-qs/yocto-project-qs.html
+documentation/yocto-project-qs/yocto-project-qs.tgz
+documentation/kernel-manual/kernel-manual.html
+documentation/kernel-manual/kernel-manual.tgz
+documentation/kernel-manual/kernel-manual.pdf
+


--- a/30
+++ b/30
@@ -1,25 +1,15 @@
 Poky
 ====

-Poky is an integration of various components to form a complete prepackaged
-build system and development environment. It features support for building
-customised embedded device style images. There are reference demo images
-featuring a X11/Matchbox/GTK themed UI called Sato. The system supports
-cross-architecture application development using QEMU emulation and a
-standalone toolchain and SDK with IDE integration.
+Poky platform builder is a combined cross build system and development 
+environment. It features support for building X11/Matchbox/GTK based 
+filesystem images for various embedded devices and boards. It also 
+supports cross-architecture application development using QEMU emulation
+and a standalone toolchain and SDK with IDE integration.
+
+Poky has an extensive handbook, the source of which is contained in
+the handbook directory. For compiled HTML or pdf versions of this, 
+see the Poky website http://pokylinux.org.

 Additional information on the specifics of hardware that Poky supports
-is available in README.hardware. Further hardware support can easily be added
-in the form of layers which extend the systems capabilities in a modular way.
-
-As an integration layer Poky consists of several upstream projects such as 
-BitBake, OpenEmbedded-Core, Yocto documentation and various sources of information 
-e.g. for the hardware support. Poky is in turn a component of the Yocto Project.
-
-The Yocto Project has extensive documentation about the system including a 
-reference manual which can be found at:
-    http://yoctoproject.org/community/documentation
-
-For information about OpenEmbedded see their website:
-    http://www.openembedded.org/
-
+is available in README.hardware.
--- a/README.hardware
+++ b/README.hardware
@@ -1,66 +1,429 @@
-                          Poky Hardware README
-                          ====================
+                     Poky Hardware Reference Guide
+                     =============================

 This file gives details about using Poky with different hardware reference
-boards and consumer devices. A full list of target machines can be found by
-looking in the meta/conf/machine/ directory. If in doubt about using Poky with
-your hardware, consult the documentation for your board/device.
+boards and consumer devices. A full list of target machines can be found by 
+looking in the meta/conf/machine/ directory. If in doubt about using Poky with 
+your hardware, consult the documentation for your board/device. To discuss 
+support for further hardware reference boards/devices please contact OpenedHand.

-Support for additional devices is normally added by creating BSP layers - for
-more information please see the Yocto Board Support Package (BSP) Developer's
-Guide - documentation source is in documentation/bspguide or download the PDF
-from:
-
-   http://yoctoproject.org/community/documentation
-
-Support for machines other than QEMU may be moved out to separate BSP layers in
-future versions.
-
-
-QEMU Emulation Targets
-======================
+QEMU Emulation Images (qemuarm and qemux86)
+===========================================

 To simplify development Poky supports building images to work with the QEMU
-emulator in system emulation mode. Several architectures are currently
-supported:
-
-  * ARM (qemuarm)
-  * x86 (qemux86)
-  * x86-64 (qemux86-64)
-  * PowerPC (qemuppc)
-  * MIPS (qemumips)
-
-Use of the QEMU images is covered in the Poky Reference Manual. The Poky
-MACHINE setting corresponding to the target is given in brackets.
-
+emulator in system emulation mode. Two architectures are currently supported,
+ARM (via qemuarm) and x86 (via qemux86). Use of the QEMU images is covered
+in the Poky Handbook.

 Hardware Reference Boards
 =========================

-The following boards are supported by Poky's core layer:
+The following boards are supported by Poky:

+  * Compulab CM-X270 (cm-x270)
+  * Compulab EM-X270 (em-x270)
+  * FreeScale iMX31ADS (mx31ads)
+  * Marvell PXA3xx Zylonite (zylonite)
+  * Logic iMX31 Lite Kit (mx31litekit)
+  * Phytec phyCORE-iMX31 (mx31phy)
  * Texas Instruments Beagleboard (beagleboard)
-  * Freescale MPC8315E-RDB (mpc8315e-rdb)
-  * Ubiquiti Networks RouterStation Pro (routerstationpro)

-For more information see the board's section below. The Poky MACHINE setting
+For more information see board's section below. The Poky MACHINE setting
 corresponding to the board is given in brackets.

-
 Consumer Devices
 ================

-The following consumer devices are supported by Poky's core layer:
+The following consumer devices are supported by Poky:

-  * Intel Atom based PCs and devices (atom-pc)
+  * FIC Neo1973 GTA01 smartphone (fic-gta01)
+  * HTC Universal (htcuniversal)
+  * Nokia 770/N800/N810 Internet Tablets (nokia770 and nokia800)
+  * Sharp Zaurus SL-C7x0 series (c7x0)
+  * Sharp Zaurus SL-C1000 (akita)
+  * Sharp Zaurus SL-C3x00 series (spitz)

-For more information see the device's section below. The Poky MACHINE setting
-corresponding to the device is given in brackets.
+For more information see board's section below. The Poky MACHINE setting
+corresponding to the board is given in brackets.


+                          Hardware Reference Boards
+                          =========================

-                      Specific Hardware Documentation
-                      ===============================
+Compulab CM-X270 (cm-x270)
+==========================
+
+The bootloader on this board doesn't support writing jffs2 images directly to 
+NAND and normally uses a proprietary kernel flash driver. To allow the use of
+jffs2 images, a two stage updating procedure is needed. Firstly, an initramfs
+is booted which contains mtd utilities and this is then used to write the main
+filesystem. 
+
+It is assumed the board is connected to a network where a TFTP server is 
+available and that a serial terminal is available to communicate with the 
+bootloader (38400, 8N1). If a DHCP server is available the device will use it
+to obtain an IP address. If not, run:
+
+  ARMmon > setip dhcp off
+  ARMmon > setip ip 192.168.1.203
+  ARMmon > setip mask 255.255.255.0
+
+To reflash the kernel:
+
+  ARMmon > download kernel tftp zimage 192.168.1.202
+  ARMmon > flash kernel
+
+where zimage is the name of the kernel on the TFTP server and its IP address is 
+192.168.1.202. The names of the files must be all lowercase.
+
+To reflash the initrd/initramfs:
+
+  ARMmon > download ramdisk tftp diskimage 192.168.1.202
+  ARMmon > flash ramdisk
+
+where diskimage is the name of the initramfs image (a cpio.gz file).
+
+To boot the initramfs:
+
+  ARMmon > ramdisk on
+  ARMmon > bootos "console=ttyS0,38400 rdinit=/sbin/init"
+
+To reflash the main image login to the system as user "root", then run:
+
+  # ifconfig eth0 192.168.1.203
+  # tftp -g -r mainimage 192.168.1.202
+  # flash_eraseall /dev/mtd1
+  # nandwrite /dev/mtd1 mainimage
+
+which configures the network interface with the IP address 192.168.1.203,
+downloads the "mainimage" file from the TFTP server at 192.168.1.202, erases
+the flash and then writes the new image to the flash.
+
+The main image can then be booted with:
+
+  ARMmon > bootos "console=ttyS0,38400 root=/dev/mtdblock1 rootfstype=jffs2"
+
+Note that the initramfs image is built by poky in a slightly different mode to
+normal since it uses uclibc. To generate this use a command like:
+
+IMAGE_FSTYPES=cpio.gz MACHINE=cm-x270 POKYLIBC=uclibc bitbake poky-image-minimal-mtdutils
+
+
+Compulab EM-X270 (em-x270)
+==========================
+
+Fetch the "Linux - kernel and run-time image (Angstrom)" ZIP file from the
+Compulab website. Inside the images directory of this ZIP file is another ZIP
+file called 'LiveDisk.zip'. Extract this over a cleanly formatted vfat USB flash
+drive. Replace the 'em_x270.img' file with the 'updater-em-x270.ext2' file.
+
+Insert this USB disk into the supplied adapter and connect this to the
+board. Whilst holding down the the suspend button press the reset button. The
+board will now boot off the USB key and into a version of Angstrom. On the
+desktop is an icon labelled "Updater". Run this program to launch the updater
+that will flash the Poky kernel and rootfs to the board.
+
+
+FreeScale iMX31ADS (mx31ads)
+===========================
+
+The correct serial port is the top-most female connector to the right of the
+ethernet socket.
+
+For uploading data to RedBoot we are going to use tftp. In this example we
+assume that the tftpserver is on 192.168.9.1 and the board is on192.168.9.2. 
+
+To set the IP address, run:
+
+  ip_address -l 192.168.9.2/24 -h 192.168.9.1
+
+To download a kernel called "zimage" from the TFTP server, run:
+
+  load -r -b 0x100000 zimage
+
+To write the kernel to flash run:
+
+  fis create kernel
+
+To download a rootfs jffs2 image "rootfs" from the TFTP server, run:
+
+  load -r -b 0x100000 rootfs
+
+To write the root filesystem  to flash run:
+
+  fis create root
+
+To load and boot a kernel and rootfs from flash:
+
+  fis load kernel
+  exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rootfstype=jffs2 init=linuxrc ip=none"
+
+To load and boot a kernel from a TFTP server with the rootfs over NFS:
+
+  load -r -b 0x100000 zimage
+  exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=192.168.9.1:/mnt/nfsmx31 rw ip=192.168.9.2::192.168.9.1:255.255.255.0"
+
+The instructions above are for using the (default) NOR flash on the board,
+there is also 128M of NAND flash. It is possible to install Poky to the NAND 
+flash which gives more space for the rootfs and instructions for using this are
+given below. To switch to the NAND flash:
+
+  factive NAND
+
+This will then restart RedBoot using the NAND rather than the NOR. If you
+have not used the NAND before then it is unlikely that there will be a
+partition table yet. You can get the list of partitions with 'fis list'.
+
+If this shows no partitions then you can create them with:
+
+  fis init
+
+The output of 'fis list' should now show:
+
+Name              FLASH addr  Mem addr    Length      Entry point
+RedBoot           0xE0000000  0xE0000000  0x00040000  0x00000000
+FIS directory     0xE7FF4000  0xE7FF4000  0x00003000  0x00000000
+RedBoot config    0xE7FF7000  0xE7FF7000  0x00001000  0x00000000
+
+Partitions for the kernel and rootfs need to be created:
+
+fis create -l 0x1A0000 -e 0x00100000 kernel
+fis create -l 0x5000000 -e 0x00100000 root
+
+You may now use the instructions above for flashing. However it is important
+to note that the erase block size for the NAND is different to the NOR so the
+JFFS erase size will need to be changed to 0x4000. Stardard images are built
+for NOR and you will need to build custom images for NAND.
+
+You will also need to update the kernel command line to use the correct root
+filesystem. This should be '/dev/mtdblock7' if you adhere to the partitioning
+scheme shown above. If this fails then you can doublecheck against the output
+from the kernel when it evaluates the available mtd partitions.
+
+
+Marvell PXA3xx Zylonite (zylonite)
+==================================
+
+These instructions assume the Zylonite is connected to a machine running a TFTP 
+server at address 192.168.123.5 and that a serial link (38400 8N1) is available 
+to access the blob bootloader. The kernel is on the TFTP server as 
+"zylonite-kernel" and the root filesystem jffs2 file is "zylonite-rootfs" and 
+the images are to be saved in NAND flash.
+
+The following commands setup blob:
+
+  blob> setip client 192.168.123.4
+  blob> setip server 192.168.123.5
+
+To flash the kernel:
+
+  blob> tftp zylonite-kernel
+  blob> nandwrite -j 0x80800000 0x60000 0x200000
+
+To flash the rootfs:
+
+  blob> tftp zylonite-rootfs
+  blob> nanderase -j 0x260000 0x5000000
+  blob> nandwrite -j 0x80800000 0x260000 <length>
+
+(where <length> is the rootfs size which will be printed by the tftp step)
+
+To boot the board:
+
+  blob> nkernel
+  blob> boot
+
+
+Logic iMX31 Lite Kit (mx31litekit)
+===============================
+
+The easiest method to boot this board is to take an MMC/SD card and format 
+the first partition as ext2, then extract the poky image onto this as root. 
+Assuming the board is network connected, a TFTP server is available at 
+192.168.1.33 and a serial terminal is available (115200 8N1), the following 
+commands will boot a kernel called "mx31kern" from the TFTP server:
+
+  losh> ifconfig sm0 192.168.1.203 255.255.255.0 192.168.1.33
+  losh> load raw 0x80100000 0x200000 /tftp/192.168.1.33:mx31kern
+  losh> exec 0x80100000 - 
+
+
+Phytec phyCORE-iMX31 (mx31phy)
+==============================
+
+Support for this board is currently being developed. Experimental jffs2 
+images and a suitable kernel are available and are known to work with the
+board.
+
+
+                             Consumer Devices
+                             ================
+
+FIC Neo1973 GTA01 smartphone (fic-gta01)
+========================================
+
+To install Poky on a GTA01 smartphone you will need "dfu-util" tool
+which you can build with "bitbake dfu-util-native" command.
+
+Flashing requires these steps:
+
+  1. Power down the device.
+  2. Connect the device to the host machine via USB.
+  3. Hold AUX key and press Power key. There should be a bootmenu
+     on screen.
+  4. Run "dfu-util -l" to check if the phone is visible on the USB bus. 
+     The output should look like this:
+
+     dfu-util - (C) 2007 by OpenMoko Inc.
+     This program is Free Software and has ABSOLUTELY NO WARRANTY
+
+     Found Runtime: [0x1457:0x5119] devnum=19, cfg=0, intf=2, alt=0, name="USB Device Firmware Upgrade"
+
+  5. Flash the kernel with "dfu-util -a kernel -D uImage-2.6.21.6-moko11-r2-fic-gta01.bin"
+  6. Flash rootfs with "dfu-util -a rootfs -D <image>", where <image> is the
+     jffs2 image file to use as the root filesystem 
+     (e.g. ./tmp/deploy/images/poky-image-sato-fic-gta01.jffs2) 
+
+
+HTC Universal (htcuniversal)
+============================
+
+Note: HTC Universal support is highly experimental.
+
+On the HTC Universal, entirely replacing the Windows installation is not 
+supported, instead Poky is booted from an MMC/SD card from Windows. Once Poky
+has booted, Windows is no longer in memory or active but when power is removed,
+the user will be returned to windows and will need to return to Linux from 
+there.
+
+Once an MMC/SD card is available it is suggested its split into two partitions,
+one for a program called HaRET which lets you boot Linux from within Windows
+and the second for the rootfs. The HaRET partition should be the first partition
+on the card and be vfat formatted. It doesn't need to be large, just enough for
+HaRET and a kernel (say 5MB max). The rootfs should be ext2 and is usually the 
+second partition. The first partition should be vfat so Windows recognises it 
+as if it doesn't, it has been known to reformat cards.
+
+On the first partition you need three files:
+
+  * a HaRET binary (version 0.5.1 works well and a working version 
+    should be part of the last Poky release)
+  * a kernel renamed to "zImage"
+  * a default.txt which contains:
+
+set kernel "zImage"
+set mtype "855"
+set cmdline "root=/dev/mmcblk0p2 rw console=ttyS0,115200n8 console=tty0 rootdelay=5 fbcon=rotate:1"
+boot2
+
+On the second parition the root file system is extracted as root. A different
+partition layout or other kernel options can be changed in the default.txt file.
+
+When inserted into the device, Windows should see the card and let you browse
+its contents using File Explorer. Running the HaRET binary will present a dialog
+box (maybe after messages warning about running unsigned binaries) where you 
+select OK and you should then see Poky boot. Kernel messages can be seen by 
+adding psplash=false to the kernel commandline.
+
+
+Nokia 770/N800/N810 Internet Tablets (nokia770 and nokia800)
+============================================================
+
+Note: Nokia tablet support is highly experimental.
+
+The Nokia internet tablet devices are OMAP based tablet formfactor devices 
+with large screens (800x480), wifi and touchscreen.
+
+To flash images to these devices you need the "flasher" utility which can be 
+downloaded from the http://tablets-dev.nokia.com/d3.php?f=flasher-3.0. This 
+utility needs to be run as root and the usb filesystem needs to be mounted 
+although most distributions will have done this for you. Once you have this 
+follow these steps:
+
+  1. Power down the device.
+  2. Connect the device to the host machine via USB 
+     (connecting power to the device doesn't hurt either).
+  3. Run "flasher -i"
+  4. Power on the device.
+  5. The program should give an indication it's found 
+     a tablet device. If not, recheck the cables, make sure you're 
+     root and usbfs/usbdevfs is mounted.
+  6. Run "flasher -r <image> -k <kernel> -f", where <image> is the
+     jffs2 image file to use as the root filesystem 
+     (e.g. ./tmp/deploy/images/poky-image-sato-nokia800.jffs2) 
+     and <kernel> is the kernel to use 
+     (e.g. ./tmp/deploy/images/zImage-nokia800.bin).
+  7. Run "flasher -R" to reboot the device.
+  8. The device should boot into Poky.
+
+The nokia800 images and kernel will run on both the N800 and N810.
+
+
+Sharp Zaurus SL-C7x0 series (c7x0)
+==================================
+
+The Sharp Zaurus c7x0 series (SL-C700, SL-C750, SL-C760, SL-C860, SL-7500)
+are PXA25x based handheld PDAs with VGA screens. To install Poky images on
+these devices follow these steps:
+
+  1. Obtain an SD/MMC or CF card with a vfat or ext2 filesystem.
+  2. Copy a jffs2 image file (e.g. poky-image-sato-c7x0.jffs2) onto the
+     card as "initrd.bin":
+
+     $ cp ./tmp/deploy/images/poky-image-sato-c7x0.jffs2 /path/to/my-cf-card/initrd.bin
+
+  3. Copy an Linux kernel file (zImage-c7x0.bin) onto the card as 
+     "zImage.bin":
+
+     $ cp ./tmp/deploy/images/zImage-c7x0.bin /path/to/my-cf-card/zImage.bin
+
+  4. Copy an updater script (updater.sh.c7x0) onto the card
+     as "updater.sh":
+
+     $ cp ./tmp/deploy/images/updater.sh.c7x0 /path/to/my-cf-card/updater.sh
+
+  5. Power down the Zaurus.
+  6. Hold "OK" key and power on the device. An update menu should appear 
+     (in Japanese).
+  7. Choose "Update" (item 4).
+  8. The next screen will ask for the source, choose the appropriate 
+     card (CF or SD).
+  9. Make sure AC power is connected.
+  10. The next screen asks for confirmation, choose "Yes" (the left button).
+  11. The update process will start, flash the files on the card onto 
+      the device and the device will then reboot into Poky.
+
+
+Sharp Zaurus SL-C1000 (akita)
+=============================
+
+The Sharp Zaurus SL-C1000 is a PXA270 based device otherwise similar to the 
+c7x0. To install Poky images on this device follow the instructions for 
+the c7x0 but replace "c7x0" with "akita" where appropriate.
+
+
+Sharp Zaurus SL-C3x00 series (spitz)
+====================================
+
+The Sharp Zaurus SL-C3x00 devices are PXA270 based devices similar
+to akita but with an internal microdrive. The installation procedure 
+assumes a standard microdrive based device where the root (first) 
+partition has been enlarged to fit the image (at least 100MB, 
+400MB for the SDK).
+
+The procedure is the same as for the c7x0 and akita models with the 
+following differences:
+
+ 1. Instead of a jffs2 image you need to copy a compressed tarball of the 
+    root fileystem (e.g. poky-image-sato-spitz.tar.gz) onto the
+    card as "hdimage1.tgz":
+
+    $ cp ./tmp/deploy/images/poky-image-sato-spitz.tar.gz /path/to/my-cf-card/hdimage1.tgz
+
+ 2. You additionally need to copy a special tar utility  (gnu-tar) onto 
+    the card as "gnu-tar":
+
+    $ cp ./tmp/deploy/images/gnu-tar /path/to/my-cf-card/gnu-tar


 Intel Atom based PCs and devices (atom-pc)
@@ -87,22 +450,22 @@ Hard Disk:
  1. Build a directdisk image format. This will generate proper partition tables
     that will in turn be written to the physical media. For example:

-     $ bitbake core-image-minimal-directdisk
+     $ bitbake poky-image-minimal-directdisk
  
  2. Use the "dd" utility to write the image to the raw block device. For example:

-     # dd if=core-image-minimal-directdisk-atom-pc.hdddirect of=/dev/sdb
+     # dd if=poky-image-minimal-directdisk-atom-pc.hdddirect of=/dev/sdb

 USB Device:
  1. Build an hddimg image format. This is a simple filesystem without partition
     tables and is suitable for USB keys. For example:

-     $ bitbake core-image-minimal-live
+     $ bitbake poky-image-minimal-live

  2. Use the "dd" utility to write the image to the raw block device. For
     example:

-     # dd if=core-image-minimal-live-atom-pc.hddimg of=/dev/sdb
+     # dd if=poky-image-minimal-live-atom-pc.hddimg of=/dev/sdb

  If the device fails to boot with "Boot error" displayed, it is likely the BIOS
  cannot understand the physical layout of the disk (or rather it expects a
@@ -126,7 +489,7 @@ USB Device:

     b. Copy the contents of the poky image to the USB-ZIP mode device:

-     # mount -o loop core-image-minimal-live-atom-pc.hddimg  /tmp/image
+     # mount -o loop poky-image-minimal-live-atom-pc.hddimg  /tmp/image
     # mount /dev/sdb4 /tmp/usbkey
     # cp -rf /tmp/image/* /tmp/usbkey

@@ -185,7 +548,7 @@ and may require modification of the NAND environment.
     # cp u-boot-beagleboard.bin /media/boot/u-boot.bin

  3. Install the root filesystem
-     # tar x -C /media/root -f core-image-$IMAGE_TYPE-beagleboard.tar.bz2
+     # tar x -C /media/root -f poky-image-$IMAGE_TYPE-beagleboard.tar.bz2
     # tar x -C /media/root -f modules-$KERNEL_VERSION-beagleboard.tgz

  4. Install the kernel uImage
@@ -217,200 +580,3 @@ Note: As of the 2.6.37 linux-yocto kernel recipe, the Beagleboard uses the
      order to setup the getty on the serial line:

      SERIAL_CONSOLE_beagleboard = "115200 ttyS2"
-
-
-Freescale MPC8315E-RDB (mpc8315e-rdb)
-=====================================
-
-The MPC8315 PowerPC reference platform (MPC8315E-RDB) is aimed at hardware and
-software development of network attached storage (NAS) and digital media server
-applications. The MPC8315E-RDB features the PowerQUICC II Pro processor, which
-includes a built-in security accelerator.
-
-Setup instructions
------------------
-
-You will need the following:
-* nfs root setup on your workstation
-* tftp server installed on your workstation
-
-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
-    server.
-
- 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.
-
- =>tftp 800000 uImage.mpc8315erdb
- =>tftp 780000 mpc8315erdb.dtb
- =>bootm 800000 - 780000
-
-
-Ubiquiti Networks RouterStation Pro (routerstationpro)
-======================================================
-
-The RouterStation Pro is an Atheros AR7161 MIPS-based board. Geared towards
-networking applications, it has all of the usual features as well as three
-type IIIA mini-PCI slots and an on-board 3-port 10/100/1000 Ethernet switch,
-in addition to the 10/100/1000 Ethernet WAN port which supports
-Power-over-Ethernet.
-
-Setup instructions
------------------
-
-You will need the following:
-* A serial cable - female to female (or female to male + gender changer)
-  NOTE: cable must be straight through, *not* a null modem cable.
-* USB flash drive or hard disk that is able to be powered from the
-  board's USB port.
-* tftp server installed on your workstation
-
-NOTE: in the following instructions it is assumed that /dev/sdb corresponds
-to the USB disk when it is plugged into your workstation. If this is not the
-case in your setup then please be careful to substitute the correct device
-name in all commands where appropriate.
-
--- Preparation ---
-
-1) Build an image (e.g. core-image-minimal) using "routerstationpro" as the
-MACHINE
-
-2) Partition the USB drive so that primary partition 1 is type Linux (83).
-Minimum size depends on your root image size - core-image-minimal probably
-only needs 8-16MB, other images will need more.
-
-  # fdisk /dev/sdb
-  Command (m for help): p
-
-  Disk /dev/sdb: 4011 MB, 4011491328 bytes
-  124 heads, 62 sectors/track, 1019 cylinders, total 7834944 sectors
-  Units = sectors of 1 * 512 = 512 bytes
-  Sector size (logical/physical): 512 bytes / 512 bytes
-  I/O size (minimum/optimal): 512 bytes / 512 bytes
-  Disk identifier: 0x0009e87d
-
-     Device Boot      Start         End      Blocks   Id  System
-  /dev/sdb1              62     1952751      976345   83  Linux
-
-3) Format partition 1 on the USB as ext3
-
-  # mke2fs -j /dev/sdb1
-
-4) Mount partition 1 and then extract the contents of
-tmp/deploy/images/core-image-XXXX.tar.bz2 into it (preserving permissions).
-
-  # mount /dev/sdb1 /media/sdb1
-  # cd /media/sdb1
-  # tar -xvjpf tmp/deploy/images/core-image-XXXX.tar.bz2
-
-5) Unmount the USB drive and then plug it into the board's USB port
-
-6) Connect the board's serial port to your workstation and then start up
-your favourite serial terminal so that you will be able to interact with
-the serial console. If you don't have a favourite, picocom is suggested:
-
-  $ picocom /dev/ttyUSB0 -b 115200
-
-7) Connect the network into eth0 (the one that is NOT the 3 port switch). If
-you are using power-over-ethernet then the board will power up at this point.
-
-8) Start up the board, watch the serial console. Hit Ctrl+C to abort the
-autostart if the board is configured that way (it is by default). The
-bootloader's fconfig command can be used to disable autostart and configure
-the IP settings if you need to change them (default IP is 192.168.1.20).
-
-9) Make the kernel (tmp/deploy/images/vmlinux-routerstationpro.bin) available
-on the tftp server.
-
-10) If you are going to write the kernel to flash (optional - see "Booting a
-kernel directly" below for the alternative), remove the current kernel and
-rootfs flash partitions. You can list the partitions using the following
-bootloader command:
-
-  RedBoot> fis list
-
-You can delete the existing kernel and rootfs with these commands:
-
-  RedBoot> fis delete kernel
-  RedBoot> fis delete rootfs
-
--- Booting a kernel directly ---
-
-1) Load the kernel using the following bootloader command:
-
-  RedBoot> load -m tftp -h <ip of tftp server> vmlinux-routerstationpro.bin
-
-You should see a message on it being successfully loaded.
-
-2) Execute the kernel:
-
-  RedBoot> exec -c "console=ttyS0,115200 root=/dev/sda1 rw rootdelay=2 board=UBNT-RSPRO"
-
-Note that specifying the command line with -c is important as linux-yocto does
-not provide a default command line.
-
--- Writing a kernel to flash ---
-
-1) Go to your tftp server and gzip the kernel you want in flash. It should
-halve the size.
-
-2) Load the kernel using the following bootloader command:
-
-  RedBoot> load -r -b 0x80600000 -m tftp -h <ip of tftp server> vmlinux-routerstationpro.bin.gz
-
-This should output something similar to the following:
-
-  Raw file loaded 0x80600000-0x8087c537, assumed entry at 0x80600000
-
-Calculate the length by subtracting the first number from the second number
-and then rounding the result up to the nearest 0x1000.
-
-3) Using the length calculated above, create a flash partition for the kernel:
-
-  RedBoot> fis create -b 0x80600000 -l 0x240000 kernel
-
-(change 0x240000 to your rounded length -- change "kernel" to whatever
-you want to name your kernel)
-
--- Booting a kernel from flash ---
-
-To boot the flashed kernel perform the following steps.
-
-1) At the bootloader prompt, load the kernel:
-
-  RedBoot> fis load -d -e kernel
-
-(Change the name "kernel" above if you chose something different earlier)
-
-(-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.
-
--- a/bitbake/bin/bitbake-layers
+++ b/bitbake/bin/bitbake-layers
@@ -1,10 +1,4 @@
-#!/usr/bin/env python
-
-# This script has subcommands which operate against your bitbake layers, either
-# displaying useful information, or acting against them.
-# Currently, it only provides a show_appends command, which shows you what
-# bbappends are in effect, and warns you if you have appends which are not being
-# utilized.
+#!/usr/bin/env python2.6

 import cmd
 import logging
@@ -19,7 +13,6 @@ import bb.cache
 import bb.cooker
 import bb.providers
 from bb.cooker import state
-from bb.server import none


 logger = logging.getLogger('BitBake')
@@ -45,11 +38,14 @@ class Commands(cmd.Cmd):
        self.returncode = 0
        self.config = Config(parse_only=True)
        self.cooker = bb.cooker.BBCooker(self.config,
-                                         bb.server.none)
+                                         self.register_idle_function)
        self.config_data = self.cooker.configuration.data
        bb.providers.logger.setLevel(logging.ERROR)
        self.prepare_cooker()

+    def register_idle_function(self, function, data):
+        pass
+
    def prepare_cooker(self):
        sys.stderr.write("Parsing recipes..")
        logger.setLevel(logging.ERROR)
--- a/bitbake/bin/bitdoc
+++ b/bitbake/bin/bitdoc
@@ -497,7 +497,7 @@ def main():
        doc.insert_doc_item(doc_ins)

    # let us create the HTML now
-    bb.utils.mkdirhier(output_dir)
+    bb.mkdirhier(output_dir)
    os.chdir(output_dir)

    # Let us create the sites now. We do it in the following order
--- a/bitbake/doc/manual/Makefile
+++ b/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 --with-dblatex --extensions -o $(topdir)/$@ $@ $(manual),XMLTO $@ $(manual))
+	$(call command,xmlto --extensions -o $(topdir)/$@ $@ $(manual),XMLTO $@ $(manual))

 clean:
 	rm -rf $(cleanfiles)
--- a/bitbake/doc/manual/usermanual.xml
+++ b/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>
@@ -261,11 +261,11 @@ SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;pat
            </section>
            <section>
                <title>Recursive DEPENDS</title>
-                <para>These are specified with the 'recdeptask' flag and is used to signify the task(s) of each DEPENDS which must have completed before that task can be executed. It applies recursively so also, the DEPENDS of each item in the original DEPENDS must be met and so on.</para>
+                <para>These are specified with the 'recdeptask' flag and is used signify the task(s) of each DEPENDS which must have completed before that task can be executed. It applies recursively so also, the DEPENDS of each item in the original DEPENDS must be met and so on.</para>
            </section>
            <section>
                <title>Recursive RDEPENDS</title>
-                <para>These are specified with the 'recrdeptask' flag and is used to signify the task(s) of each RDEPENDS which must have completed before that task can be executed. It applies recursively so also, the RDEPENDS of each item in the original RDEPENDS must be met and so on. It also runs all DEPENDS first too.</para>
+                <para>These are specified with the 'recrdeptask' flag and is used signify the task(s) of each RDEPENDS which must have completed before that task can be executed. It applies recursively so also, the RDEPENDS of each item in the original RDEPENDS must be met and so on. It also runs all DEPENDS first too.</para>
            </section>
            <section>
                <title>Inter Task</title>
--- a/bitbake/lib/bb/build.py
+++ b/bitbake/lib/bb/build.py
@@ -32,7 +32,7 @@ import bb
 import bb.msg
 import bb.process
 from contextlib import nested
-from bb import data, event, utils
+from bb import data, event, mkdirhier, utils

 bblogger = logging.getLogger('BitBake')
 logger = logging.getLogger('BitBake.Build')
@@ -162,7 +162,6 @@ def exec_func(func, d, dirs = None):
        lockfiles = None

    tempdir = data.getVar('T', d, 1)
-    bb.utils.mkdirhier(tempdir)
    runfile = os.path.join(tempdir, 'run.{0}.{1}'.format(func, os.getpid()))

    with bb.utils.fileslocked(lockfiles):
@@ -182,16 +181,16 @@ def exec_func_python(func, d, runfile, cwd=None):
    """Execute a python BB 'function'"""

    bbfile = d.getVar('FILE', True)
+    try:
+        olddir = os.getcwd()
+    except OSError:
+        olddir = None
    code = _functionfmt.format(function=func, body=d.getVar(func, True))
    bb.utils.mkdirhier(os.path.dirname(runfile))
    with open(runfile, 'w') as script:
        script.write(code)

    if cwd:
-        try:
-            olddir = os.getcwd()
-        except OSError:
-            olddir = None
        os.chdir(cwd)

    try:
@@ -203,11 +202,8 @@ def exec_func_python(func, d, runfile, cwd=None):

        raise FuncFailed(func, None)
    finally:
-        if cwd and olddir:
-            try:
-                os.chdir(olddir)
-            except OSError:
-                pass
+        if olddir:
+            os.chdir(olddir)

 def exec_func_shell(function, d, runfile, cwd=None):
    """Execute a shell function from the metadata
@@ -225,11 +221,9 @@ def exec_func_shell(function, d, runfile, cwd=None):
        if logger.isEnabledFor(logging.DEBUG):
            script.write("set -x\n")
        data.emit_func(function, script, d)
-        if cwd:
-            script.write("cd %s\n" % cwd)
-        script.write("%s\n" % function)

-    os.chmod(runfile, 0775)
+        script.write("%s\n" % function)
+        os.fchmod(script.fileno(), 0775)

    env = {
        'PATH': d.getVar('PATH', True),
@@ -244,7 +238,8 @@ def exec_func_shell(function, d, runfile, cwd=None):
        logfile = sys.stdout

    try:
-        bb.process.run(cmd, env=env, shell=False, stdin=NULL, log=logfile)
+        bb.process.run(cmd, env=env, cwd=cwd, shell=False, stdin=NULL,
+                       log=logfile)
    except bb.process.CmdError:
        logfn = d.getVar('BB_LOGFILE', True)
        raise FuncFailed(function, logfn)
--- a/bitbake/lib/bb/cache.py
+++ b/bitbake/lib/bb/cache.py
@@ -43,7 +43,7 @@ except ImportError:
    logger.info("Importing cPickle failed. "
                "Falling back to a very slow implementation.")

-__cache_version__ = "138"
+__cache_version__ = "137"

 recipe_fields = (
    'pn',
@@ -78,8 +78,6 @@ recipe_fields = (
    'summary',
    'license',
    'section',
-    'fakerootenv',
-    'fakerootdirs'
 )


@@ -129,10 +127,7 @@ class RecipeInfo(namedtuple('RecipeInfo', recipe_fields)):
    @classmethod
    def from_metadata(cls, filename, metadata):
        if cls.getvar('__SKIPPED', metadata):
-            return cls.make_optional(skipped=True,
-                                     file_depends=metadata.getVar('__depends', False),
-                                     timestamp=bb.parse.cached_mtime(filename),
-                                     variants=cls.listvar('__VARIANTS', metadata) + [''])
+            return cls.make_optional(skipped=True)

        tasks = metadata.getVar('__BBTASKS', False)

@@ -177,8 +172,6 @@ class RecipeInfo(namedtuple('RecipeInfo', recipe_fields)):
            summary          = cls.getvar('SUMMARY', metadata),
            license          = cls.getvar('LICENSE', metadata),
            section          = cls.getvar('SECTION', metadata),
-            fakerootenv      = cls.getvar('FAKEROOTENV', metadata),
-            fakerootdirs     = cls.getvar('FAKEROOTDIRS', metadata),
        )


@@ -297,7 +290,6 @@ class Cache(object):

        logger.debug(1, "Parsing %s (full)", fn)

-        cfgData.setVar("__ONLYFINALISE", virtual or "default")
        bb_data = cls.load_bbfile(fn, appends, cfgData)
        return bb_data[virtual]

@@ -483,13 +475,11 @@ class Cache(object):
        return bb.parse.cached_mtime_noerror(cachefile)

    def add_info(self, filename, info, cacheData, parsed=None):
-        if not info.skipped:
-            cacheData.add_from_recipeinfo(filename, info)
-
+        cacheData.add_from_recipeinfo(filename, info)
        if not self.has_cache:
            return

-        if (info.skipped or 'SRCREVINACTION' not in info.pv) and not info.nocache:
+        if 'SRCREVINACTION' not in info.pv and not info.nocache:
            if parsed:
                self.cacheclean = False
            self.depends_cache[filename] = info
@@ -572,7 +562,6 @@ class CacheData(object):
        self.packages = defaultdict(list)
        self.packages_dynamic = defaultdict(list)
        self.possible_world = []
-        self.universe_target = []
        self.pkg_pn = defaultdict(list)
        self.pkg_fn = {}
        self.pkg_pepvpr = {}
@@ -595,8 +584,6 @@ class CacheData(object):
        self.summary = {}
        self.license = {}
        self.section = {}
-        self.fakerootenv = {}
-        self.fakerootdirs = {}

        # Indirect Cache variables (set elsewhere)
        self.ignored_dependencies = []
@@ -651,11 +638,6 @@ class CacheData(object):
        if not info.broken and not info.not_world:
            self.possible_world.append(fn)

-        # create a collection of all targets for sanity checking
-        # tasks, such as upstream versions, license, and tools for
-        # task and image creation.
-        self.universe_target.append(info.pn)
-
        self.hashfn[fn] = info.hashfilename
        for task, taskhash in info.basetaskhashes.iteritems():
            identifier = '%s.%s' % (fn, task)
@@ -665,5 +647,3 @@ class CacheData(object):
        self.summary[fn] = info.summary
        self.license[fn] = info.license
        self.section[fn] = info.section
-        self.fakerootenv[fn] = info.fakerootenv
-        self.fakerootdirs[fn] = info.fakerootdirs
--- a/bitbake/lib/bb/codeparser.py
+++ b/bitbake/lib/bb/codeparser.py
@@ -21,13 +21,13 @@ def check_indent(codestr):
    """If the code is indented, add a top level piece of code to 'remove' the indentation"""

    i = 0
-    while codestr[i] in ["\n", "\t", " "]:
+    while codestr[i] in ["\n", "	", " "]:
        i = i + 1

    if i == 0:
        return codestr

-    if codestr[i-1] == "\t" or codestr[i-1] == " ":
+    if codestr[i-1] is "	" or codestr[i-1] is " ":
        return "if 1:\n" + codestr

    return codestr
@@ -70,25 +70,8 @@ def parser_cache_save(d):
    if not cachefile:
        return

-    lf = bb.utils.lockfile(cachefile + ".lock")
-
-    try:
-        p = pickle.Unpickler(file(cachefile, "rb"))
-        data, version = p.load()
-    except IOError, EOFError:
-        data, version = None, None
-
-    if version == PARSERCACHE_VERSION:
-        for h in data[0]:
-            if h not in pythonparsecache:
-                pythonparsecache[h] = data[0][h]
-        for h in data[1]:
-            if h not in pythonparsecache:
-                shellparsecache[h] = data[1][h]
-
    p = pickle.Pickler(file(cachefile, "wb"), -1)
    p.dump([[pythonparsecache, shellparsecache], PARSERCACHE_VERSION])
-    bb.utils.unlockfile(lf)

 class PythonParser():
    class ValueVisitor():
--- a/bitbake/lib/bb/compat.py
+++ b/bitbake/lib/bb/compat.py
@@ -1,28 +0,0 @@
-"""Code pulled from future python versions, here for compatibility"""
-
-def total_ordering(cls):
-    """Class decorator that fills in missing ordering methods"""
-    convert = {
-        '__lt__': [('__gt__', lambda self, other: other < self),
-                   ('__le__', lambda self, other: not other < self),
-                   ('__ge__', lambda self, other: not self < other)],
-        '__le__': [('__ge__', lambda self, other: other <= self),
-                   ('__lt__', lambda self, other: not other <= self),
-                   ('__gt__', lambda self, other: not self <= other)],
-        '__gt__': [('__lt__', lambda self, other: other > self),
-                   ('__ge__', lambda self, other: not other > self),
-                   ('__le__', lambda self, other: not self > other)],
-        '__ge__': [('__le__', lambda self, other: other >= self),
-                   ('__gt__', lambda self, other: not other >= self),
-                   ('__lt__', lambda self, other: not self >= other)]
-    }
-    roots = set(dir(cls)) & set(convert)
-    if not roots:
-        raise ValueError('must define at least one ordering operation: < > <= >=')
-    root = max(roots)       # prefer __lt__ to __le__ to __gt__ to __ge__
-    for opname, opfunc in convert[root]:
-        if opname not in roots:
-            opfunc.__name__ = opname
-            opfunc.__doc__ = getattr(int, opname).__doc__
-            setattr(cls, opname, opfunc)
-    return cls
--- a/bitbake/lib/bb/cooker.py
+++ b/bitbake/lib/bb/cooker.py
@@ -124,8 +124,6 @@ class BBCooker:

            if 'world' in self.configuration.pkgs_to_build:
                buildlog.error("'world' is not a valid target for --environment.")
-            if 'universe' in self.configuration.pkgs_to_build:
-                buildlog.error("'universe' is not a valid target for --environment.")
            elif len(self.configuration.pkgs_to_build) > 1:
                buildlog.error("Only one target can be used with the --environment option.")
            elif self.configuration.buildfile and len(self.configuration.pkgs_to_build) > 0:
@@ -255,9 +253,7 @@ class BBCooker:
        localdata = data.createCopy(self.configuration.data)
        bb.data.update_data(localdata)
        bb.data.expandKeys(localdata)
-        # We set abort to False here to prevent unbuildable targets raising
-        # an exception when we're just generating data
-        taskdata = bb.taskdata.TaskData(False)
+        taskdata = bb.taskdata.TaskData(self.configuration.abort)

        runlist = []
        for k in pkgs_to_build:
@@ -707,23 +703,20 @@ class BBCooker:
        if (task == None):
            task = self.configuration.cmd

-        fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
-        fn = os.path.abspath(fn)
+        (fn, cls) = bb.cache.Cache.virtualfn2realfn(buildfile)
        buildfile = self.matchFile(fn)
+        fn = bb.cache.Cache.realfn2virtual(buildfile, cls)

        self.buildSetVars()

        self.status = bb.cache.CacheData()
        infos = bb.cache.Cache.parse(fn, self.get_file_appends(fn), \
                                     self.configuration.data)
-        infos = dict(infos)
-
-        fn = bb.cache.Cache.realfn2virtual(buildfile, cls)
-        try:
-            maininfo = infos[fn]
-        except KeyError:
-            bb.fatal("%s does not exist" % fn)
-        self.status.add_from_recipeinfo(fn, maininfo)
+        maininfo = None
+        for vfn, info in infos:
+            self.status.add_from_recipeinfo(vfn, info)
+            if vfn == fn:
+                maininfo = info

        # Tweak some variables
        item = maininfo.pn
@@ -894,12 +887,6 @@ class BBCooker:
            for t in self.status.world_target:
                pkgs_to_build.append(t)

-        if 'universe' in pkgs_to_build:
-            parselog.debug(1, "collating packages for \"universe\"")
-            pkgs_to_build.remove('universe')
-            for t in self.status.universe_target:
-                pkgs_to_build.append(t)
-
        return pkgs_to_build

    def get_bbfiles( self, path = os.getcwd() ):
@@ -941,21 +928,16 @@ class BBCooker:
            collectlog.error("no recipe files to build, check your BBPATH and BBFILES?")
            bb.event.fire(CookerExit(), self.configuration.event_data)

-        # Can't use set here as order is important
-        newfiles = []
+        newfiles = set()
        for f in files:
            if os.path.isdir(f):
                dirfiles = self.find_bbfiles(f)
-                for g in dirfiles:
-                    if g not in newfiles:
-                        newfiles.append(g)
+                newfiles.update(dirfiles)
            else:
                globbed = glob.glob(f)
                if not globbed and os.path.exists(f):
                    globbed = [f]
-                for g in globbed:
-                    if g not in newfiles:
-                        newfiles.append(g)
+                newfiles.update(globbed)

        bbmask = bb.data.getVar('BBMASK', self.configuration.data, 1)

@@ -1120,7 +1102,6 @@ class CookerParser(object):
    def start(self):
        def init(cfg):
            signal.signal(signal.SIGINT, signal.SIG_IGN)
-            multiprocessing.util.Finalize(None, bb.codeparser.parser_cache_save, args=(self.cooker.configuration.data, ), exitpriority=1)
            parse_file.cfg = cfg

        bb.event.fire(bb.event.ParseStarted(self.toparse), self.cfgdata)
@@ -1146,6 +1127,10 @@ class CookerParser(object):
        sync.start()
        atexit.register(lambda: sync.join())

+        codesync = threading.Thread(target=bb.codeparser.parser_cache_save(self.cooker.configuration.data))
+        codesync.start()
+        atexit.register(lambda: codesync.join())
+
    def load_cached(self):
        for filename, appends in self.fromcache:
            cached, infos = self.bb_cache.load(filename, appends, self.cfgdata)
@@ -1177,7 +1162,8 @@ class CookerParser(object):
        for virtualfn, info in result:
            if info.skipped:
                self.skipped += 1
-            self.bb_cache.add_info(virtualfn, info, self.cooker.status,
+            else:
+                self.bb_cache.add_info(virtualfn, info, self.cooker.status,
                                        parsed=parsed)
        return True

--- a/bitbake/lib/bb/data_smart.py
+++ b/bitbake/lib/bb/data_smart.py
@@ -191,11 +191,11 @@ class DataSmart(MutableMapping):
                            keep.append((a ,o))
                            continue

-                        if op == "_append":
+                        if op is "_append":
                            sval = self.getVar(append, False) or ""
                            sval += a
                            self.setVar(append, sval)
-                        elif op == "_prepend":
+                        elif op is "_prepend":
                            sval = a + (self.getVar(append, False) or "")
                            self.setVar(append, sval)

--- a/bitbake/lib/bb/event.py
+++ b/bitbake/lib/bb/event.py
@@ -37,8 +37,6 @@ import bb.utils
 worker_pid = 0
 worker_pipe = None

-logger = logging.getLogger('BitBake.Event')
-
 class Event(object):
    """Base class for events"""

@@ -60,35 +58,23 @@ _ui_handler_seq = 0
 bb.utils._context["NotHandled"] = NotHandled
 bb.utils._context["Handled"] = Handled

-def execute_handler(name, handler, event, d):
-    event.data = d
-    try:
-        ret = handler(event)
-    except Exception:
-        etype, value, tb = sys.exc_info()
-        logger.error("Execution of event handler '%s' failed" % name,
-                        exc_info=(etype, value, tb.tb_next))
-        raise
-    except SystemExit as exc:
-        if exc.code != 0:
-            logger.error("Execution of event handler '%s' failed" % name)
-        raise
-    finally:
-        del event.data
-
-    if ret is not None:
-        warnings.warn("Using Handled/NotHandled in event handlers is deprecated",
-                        DeprecationWarning, stacklevel = 2)
-
 def fire_class_handlers(event, d):
    if isinstance(event, logging.LogRecord):
        return

-    for name, handler in _handlers.iteritems():
-        try:
-            execute_handler(name, handler, event, d)
-        except BaseException:
-            continue
+    for handler in _handlers:
+        h = _handlers[handler]
+        event.data = d
+        if type(h).__name__ == "code":
+            locals = {"e": event}
+            bb.utils.simple_exec(h, locals)
+            ret = bb.utils.better_eval("tmpHandler(e)", locals)
+            if ret is not None:
+                warnings.warn("Using Handled/NotHandled in event handlers is deprecated",
+                              DeprecationWarning, stacklevel = 2)
+        else:
+            h(event)
+        del event.data

 ui_queue = []
@atexit.register
@@ -150,7 +136,6 @@ def fire_from_worker(event, d):
    event = pickle.loads(event[7:-8])
    fire_ui_handlers(event, d)

-noop = lambda _: None
 def register(name, handler):
    """Register an Event handler"""

@@ -161,18 +146,9 @@ def register(name, handler):
    if handler is not None:
        # handle string containing python code
        if isinstance(handler, basestring):
-            tmp = "def %s(e):\n%s" % (name, handler)
-            try:
-                code = compile(tmp, "%s(e)" % name, "exec")
-            except SyntaxError:
-                logger.error("Unable to register event handler '%s':\n%s", name,
-                             ''.join(traceback.format_exc(limit=0)))
-                _handlers[name] = noop
-                return
-            env = {}
-            bb.utils.simple_exec(code, env)
-            func = bb.utils.better_eval(name, env)
-            _handlers[name] = func
+            tmp = "def tmpHandler(e):\n%s" % handler
+            comp = bb.utils.better_compile(tmp, "tmpHandler(e)", "bb.event._registerCode")
+            _handlers[name] = comp
        else:
            _handlers[name] = handler

--- a/bitbake/lib/bb/fetch/init.py
+++ b/bitbake/lib/bb/fetch/init.py
@@ -153,18 +153,18 @@ def fetcher_init(d):
    Called to initialize the fetchers once the configuration data is known.
    Calls before this must not hit the cache.
    """
+    pd = persist_data.persist(d)
    # When to drop SCM head revisions controlled by user policy
    srcrev_policy = bb.data.getVar('BB_SRCREV_POLICY', d, 1) or "clear"
    if srcrev_policy == "cache":
        logger.debug(1, "Keeping SRCREV cache due to cache policy of: %s", srcrev_policy)
    elif srcrev_policy == "clear":
        logger.debug(1, "Clearing SRCREV cache due to cache policy of: %s", srcrev_policy)
-        revs = persist_data.persist('BB_URI_HEADREVS', d)
        try:
-            bb.fetch.saved_headrevs = revs.items()
+            bb.fetch.saved_headrevs = pd['BB_URI_HEADREVS'].items()
        except:
            pass
-        revs.clear()
+        del pd['BB_URI_HEADREVS']
    else:
        raise FetchError("Invalid SRCREV cache policy of: %s" % srcrev_policy)

@@ -178,7 +178,8 @@ def fetcher_compare_revisions(d):
    return true/false on whether they've changed.
    """

-    data = persist_data.persist('BB_URI_HEADREVS', d).items()
+    pd = persist_data.persist(d)
+    data = pd['BB_URI_HEADREVS'].items()
    data2 = bb.fetch.saved_headrevs

    changed = False
@@ -755,13 +756,15 @@ class Fetch(object):
        if not hasattr(self, "_latest_revision"):
            raise ParameterError

-        revs = persist_data.persist('BB_URI_HEADREVS', d)
+        pd = persist_data.persist(d)
+        revs = pd['BB_URI_HEADREVS']
        key = self.generate_revision_key(url, ud, d)
-        try:
-            return revs[key]
-        except KeyError:
-            revs[key] = rev = self._latest_revision(url, ud, d)
-            return rev
+        rev = revs[key]
+        if rev != None:
+            return str(rev)
+
+        revs[key] = rev = self._latest_revision(url, ud, d)
+        return rev

    def sortable_revision(self, url, ud, d):
        """
@@ -770,17 +773,18 @@ class Fetch(object):
        if hasattr(self, "_sortable_revision"):
            return self._sortable_revision(url, ud, d)

-        localcounts = persist_data.persist('BB_URI_LOCALCOUNT', d)
+        pd = persist_data.persist(d)
+        localcounts = pd['BB_URI_LOCALCOUNT']
        key = self.generate_revision_key(url, ud, d)

        latest_rev = self._build_revision(url, ud, d)
-        last_rev = localcounts.get(key + '_rev')
+        last_rev = localcounts[key + '_rev']
        uselocalcount = bb.data.getVar("BB_LOCALCOUNT_OVERRIDE", d, True) or False
        count = None
        if uselocalcount:
            count = Fetch.localcount_internal_helper(ud, d)
        if count is None:
-            count = localcounts.get(key + '_count')
+            count = localcounts[key + '_count']

        if last_rev == latest_rev:
            return str(count + "+" + latest_rev)
--- a/bitbake/lib/bb/fetch/bzr.py
+++ b/bitbake/lib/bb/fetch/bzr.py
@@ -67,15 +67,15 @@ class Bzr(Fetch):

        options = []

-        if command == "revno":
+        if command is "revno":
            bzrcmd = "%s revno %s %s://%s" % (basecmd, " ".join(options), proto, bzrroot)
        else:
            if ud.revision:
                options.append("-r %s" % ud.revision)

-            if command == "fetch":
+            if command is "fetch":
                bzrcmd = "%s co %s %s://%s" % (basecmd, " ".join(options), proto, bzrroot)
-            elif command == "update":
+            elif command is "update":
                bzrcmd = "%s pull %s --overwrite" % (basecmd, " ".join(options))
            else:
                raise FetchError("Invalid bzr command %s" % command)
@@ -94,7 +94,7 @@ class Bzr(Fetch):
            bb.utils.remove(os.path.join(ud.pkgdir, os.path.basename(ud.pkgdir)), True)
            bzrcmd = self._buildbzrcommand(ud, d, "fetch")
            logger.debug(1, "BZR Checkout %s", loc)
-            bb.utils.mkdirhier(ud.pkgdir)
+            bb.mkdirhier(ud.pkgdir)
            os.chdir(ud.pkgdir)
            logger.debug(1, "Running %s", bzrcmd)
            runfetchcmd(bzrcmd, d)
--- a/bitbake/lib/bb/fetch/cvs.py
+++ b/bitbake/lib/bb/fetch/cvs.py
@@ -137,7 +137,7 @@ class Cvs(Fetch):
        else:
            logger.info("Fetch " + loc)
            # check out sources there
-            bb.utils.mkdirhier(pkgdir)
+            bb.mkdirhier(pkgdir)
            os.chdir(pkgdir)
            logger.debug(1, "Running %s", cvscmd)
            myret = os.system(cvscmd)
--- a/bitbake/lib/bb/fetch/git.py
+++ b/bitbake/lib/bb/fetch/git.py
@@ -131,7 +131,7 @@ class Git(Fetch):

        # If the checkout doesn't exist and the mirror tarball does, extract it
        if not os.path.exists(ud.clonedir) and os.path.exists(repofile):
-            bb.utils.mkdirhier(ud.clonedir)
+            bb.mkdirhier(ud.clonedir)
            os.chdir(ud.clonedir)
            runfetchcmd("tar -xzf %s" % (repofile), d)

@@ -188,7 +188,7 @@ class Git(Fetch):
            os.chdir(coprefix)
            runfetchcmd("%s checkout -q -f %s%s" % (ud.basecmd, ud.tag, readpathspec), d)
        else:
-            bb.utils.mkdirhier(codir)
+            bb.mkdirhier(codir)
            os.chdir(ud.clonedir)
            runfetchcmd("%s read-tree %s%s" % (ud.basecmd, ud.tag, readpathspec), d)
            runfetchcmd("%s checkout-index -q -f --prefix=%s -a" % (ud.basecmd, coprefix), d)
@@ -242,36 +242,36 @@ class Git(Fetch):
        """
        Look in the cache for the latest revision, if not present ask the SCM.
        """
-        revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
+        persisted = bb.persist_data.persist(d)
+        revs = persisted['BB_URI_HEADREVS']

        key = self.generate_revision_key(url, ud, d, branch=True)
-
-        try:
-            return revs[key]
-        except KeyError:
+        rev = revs[key]
+        if rev is None:
            # Compatibility with old key format, no branch included
            oldkey = self.generate_revision_key(url, ud, d, branch=False)
-            try:
-                rev = revs[oldkey]
-            except KeyError:
-                rev = self._latest_revision(url, ud, d)
-            else:
+            rev = revs[oldkey]
+            if rev is not None:
                del revs[oldkey]
+            else:
+                rev = self._latest_revision(url, ud, d)
            revs[key] = rev
-            return rev
+
+        return str(rev)

    def sortable_revision(self, url, ud, d):
        """

        """
-        localcounts = bb.persist_data.persist('BB_URI_LOCALCOUNT', d)
+        pd = bb.persist_data.persist(d)
+        localcounts = pd['BB_URI_LOCALCOUNT']
        key = self.generate_revision_key(url, ud, d, branch=True)
        oldkey = self.generate_revision_key(url, ud, d, branch=False)

        latest_rev = self._build_revision(url, ud, d)
-        last_rev = localcounts.get(key + '_rev')
+        last_rev = localcounts[key + '_rev']
        if last_rev is None:
-            last_rev = localcounts.get(oldkey + '_rev')
+            last_rev = localcounts[oldkey + '_rev']
            if last_rev is not None:
                del localcounts[oldkey + '_rev']
                localcounts[key + '_rev'] = last_rev
@@ -281,9 +281,9 @@ class Git(Fetch):
        if uselocalcount:
            count = Fetch.localcount_internal_helper(ud, d)
        if count is None:
-            count = localcounts.get(key + '_count')
+            count = localcounts[key + '_count']
        if count is None:
-            count = localcounts.get(oldkey + '_count')
+            count = localcounts[oldkey + '_count']
            if count is not None:
                del localcounts[oldkey + '_count']
                localcounts[key + '_count'] = count
--- a/bitbake/lib/bb/fetch/hg.py
+++ b/bitbake/lib/bb/fetch/hg.py
@@ -131,7 +131,7 @@ class Hg(Fetch):
            fetchcmd = self._buildhgcommand(ud, d, "fetch")
            logger.info("Fetch " + loc)
            # check out sources there
-            bb.utils.mkdirhier(ud.pkgdir)
+            bb.mkdirhier(ud.pkgdir)
            os.chdir(ud.pkgdir)
            logger.debug(1, "Running %s", fetchcmd)
            runfetchcmd(fetchcmd, d)
--- a/bitbake/lib/bb/fetch/osc.py
+++ b/bitbake/lib/bb/fetch/osc.py
@@ -98,7 +98,7 @@ class Osc(Fetch):
            oscfetchcmd = self._buildosccommand(ud, d, "fetch")
            logger.info("Fetch " + loc)
            # check out sources there
-            bb.utils.mkdirhier(ud.pkgdir)
+            bb.mkdirhier(ud.pkgdir)
            os.chdir(ud.pkgdir)
            logger.debug(1, "Running %s", oscfetchcmd)
            runfetchcmd(oscfetchcmd, d)
--- a/bitbake/lib/bb/fetch/perforce.py
+++ b/bitbake/lib/bb/fetch/perforce.py
@@ -154,7 +154,7 @@ class Perforce(Fetch):

        # create temp directory
        logger.debug(2, "Fetch: creating temporary directory")
-        bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
+        bb.mkdirhier(data.expand('${WORKDIR}', localdata))
        data.setVar('TMPBASE', data.expand('${WORKDIR}/oep4.XXXXXX', localdata), localdata)
        tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, 1) or "false")
        tmpfile = tmppipe.readline().strip()
--- a/bitbake/lib/bb/fetch/repo.py
+++ b/bitbake/lib/bb/fetch/repo.py
@@ -71,7 +71,7 @@ class Repo(Fetch):
        else:
            username = ""

-        bb.utils.mkdirhier(os.path.join(codir, "repo"))
+        bb.mkdirhier(os.path.join(codir, "repo"))
        os.chdir(os.path.join(codir, "repo"))
        if not os.path.exists(os.path.join(codir, "repo", ".repo")):
            runfetchcmd("repo init -m %s -b %s -u %s://%s%s%s" % (ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), d)
--- a/bitbake/lib/bb/fetch/svk.py
+++ b/bitbake/lib/bb/fetch/svk.py
@@ -71,7 +71,7 @@ class Svk(Fetch):
        localdata = data.createCopy(d)
        data.update_data(localdata)
        logger.debug(2, "Fetch: creating temporary directory")
-        bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
+        bb.mkdirhier(data.expand('${WORKDIR}', localdata))
        data.setVar('TMPBASE', data.expand('${WORKDIR}/oesvk.XXXXXX', localdata), localdata)
        tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, 1) or "false")
        tmpfile = tmppipe.readline().strip()
--- a/bitbake/lib/bb/fetch/svn.py
+++ b/bitbake/lib/bb/fetch/svn.py
@@ -146,7 +146,7 @@ class Svn(Fetch):
            svnfetchcmd = self._buildsvncommand(ud, d, "fetch")
            logger.info("Fetch " + loc)
            # check out sources there
-            bb.utils.mkdirhier(ud.pkgdir)
+            bb.mkdirhier(ud.pkgdir)
            os.chdir(ud.pkgdir)
            logger.debug(1, "Running %s", svnfetchcmd)
            runfetchcmd(svnfetchcmd, d)
--- a/bitbake/lib/bb/fetch2/init.py
+++ b/bitbake/lib/bb/fetch2/init.py
@@ -28,8 +28,10 @@ from __future__ import absolute_import
 from __future__ import print_function
 import os, re
 import logging
-import bb.data, bb.persist_data, bb.utils
-from bb import data
+import bb
+from   bb import data
+from   bb import persist_data
+from   bb import utils

 __version__ = "2"

@@ -222,18 +224,18 @@ def fetcher_init(d):
    Called to initialize the fetchers once the configuration data is known.
    Calls before this must not hit the cache.
    """
+    pd = persist_data.persist(d)
    # When to drop SCM head revisions controlled by user policy
    srcrev_policy = bb.data.getVar('BB_SRCREV_POLICY', d, True) or "clear"
    if srcrev_policy == "cache":
        logger.debug(1, "Keeping SRCREV cache due to cache policy of: %s", srcrev_policy)
    elif srcrev_policy == "clear":
        logger.debug(1, "Clearing SRCREV cache due to cache policy of: %s", srcrev_policy)
-        revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
        try:
-            bb.fetch2.saved_headrevs = revs.items()
+            bb.fetch2.saved_headrevs = pd['BB_URI_HEADREVS'].items()
        except:
            pass
-        revs.clear()
+        del pd['BB_URI_HEADREVS']
    else:
        raise FetchError("Invalid SRCREV cache policy of: %s" % srcrev_policy)

@@ -247,7 +249,8 @@ def fetcher_compare_revisions(d):
    return true/false on whether they've changed.
    """

-    data = bb.persist_data.persist('BB_URI_HEADREVS', d).items()
+    pd = persist_data.persist(d)
+    data = pd['BB_URI_HEADREVS'].items()
    data2 = bb.fetch2.saved_headrevs

    changed = False
@@ -349,7 +352,7 @@ def get_srcrev(d):

 def localpath(url, d):
    fetcher = bb.fetch2.Fetch([url], d)
-    return fetcher.localpath(url)
+	return fetcher.localpath(url)

 def runfetchcmd(cmd, d, quiet = False, cleanup = []):
    """
@@ -369,7 +372,7 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
                  'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME']

    for var in exportvars:
-        val = bb.data.getVar(var, d, True)
+        val = data.getVar(var, d, True)
        if val:
            cmd = 'export ' + var + '=\"%s\"; %s' % (val, cmd)

@@ -495,15 +498,15 @@ def srcrev_internal_helper(ud, d, name):
        return ud.parm['tag']

    rev = None
-    pn = bb.data.getVar("PN", d, True)
+    pn = data.getVar("PN", d, True)
    if name != '':
-        rev = bb.data.getVar("SRCREV_%s_pn-%s" % (name, pn), d, True)
+        rev = data.getVar("SRCREV_%s_pn-%s" % (name, pn), d, True)
        if not rev:
-            rev = bb.data.getVar("SRCREV_%s" % name, d, True)
+            rev = data.getVar("SRCREV_%s" % name, d, True)
    if not rev:
-       rev = bb.data.getVar("SRCREV_pn-%s" % pn, d, True)
+       rev = data.getVar("SRCREV_pn-%s" % pn, d, True)
    if not rev:
-        rev = bb.data.getVar("SRCREV", d, True)
+        rev = data.getVar("SRCREV", d, True)
    if rev == "INVALID":
        raise FetchError("Please set SRCREV to a valid value", ud.url)
    if rev == "AUTOINC":
@@ -522,7 +525,6 @@ class FetchData(object):
        self.localpath = None
        self.lockfile = None
        self.mirrortarball = None
-        self.basename = None
        (self.type, self.host, self.path, self.user, self.pswd, self.parm) = decodeurl(data.expand(url, d))
        self.date = self.getSRCDate(d)
        self.url = url
@@ -552,6 +554,15 @@ 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)

@@ -562,19 +573,11 @@ class FetchData(object):
        elif self.localfile:
            self.localpath = self.method.localpath(self.url, self, d)

-        # Note: These files should always be in DL_DIR whereas localpath may not be.
-        basepath = bb.data.expand("${DL_DIR}/%s" % os.path.basename(self.localpath or self.basename), d)
-        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]]
+        if self.localfile and self.localpath:
+            # Note: These files should always be in DL_DIR whereas localpath may not be.
+            basepath = bb.data.expand("${DL_DIR}/%s" % os.path.basename(self.localpath), d)
+            self.donestamp = basepath + '.done'
+            self.lockfile = basepath + '.lock'

    def setup_localpath(self, d):
        if not self.localpath:
@@ -589,12 +592,12 @@ class FetchData(object):
        if "srcdate" in self.parm:
            return self.parm['srcdate']

-        pn = bb.data.getVar("PN", d, True)
+        pn = data.getVar("PN", d, True)

        if pn:
-            return bb.data.getVar("SRCDATE_%s" % pn, d, True) or bb.data.getVar("SRCDATE", d, True) or bb.data.getVar("DATE", d, True)
+            return data.getVar("SRCDATE_%s" % pn, d, True) or data.getVar("SRCDATE", d, True) or data.getVar("DATE", d, True)

-        return bb.data.getVar("SRCDATE", d, True) or bb.data.getVar("DATE", d, True)
+        return data.getVar("SRCDATE", d, True) or data.getVar("DATE", d, True)

 class FetchMethod(object):
    """Base class for 'fetch'ing data"""
@@ -728,7 +731,7 @@ class FetchMethod(object):
                       destdir = urldata.path.rsplit("/", 1)[0]
                    else:
                       destdir = "."
-                    bb.utils.mkdirhier("%s/%s" % (rootdir, destdir))
+                    bb.mkdirhier("%s/%s" % (rootdir, destdir))
                    cmd = 'cp %s %s/%s/' % (file, rootdir, destdir)

        if not cmd:
@@ -739,7 +742,7 @@ class FetchMethod(object):
        os.chdir(rootdir)
        if 'subdir' in urldata.parm:
            newdir = ("%s/%s" % (rootdir, urldata.parm.get('subdir')))
-            bb.utils.mkdirhier(newdir)
+            bb.mkdirhier(newdir)
            os.chdir(newdir)

        cmd = "PATH=\"%s\" %s" % (bb.data.getVar('PATH', data, True), cmd)
@@ -787,10 +790,10 @@ class FetchMethod(object):

        localcount = None
        if name != '':
-            pn = bb.data.getVar("PN", d, True)
-            localcount = bb.data.getVar("LOCALCOUNT_" + name, d, True)
+            pn = data.getVar("PN", d, True)
+            localcount = data.getVar("LOCALCOUNT_" + name, d, True)
        if not localcount:
-            localcount = bb.data.getVar("LOCALCOUNT", d, True)
+            localcount = data.getVar("LOCALCOUNT", d, True)
        return localcount

    localcount_internal_helper = staticmethod(localcount_internal_helper)
@@ -802,13 +805,15 @@ class FetchMethod(object):
        if not hasattr(self, "_latest_revision"):
            raise ParameterError("The fetcher for this URL does not support _latest_revision", url)

-        revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
+        pd = persist_data.persist(d)
+        revs = pd['BB_URI_HEADREVS']
        key = self.generate_revision_key(url, ud, d, name)
-        try:
-            return revs[key]
-        except KeyError:
-            revs[key] = rev = self._latest_revision(url, ud, d, name)
-            return rev
+        rev = revs[key]
+        if rev != None:
+            return str(rev)
+
+        revs[key] = rev = self._latest_revision(url, ud, d, name)
+        return rev

    def sortable_revision(self, url, ud, d, name):
        """
@@ -817,17 +822,18 @@ class FetchMethod(object):
        if hasattr(self, "_sortable_revision"):
            return self._sortable_revision(url, ud, d)

-        localcounts = bb.persist_data.persist('BB_URI_LOCALCOUNT', d)
+        pd = persist_data.persist(d)
+        localcounts = pd['BB_URI_LOCALCOUNT']
        key = self.generate_revision_key(url, ud, d, name)

        latest_rev = self._build_revision(url, ud, d, name)
-        last_rev = localcounts.get(key + '_rev')
+        last_rev = localcounts[key + '_rev']
        uselocalcount = bb.data.getVar("BB_LOCALCOUNT_OVERRIDE", d, True) or False
        count = None
        if uselocalcount:
            count = FetchMethod.localcount_internal_helper(ud, d, name)
        if count is None:
-            count = localcounts.get(key + '_count') or "0"
+            count = localcounts[key + '_count'] or "0"

        if last_rev == latest_rev:
            return str(count + "+" + latest_rev)
@@ -907,6 +913,9 @@ class Fetch(object):
            m = ud.method
            localpath = ""

+            if not ud.localfile:
+                continue
+
            lf = bb.utils.lockfile(ud.lockfile)

            try:
@@ -942,7 +951,7 @@ class Fetch(object):
                        mirrors = mirror_from_string(bb.data.getVar('MIRRORS', self.d, True))
                        localpath = try_mirrors (self.d, ud, mirrors)

-                if not localpath or ((not os.path.exists(localpath)) and localpath.find("*") == -1):
+                if not localpath or not os.path.exists(localpath):
                    raise FetchError("Unable to fetch URL %s from any source." % u, u)

                if os.path.exists(ud.donestamp):
--- a/bitbake/lib/bb/fetch2/bzr.py
+++ b/bitbake/lib/bb/fetch2/bzr.py
@@ -45,8 +45,6 @@ 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)

@@ -66,15 +64,15 @@ class Bzr(FetchMethod):

        options = []

-        if command == "revno":
+        if command is "revno":
            bzrcmd = "%s revno %s %s://%s" % (basecmd, " ".join(options), proto, bzrroot)
        else:
            if ud.revision:
                options.append("-r %s" % ud.revision)

-            if command == "fetch":
+            if command is "fetch":
                bzrcmd = "%s co %s %s://%s" % (basecmd, " ".join(options), proto, bzrroot)
-            elif command == "update":
+            elif command is "update":
                bzrcmd = "%s pull %s --overwrite" % (basecmd, " ".join(options))
            else:
                raise FetchError("Invalid bzr command %s" % command, ud.url)
@@ -95,7 +93,7 @@ class Bzr(FetchMethod):
            bzrcmd = self._buildbzrcommand(ud, d, "fetch")
            bb.fetch2.check_network_access(d, bzrcmd, ud.url)
            logger.debug(1, "BZR Checkout %s", loc)
-            bb.utils.mkdirhier(ud.pkgdir)
+            bb.mkdirhier(ud.pkgdir)
            os.chdir(ud.pkgdir)
            logger.debug(1, "Running %s", bzrcmd)
            runfetchcmd(bzrcmd, d)
--- a/bitbake/lib/bb/fetch2/cvs.py
+++ b/bitbake/lib/bb/fetch2/cvs.py
@@ -139,7 +139,7 @@ class Cvs(FetchMethod):
        else:
            logger.info("Fetch " + loc)
            # check out sources there
-            bb.utils.mkdirhier(pkgdir)
+            bb.mkdirhier(pkgdir)
            os.chdir(pkgdir)
            logger.debug(1, "Running %s", cvscmd)
            bb.fetch2.check_network_access(d, cvscmd, ud.url)
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -57,11 +57,6 @@ class Git(FetchMethod):
        if 'nocheckout' in ud.parm:
            ud.nocheckout = True

-        # rebaseable means the upstream git repo may rebase in the future,
-        # and current revision may disappear from upstream repo
-        # rebaseable is false by default. set rebaseable=1 in SRC_URI if rebaseable.
-        ud.rebaseable = ud.parm.get("rebaseable","0") == "1"
-
        branches = ud.parm.get("branch", "master").split(',')
        if len(branches) != len(ud.names):
            raise bb.fetch2.ParameterError("The number of name and branch parameters is not balanced", ud.url)
@@ -70,29 +65,19 @@ class Git(FetchMethod):
            branch = branches[ud.names.index(name)]
            ud.branches[name] = branch

+        gitsrcname = '%s%s' % (ud.host, ud.path.replace('/', '.'))
+        ud.mirrortarball = 'git2_%s.tar.gz' % (gitsrcname)
+        ud.fullmirror = os.path.join(data.getVar("DL_DIR", d, True), ud.mirrortarball)
+        ud.clonedir = os.path.join(data.expand('${GITDIR}', d), gitsrcname)
+
        ud.basecmd = data.getVar("FETCHCMD_git", d, True) or "git"

-        ud.write_tarballs = ((data.getVar("BB_GENERATE_MIRROR_TARBALLS", d, True) or "0") != "0") or ud.rebaseable
-
-        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)

-        gitsrcname = '%s%s' % (ud.host, ud.path.replace('/', '.'))
-        # for rebaseable git repo, it is necessary to keep mirror tar ball
-        # per revision, so that even the revision disappears from the
-        # upstream repo in the future, the mirror will remain intact and still
-        # contains the revision
-        if ud.rebaseable:
-            for name in ud.names:
-                gitsrcname = gitsrcname + '_' + ud.revisions[name]
-        ud.mirrortarball = 'git2_%s.tar.gz' % (gitsrcname)
-        ud.fullmirror = os.path.join(data.getVar("DL_DIR", d, True), ud.mirrortarball)
-        ud.clonedir = os.path.join(data.expand('${GITDIR}', d), gitsrcname)
+        ud.write_tarballs = (data.getVar("BB_GENERATE_MIRROR_TARBALLS", d, True) or "0") != "0"

        ud.localfile = ud.clonedir

@@ -131,7 +116,7 @@ class Git(FetchMethod):

        # If the checkout doesn't exist and the mirror tarball does, extract it
        if not os.path.exists(ud.clonedir) and os.path.exists(ud.fullmirror):
-            bb.utils.mkdirhier(ud.clonedir)
+            bb.mkdirhier(ud.clonedir)
            os.chdir(ud.clonedir)
            runfetchcmd("tar -xzf %s" % (ud.fullmirror), d)

--- a/bitbake/lib/bb/fetch2/hg.py
+++ b/bitbake/lib/bb/fetch2/hg.py
@@ -57,8 +57,6 @@ 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:
@@ -94,21 +92,21 @@ class Hg(FetchMethod):
        else:
            hgroot = ud.user + "@" + host + ud.path

-        if command == "info":
+        if command is "info":
            return "%s identify -i %s://%s/%s" % (basecmd, proto, hgroot, ud.module)

        options = [];
        if ud.revision:
            options.append("-r %s" % ud.revision)

-        if command == "fetch":
+        if command is "fetch":
            cmd = "%s clone %s %s://%s/%s %s" % (basecmd, " ".join(options), proto, hgroot, ud.module, ud.module)
-        elif command == "pull":
+        elif command is "pull":
            # do not pass options list; limiting pull to rev causes the local
            # repo not to contain it and immediately following "update" command
            # will crash
            cmd = "%s pull" % (basecmd)
-        elif command == "update":
+        elif command is "update":
            cmd = "%s update -C %s" % (basecmd, " ".join(options))
        else:
            raise FetchError("Invalid hg command %s" % command, ud.url)
@@ -133,7 +131,7 @@ class Hg(FetchMethod):
            fetchcmd = self._buildhgcommand(ud, d, "fetch")
            logger.info("Fetch " + loc)
            # check out sources there
-            bb.utils.mkdirhier(ud.pkgdir)
+            bb.mkdirhier(ud.pkgdir)
            os.chdir(ud.pkgdir)
            logger.debug(1, "Running %s", fetchcmd)
            bb.fetch2.check_network_access(d, fetchcmd, ud.url)
--- a/bitbake/lib/bb/fetch2/local.py
+++ b/bitbake/lib/bb/fetch2/local.py
@@ -40,7 +40,6 @@ class Local(FetchMethod):

    def urldata_init(self, ud, d):
        # We don't set localfile as for this fetcher the file is already local!
-        ud.basename = os.path.basename(ud.url.split("://")[1].split(";")[0])
        return

    def localpath(self, url, urldata, d):
@@ -50,9 +49,6 @@ class Local(FetchMethod):
        path = url.split("://")[1]
        path = path.split(";")[0]
        newpath = path
-        dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
-        if os.path.exists(dldirfile):
-            return dldirfile
        if path[0] != "/":
            filespath = data.getVar('FILESPATH', d, True)
            if filespath:
@@ -61,17 +57,8 @@ class Local(FetchMethod):
                filesdir = data.getVar('FILESDIR', d, True)
                if filesdir:
                    newpath = os.path.join(filesdir, path)
-        if not os.path.exists(newpath) and path.find("*") == -1:
-            return dldirfile
        return newpath

-    def need_update(self, url, ud, d):
-        if url.find("*") != -1:
-            return False
-        if os.path.exists(ud.localpath):
-            return False
-        return True
-
    def download(self, url, urldata, d):
        """Fetch urls (no-op for Local method)"""
        # no need to fetch local files, we'll deal with them in place.
--- a/bitbake/lib/bb/fetch2/osc.py
+++ b/bitbake/lib/bb/fetch2/osc.py
@@ -68,9 +68,9 @@ class Osc(FetchMethod):

        coroot = self._strip_leading_slashes(ud.path)

-        if command == "fetch":
+        if command is "fetch":
            osccmd = "%s %s co %s/%s %s" % (basecmd, config, coroot, ud.module, " ".join(options))
-        elif command == "update":
+        elif command is "update":
            osccmd = "%s %s up %s" % (basecmd, config, " ".join(options))
        else:
            raise FetchError("Invalid osc command %s" % command, ud.url)
@@ -96,7 +96,7 @@ class Osc(FetchMethod):
            oscfetchcmd = self._buildosccommand(ud, d, "fetch")
            logger.info("Fetch " + loc)
            # check out sources there
-            bb.utils.mkdirhier(ud.pkgdir)
+            bb.mkdirhier(ud.pkgdir)
            os.chdir(ud.pkgdir)
            logger.debug(1, "Running %s", oscfetchcmd)
            bb.fetch2.check_network_access(d, oscfetchcmd, ud.url)
--- a/bitbake/lib/bb/fetch2/perforce.py
+++ b/bitbake/lib/bb/fetch2/perforce.py
@@ -152,7 +152,7 @@ class Perforce(FetchMethod):

        # create temp directory
        logger.debug(2, "Fetch: creating temporary directory")
-        bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
+        bb.mkdirhier(data.expand('${WORKDIR}', localdata))
        data.setVar('TMPBASE', data.expand('${WORKDIR}/oep4.XXXXXX', localdata), localdata)
        tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, True) or "false")
        tmpfile = tmppipe.readline().strip()
--- a/bitbake/lib/bb/fetch2/repo.py
+++ b/bitbake/lib/bb/fetch2/repo.py
@@ -69,7 +69,7 @@ class Repo(FetchMethod):
        else:
            username = ""

-        bb.utils.mkdirhier(os.path.join(codir, "repo"))
+        bb.mkdirhier(os.path.join(codir, "repo"))
        os.chdir(os.path.join(codir, "repo"))
        if not os.path.exists(os.path.join(codir, "repo", ".repo")):
            bb.fetch2.check_network_access(d, "repo init -m %s -b %s -u %s://%s%s%s" % (ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), ud.url)
--- a/bitbake/lib/bb/fetch2/svk.py
+++ b/bitbake/lib/bb/fetch2/svk.py
@@ -75,7 +75,7 @@ class Svk(FetchMethod):
        localdata = data.createCopy(d)
        data.update_data(localdata)
        logger.debug(2, "Fetch: creating temporary directory")
-        bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
+        bb.mkdirhier(data.expand('${WORKDIR}', localdata))
        data.setVar('TMPBASE', data.expand('${WORKDIR}/oesvk.XXXXXX', localdata), localdata)
        tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, True) or "false")
        tmpfile = tmppipe.readline().strip()
--- a/bitbake/lib/bb/fetch2/svn.py
+++ b/bitbake/lib/bb/fetch2/svn.py
@@ -56,8 +56,6 @@ 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']

@@ -87,7 +85,7 @@ class Svn(FetchMethod):
        if ud.pswd:
            options.append("--password %s" % ud.pswd)

-        if command == "info":
+        if command is "info":
            svncmd = "%s info %s %s://%s/%s/" % (basecmd, " ".join(options), proto, svnroot, ud.module)
        else:
            suffix = ""
@@ -95,9 +93,9 @@ class Svn(FetchMethod):
                options.append("-r %s" % ud.revision)
                suffix = "@%s" % (ud.revision)

-            if command == "fetch":
+            if command is "fetch":
                svncmd = "%s co %s %s://%s/%s%s %s" % (basecmd, " ".join(options), proto, svnroot, ud.module, suffix, ud.module)
-            elif command == "update":
+            elif command is "update":
                svncmd = "%s update %s" % (basecmd, " ".join(options))
            else:
                raise FetchError("Invalid svn command %s" % command, ud.url)
@@ -124,7 +122,7 @@ class Svn(FetchMethod):
            svnfetchcmd = self._buildsvncommand(ud, d, "fetch")
            logger.info("Fetch " + loc)
            # check out sources there
-            bb.utils.mkdirhier(ud.pkgdir)
+            bb.mkdirhier(ud.pkgdir)
            os.chdir(ud.pkgdir)
            logger.debug(1, "Running %s", svnfetchcmd)
            bb.fetch2.check_network_access(d, svnfetchcmd, ud.url)
--- a/bitbake/lib/bb/msg.py
+++ b/bitbake/lib/bb/msg.py
@@ -147,8 +147,8 @@ def set_debug_domains(domainargs):
 #

 def debug(level, msgdomain, msg):
-    warnings.warn("bb.msg.debug is deprecated in favor of the python 'logging' module",
-                  DeprecationWarning, stacklevel=2)
+    warnings.warn("bb.msg.debug will soon be deprecated in favor of the python 'logging' module",
+                  PendingDeprecationWarning, stacklevel=2)
    level = logging.DEBUG - (level - 1)
    if not msgdomain:
        logger.debug(level, msg)
@@ -156,13 +156,13 @@ def debug(level, msgdomain, msg):
        loggers[msgdomain].debug(level, msg)

 def plain(msg):
-    warnings.warn("bb.msg.plain is deprecated in favor of the python 'logging' module",
-                  DeprecationWarning, stacklevel=2)
+    warnings.warn("bb.msg.plain will soon be deprecated in favor of the python 'logging' module",
+                  PendingDeprecationWarning, stacklevel=2)
    logger.plain(msg)

 def note(level, msgdomain, msg):
-    warnings.warn("bb.msg.note is deprecated in favor of the python 'logging' module",
-                  DeprecationWarning, stacklevel=2)
+    warnings.warn("bb.msg.note will soon be deprecated in favor of the python 'logging' module",
+                  PendingDeprecationWarning, stacklevel=2)
    if level > 1:
        if msgdomain:
            logger.verbose(msg)
@@ -175,22 +175,24 @@ def note(level, msgdomain, msg):
            loggers[msgdomain].info(msg)

 def warn(msgdomain, msg):
-    warnings.warn("bb.msg.warn is deprecated in favor of the python 'logging' module",
-                  DeprecationWarning, stacklevel=2)
+    warnings.warn("bb.msg.warn will soon be deprecated in favor of the python 'logging' module",
+                  PendingDeprecationWarning, stacklevel=2)
    if not msgdomain:
        logger.warn(msg)
    else:
        loggers[msgdomain].warn(msg)

 def error(msgdomain, msg):
-    warnings.warn("bb.msg.error is deprecated in favor of the python 'logging' module",
-                  DeprecationWarning, stacklevel=2)
+    warnings.warn("bb.msg.error will soon be deprecated in favor of the python 'logging' module",
+                  PendingDeprecationWarning, stacklevel=2)
    if not msgdomain:
        logger.error(msg)
    else:
        loggers[msgdomain].error(msg)

 def fatal(msgdomain, msg):
+    warnings.warn("bb.msg.fatal will soon be deprecated in favor of raising appropriate exceptions",
+                  PendingDeprecationWarning, stacklevel=2)
    if not msgdomain:
        logger.critical(msg)
    else:
--- a/bitbake/lib/bb/parse/ast.py
+++ b/bitbake/lib/bb/parse/ast.py
@@ -369,13 +369,10 @@ def multi_finalize(fn, d):
        logger.debug(2, "Appending .bbappend file %s to %s", append, fn)
        bb.parse.BBHandler.handle(append, d, True)

-    onlyfinalise = d.getVar("__ONLYFINALISE", False)
-
    safe_d = d
    d = bb.data.createCopy(safe_d)
    try:
-        if not onlyfinalise or "default" in onlyfinalise:
-            finalize(fn, d)
+        finalize(fn, d)
    except bb.parse.SkipPackage:
        bb.data.setVar("__SKIPPED", True, d)
    datastores = {"": safe_d}
@@ -437,8 +434,7 @@ def multi_finalize(fn, d):
    for variant, variant_d in datastores.iteritems():
        if variant:
            try:
-                if not onlyfinalise or variant in onlyfinalise:
-                    finalize(fn, variant_d, variant)
+                finalize(fn, variant_d, variant)
            except bb.parse.SkipPackage:
                bb.data.setVar("__SKIPPED", True, variant_d)

--- a/bitbake/lib/bb/persist_data.py
+++ b/bitbake/lib/bb/persist_data.py
@@ -26,8 +26,7 @@ import logging
 import os.path
 import sys
 import warnings
-from bb.compat import total_ordering
-from collections import Mapping
+import bb.msg, bb.data, bb.utils

 try:
    import sqlite3
@@ -40,11 +39,8 @@ if sqlversion[0] < 3 or (sqlversion[0] == 3 and sqlversion[1] < 3):


 logger = logging.getLogger("BitBake.PersistData")
-if hasattr(sqlite3, 'enable_shared_cache'):
-    sqlite3.enable_shared_cache(True)


-@total_ordering
 class SQLTable(collections.MutableMapping):
    """Object representing a table/domain in the database"""
    def __init__(self, cursor, table):
@@ -66,31 +62,16 @@ class SQLTable(collections.MutableMapping):
                    continue
                raise

-    def __enter__(self):
-        self.cursor.__enter__()
-        return self
-
-    def __exit__(self, *excinfo):
-        self.cursor.__exit__(*excinfo)
-
    def __getitem__(self, key):
        data = self._execute("SELECT * from %s where key=?;" %
                             self.table, [key])
        for row in data:
            return row[1]
-        raise KeyError(key)

    def __delitem__(self, key):
-        if key not in self:
-            raise KeyError(key)
        self._execute("DELETE from %s where key=?;" % self.table, [key])

    def __setitem__(self, key, value):
-        if not isinstance(key, basestring):
-            raise TypeError('Only string keys are supported')
-        elif not isinstance(value, basestring):
-            raise TypeError('Only string values are supported')
-
        data = self._execute("SELECT * from %s where key=?;" %
                                   self.table, [key])
        exists = len(list(data))
@@ -111,40 +92,53 @@ class SQLTable(collections.MutableMapping):

    def __iter__(self):
        data = self._execute("SELECT key FROM %s;" % self.table)
-        return (row[0] for row in data)
+        for row in data:
+            yield row[0]

-    def __lt__(self, other):
-        if not isinstance(other, Mapping):
-            raise NotImplemented
-
-        return len(self) < len(other)
-
-    def values(self):
-        return list(self.itervalues())
+    def iteritems(self):
+        data = self._execute("SELECT * FROM %s;" % self.table)
+        for row in data:
+            yield row[0], row[1]

    def itervalues(self):
        data = self._execute("SELECT value FROM %s;" % self.table)
-        return (row[0] for row in data)
+        for row in data:
+            yield row[0]

-    def items(self):
-        return list(self.iteritems())

-    def iteritems(self):
-        return self._execute("SELECT * FROM %s;" % self.table)
+class SQLData(object):
+    """Object representing the persistent data"""
+    def __init__(self, filename):
+        bb.utils.mkdirhier(os.path.dirname(filename))

-    def clear(self):
-        self._execute("DELETE FROM %s;" % self.table)
+        self.filename = filename
+        self.connection = sqlite3.connect(filename, timeout=5,
+                                          isolation_level=None)
+        self.cursor = self.connection.cursor()
+        self._tables = {}

-    def has_key(self, key):
-        return key in self
+    def __getitem__(self, table):
+        if not isinstance(table, basestring):
+            raise TypeError("table argument must be a string, not '%s'" %
+                            type(table))
+
+        if table in self._tables:
+            return self._tables[table]
+        else:
+            tableobj = self._tables[table] = SQLTable(self.cursor, table)
+            return tableobj
+
+    def __delitem__(self, table):
+        if table in self._tables:
+            del self._tables[table]
+        self.cursor.execute("DROP TABLE IF EXISTS %s;" % table)


 class PersistData(object):
    """Deprecated representation of the bitbake persistent data store"""
    def __init__(self, d):
-        warnings.warn("Use of PersistData is deprecated.  Please use "
-                      "persist(domain, d) instead.",
-                      category=DeprecationWarning,
+        warnings.warn("Use of PersistData will be deprecated in the future",
+                      category=PendingDeprecationWarning,
                      stacklevel=2)

        self.data = persist(d)
@@ -187,19 +181,14 @@ class PersistData(object):
        """
        del self.data[domain][key]

-def connect(database):
-    return sqlite3.connect(database, timeout=30, isolation_level=None)

-def persist(domain, d):
-    """Convenience factory for SQLTable objects based upon metadata"""
-    import bb.data, bb.utils
+def persist(d):
+    """Convenience factory for construction of SQLData based upon metadata"""
    cachedir = (bb.data.getVar("PERSISTENT_DIR", d, True) or
                bb.data.getVar("CACHE", d, True))
    if not cachedir:
        logger.critical("Please set the 'PERSISTENT_DIR' or 'CACHE' variable")
        sys.exit(1)

-    bb.utils.mkdirhier(cachedir)
    cachefile = os.path.join(cachedir, "bb_persist_data.sqlite3")
-    connection = connect(cachefile)
-    return SQLTable(connection, domain)
+    return SQLData(cachefile)
--- a/bitbake/lib/bb/runqueue.py
+++ b/bitbake/lib/bb/runqueue.py
@@ -204,9 +204,9 @@ class RunQueueData:
            ret.extend([nam])
        return ret

-    def get_user_idstring(self, task, task_name_suffix = ""):
+    def get_user_idstring(self, task):
        fn = self.taskData.fn_index[self.runq_fnid[task]]
-        taskname = self.runq_task[task] + task_name_suffix
+        taskname = self.runq_task[task]
        return "%s, %s" % (fn, taskname)

    def get_task_id(self, fnid, taskname):
@@ -929,7 +929,7 @@ class RunQueue:

        if self.state is runQueuePrepare:
            self.rqexe = RunQueueExecuteDummy(self)
-            if self.rqdata.prepare() == 0:
+            if self.rqdata.prepare() is 0:
                self.state = runQueueComplete
            else:
                self.state = runQueueSceneInit
@@ -1018,7 +1018,7 @@ class RunQueueExecute:
        collect the process exit codes and close the information pipe.
        """
        result = os.waitpid(-1, os.WNOHANG)
-        if result[0] == 0 and result[1] == 0:
+        if result[0] is 0 and result[1] is 0:
            return None
        task = self.build_pids[result[0]]
        del self.build_pids[result[0]]
@@ -1060,26 +1060,27 @@ class RunQueueExecute:
        return

    def fork_off_task(self, fn, task, taskname, quieterrors=False):
-        # We need to setup the environment BEFORE the fork, since
-        # a fork() or exec*() activates PSEUDO...
+        the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.get_file_appends(fn), self.cooker.configuration.data)

-        env = {}
-        envbackup = {}
+        env = bb.data.export_vars(the_data)
+        env = bb.data.export_envvars(env, the_data)

        taskdep = self.rqdata.dataCache.task_deps[fn]
        if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
-            envvars = (self.rqdata.dataCache.fakerootenv[fn] or "").split()
-            for key, value in (var.split('=') for var in envvars):
-                envbackup[key] = os.environ.get(key)
-                os.environ[key] = value
-                env[key] = value
-
-            fakedirs = (self.rqdata.dataCache.fakerootdirs[fn] or "").split()
+            envvars = the_data.getVar("FAKEROOTENV", True).split()
+            for var in envvars:
+                comps = var.split("=")
+                env[comps[0]] = comps[1]
+            fakedirs = (the_data.getVar("FAKEROOTDIRS", True) or "").split()
            for p in fakedirs:
-                bb.utils.mkdirhier(p)
+                bb.mkdirhier(p)
+            logger.debug(2, "Running %s:%s under fakeroot, state dir is %s" % (fn, taskname, fakedirs))

-            logger.debug(2, 'Running %s:%s under fakeroot, fakedirs: %s' %
-                            (fn, taskname, ', '.join(fakedirs)))
+        envbackup = os.environ.copy()
+        for e in envbackup:
+            os.unsetenv(e)
+        for e in env:
+            os.putenv(e, env[e])

        sys.stdout.flush()
        sys.stderr.flush()
@@ -1090,7 +1091,6 @@ class RunQueueExecute:
            pid = os.fork()
        except OSError as e:
            bb.msg.fatal(bb.msg.domain.RunQueue, "fork failed: %d (%s)" % (e.errno, e.strerror))
-
        if pid == 0:
            pipein.close()

@@ -1098,6 +1098,12 @@ class RunQueueExecute:
            # events
            bb.event.worker_pid = os.getpid()
            bb.event.worker_pipe = pipeout
+            bb.event.useStdout = False
+
+            # Child processes should send their messages to the UI
+            # process via the server process, not print them
+            # themselves
+            bblogger.handlers = [bb.event.LogHandler()]

            self.rq.state = runQueueChildProcess
            # Make the child the process group leader
@@ -1105,20 +1111,6 @@ class RunQueueExecute:
            # No stdin
            newsi = os.open(os.devnull, os.O_RDWR)
            os.dup2(newsi, sys.stdin.fileno())
-
-
-            the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.get_file_appends(fn), self.cooker.configuration.data)
-
-            env2 = bb.data.export_vars(the_data)
-            env2 = bb.data.export_envvars(env2, the_data)
-
-            for e in os.environ:
-                os.unsetenv(e)
-            for e in env2:
-                os.putenv(e, env2[e])
-            for e in env:
-                os.putenv(e, env[e])
-
            if quieterrors:
                the_data.setVarFlag(taskname, "quieterrors", "1")

@@ -1141,12 +1133,11 @@ class RunQueueExecute:
                os._exit(ret)
            except:
                os._exit(1)
-        else:
-            for key, value in envbackup.iteritems():
-                if value is None:
-                    del os.environ[key]
-                else:
-                    os.environ[key] = value
+
+        for e in env:
+            os.unsetenv(e)
+        for e in envbackup:
+            os.putenv(e, envbackup[e])

        return pid, pipein, pipeout

@@ -1186,25 +1177,6 @@ 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:
@@ -1511,7 +1483,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
    def task_fail(self, task, result):
        self.stats.taskFailed()
        index = self.rqdata.runq_setscene[task]
-        bb.event.fire(sceneQueueTaskFailed(index, self.stats, result, self), self.cfgData)
+        bb.event.fire(runQueueTaskFailed(task, self.stats, result, self), self.cfgData)
        self.scenequeue_notcovered.add(task)
        self.scenequeue_updatecounters(task)

@@ -1644,14 +1616,6 @@ class runQueueTaskFailed(runQueueEvent):
        runQueueEvent.__init__(self, task, stats, rq)
        self.exitcode = exitcode

-class sceneQueueTaskFailed(runQueueTaskFailed):
-    """
-    Event notifing a setscene task failed
-    """
-    def __init__(self, task, stats, exitcode, rq):
-        runQueueTaskFailed.__init__(self, task, stats, exitcode, rq)
-        self.taskstring = rq.rqdata.get_user_idstring(task, "_setscene")
-
 class runQueueTaskCompleted(runQueueEvent):
    """
    Event notifing a task completed
--- a/bitbake/lib/bb/server/xmlrpc.py
+++ b/bitbake/lib/bb/server/xmlrpc.py
@@ -52,8 +52,6 @@ if sys.hexversion < 0x020600F0:
 # implementations from Python 2.6.6's xmlrpclib.
 #
 # Upstream Python bug is #8194 (http://bugs.python.org/issue8194)
-# This bug is relevant for Python 2.7.0 and 2.7.1 but was fixed for
-# Python > 2.7.2
 ##

 class BBTransport(xmlrpclib.Transport):
@@ -109,18 +107,6 @@ class BBTransport(xmlrpclib.Transport):

        return u.close()

-def _create_server(host, port):
-    # Python 2.7.0 and 2.7.1 have a buggy Transport implementation
-    # For those versions of Python, and only those versions, use our
-    # own copy/paste BBTransport class.
-    if (2, 7, 0) <= sys.version_info < (2, 7, 2):
-        t = BBTransport()
-        s = xmlrpclib.Server("http://%s:%d/" % (host, port), transport=t, allow_none=True)
-    else:
-        s = xmlrpclib.Server("http://%s:%d/" % (host, port), allow_none=True)
-
-    return s
-
 class BitBakeServerCommands():
    def __init__(self, server, cooker):
        self.cooker = cooker
@@ -130,8 +116,8 @@ class BitBakeServerCommands():
        """
        Register a remote UI Event Handler
        """
-        s = _create_server(host, port)
-
+        t = BBTransport()
+        s = xmlrpclib.Server("http://%s:%d/" % (host, port), transport=t, allow_none=True)
        return bb.event.register_UIHhandler(s)

    def unregisterEventHandler(self, handlerNum):
@@ -254,7 +240,8 @@ class BitbakeUILauch():

 class BitBakeServerConnection():
    def __init__(self, serverinfo):
-        self.connection = _create_server(serverinfo.host, serverinfo.port)
+        t = BBTransport()
+        self.connection = xmlrpclib.Server("http://%s:%s" % (serverinfo.host, serverinfo.port), transport=t, allow_none=True)
        self.events = uievent.BBUIEventQueue(self.connection)
        for event in bb.event.ui_queue:
            self.events.queue_event(event)
--- a/bitbake/lib/bb/siggen.py
+++ b/bitbake/lib/bb/siggen.py
@@ -1,6 +1,5 @@
 import hashlib
 import logging
-import os
 import re
 import bb.data

--- a/bitbake/lib/bb/ui/crumbs/hobeventhandler.py
+++ b/bitbake/lib/bb/ui/crumbs/hobeventhandler.py
@@ -102,8 +102,6 @@ class HobHandler(gobject.GObject):
        elif isinstance(event, bb.event.CacheLoadCompleted) and pbar:
            pbar.update(bb.ui.crumbs.hobeventhandler.progress_total, bb.ui.crumbs.hobeventhandler.progress_total)
        elif isinstance(event, bb.event.ParseStarted) and pbar:
-            if event.total == 0:
-                return
            pbar.set_title("Processing recipes")
            bb.ui.crumbs.hobeventhandler.progress_total = event.total
            pbar.update(0, bb.ui.crumbs.hobeventhandler.progress_total)
--- a/bitbake/lib/bb/ui/crumbs/runningbuild.py
+++ b/bitbake/lib/bb/ui/crumbs/runningbuild.py
@@ -234,8 +234,6 @@ class RunningBuild (gobject.GObject):
            pbar.update(self.progress_total, self.progress_total)

        elif isinstance(event, bb.event.ParseStarted) and pbar:
-            if event.total == 0:
-                return
            pbar.set_title("Processing recipes")
            self.progress_total = event.total
            pbar.update(0, self.progress_total)
@@ -310,4 +308,4 @@ class RunningBuildTreeView (gtk.TreeView):

        clipboard = gtk.clipboard_get()
        clipboard.set_text(paste_url)
-        clipboard.store()
+        clipboard.store()
--- a/bitbake/lib/bb/ui/depexp.py
+++ b/bitbake/lib/bb/ui/depexp.py
@@ -254,8 +254,6 @@ def main(server, eventHandler):

            if isinstance(event, bb.event.ParseStarted):
                progress_total = event.total
-                if progress_total == 0:
-                    continue
                gtk.gdk.threads_enter()
                pbar.set_title("Processing recipes")
                pbar.update(0, progress_total)
--- a/bitbake/lib/bb/ui/goggle.py
+++ b/bitbake/lib/bb/ui/goggle.py
@@ -105,8 +105,6 @@ def main (server, eventHandler):
        # ignore interrupted io
        if ioerror.args[0] == 4:
            pass
-    except KeyboardInterrupt:
-        pass
    finally:
        server.runCommand(["stateStop"])

--- a/bitbake/lib/bb/ui/hob.py
+++ b/bitbake/lib/bb/ui/hob.py
@@ -420,7 +420,7 @@ class MainWindow (gtk.Window):
        label.show()
        response = dialog.run()
        dialog.destroy()
-        if response == gtk.RESPONSE_YES:
+        if not response == gtk.RESPONSE_YES:
            self.handler.cancel_build()
        return

--- a/bitbake/lib/bb/ui/knotty.py
+++ b/bitbake/lib/bb/ui/knotty.py
@@ -150,17 +150,12 @@ def main(server, eventHandler):
                logger.info(event._message)
                continue
            if isinstance(event, bb.event.ParseStarted):
-                if event.total == 0:
-                    continue
                parseprogress = new_progress("Parsing recipes", event.total).start()
                continue
            if isinstance(event, bb.event.ParseProgress):
                parseprogress.update(event.current)
                continue
            if isinstance(event, bb.event.ParseCompleted):
-                if not parseprogress:
-                    continue
-
                parseprogress.finish()
                print(("Parsing of %d .bb files complete (%d cached, %d parsed). %d targets, %d skipped, %d masked, %d errors."
                    % ( event.total, event.cached, event.parsed, event.virtuals, event.skipped, event.masked, event.errors)))
--- a/bitbake/lib/bb/utils.py
+++ b/bitbake/lib/bb/utils.py
@@ -407,12 +407,13 @@ 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().
    """
-    dirname = os.path.dirname(name)
-    mkdirhier(dirname)
+    path = os.path.dirname(name)
+    if not os.path.isdir(path):
+        logger.error("Lockfile destination directory '%s' does not exist", path)
+        sys.exit(1)

-    if not os.access(dirname, os.W_OK):
-        logger.error("Unable to acquire lock '%s', directory is not writable",
-                     name)
+    if not os.access(path, os.W_OK):
+        logger.error("Error, lockfile path is not writable!: %s" % path)
        sys.exit(1)

    op = fcntl.LOCK_EX
@@ -448,7 +449,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)
--- a/documentation/adt-manual/Makefile
+++ b/documentation/adt-manual/Makefile
@@ -1,44 +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 adt-manual.pdf style.css figures/adt-title.png
-
-validate:
-	xmllint --postvalid --xinclude --noout adt-manual.xml
-
-MANUALS = adt-manual.html adt-manual.pdf
-FIGURES = figures/*.png
-STYLESHEET = *.css
-
-publish:
-	scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/adt-manual
-	scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/adt-manual/figures
-
-clean:
-	rm -f $(MANUALS)
--- a/documentation/adt-manual/adt-command.xml
+++ b/documentation/adt-manual/adt-command.xml
@@ -1,66 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id='using-the-command-line'>
-<title>Using the Command Line</title>
-    <para>
-        Recall that earlier we talked about how to use an existing toolchain 
-        tarball that had been installed into <filename>/opt/poky</filename>, 
-        which is outside of the Poky build environment 
-        (see <xref linkend='using-an-existing-toolchain-tarball'>
-        “Using an Existing Toolchain Tarball”)</xref>.  
-        And, that sourcing your architecture-specific environment setup script 
-        initializes a suitable development environment.  
-        This setup occurs by adding the compiler, QEMU scripts, QEMU binary, 
-        a special version of <filename>pkgconfig</filename> and other useful 
-        utilities to the <filename>PATH</filename> variable.
-        Variables to assist pkgconfig and autotools are also defined so that, 
-        for example, <filename>configure.sh</filename> can find pre-generated 
-        test results for tests that need target hardware on which to run.  
-        These conditions allow you to easily use the toolchain outside of the 
-        Poky build environment on both autotools-based projects and 
-        makefile-based projects.
-    </para>
-
-<section id='autotools-based-projects'>
-<title>Autotools-Based Projects</title>
-    <para>
-        For an autotools-based project you can use the cross-toolchain by just 
-        passing the appropriate host option to <filename>configure.sh</filename>.
-        The host option you use is derived from the name of the environment setup 
-        script in <filename>/opt/poky</filename> resulting from unpacking the 
-        cross-toolchain tarball.
-        For example, the host option for an ARM-based target that uses the GNU EABI 
-        is <filename>armv5te-poky-linux-gnueabi</filename>.
-        Note that the name of the script is 
-        <filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
-        Thus, the following command works:
-        <literallayout class='monospaced'>
-     $ configure &dash;&dash;host-armv5te-poky-linux-gnueabi &dash;&dash;with-libtool-sysroot=&lt;sysroot-dir&gt;
-        </literallayout>
-    </para>
-    <para>
-        This single command updates your project and rebuilds it using the appropriate 
-        cross-toolchain tools.
-    </para>
-</section>
-
-<section id='makefile-based-projects'>
-<title>Makefile-Based Projects</title>
-    <para>
-        For a makefile-based project you use the cross-toolchain by making sure 
-        the tools are used.  
-        You can do this as follows:
-        <literallayout class='monospaced'>
-     CC=arm-poky-linux-gnueabi-gcc
-     LD=arm-poky-linux-gnueabi-ld
-     CFLAGS=”${CFLAGS} &dash;&dash;sysroot=&lt;sysroot-dir&gt;”
-     CXXFLAGS=”${CXXFLAGS} &dash;&dash;sysroot=&lt;sysroot-dir&gt;”
-        </literallayout>
-    </para>
-</section>
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
-->
--- a/documentation/adt-manual/adt-eclipse.xml
+++ b/documentation/adt-manual/adt-eclipse.xml
@@ -1,435 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id='adt-eclipse'>
-<title>Working Within Eclipse</title>
-    <para>
-        The Eclipse IDE is a popular development environment and it fully supports 
-        development using Yocto Project.  
-        When you install and configure the Eclipse Yocto Project Plug-in into 
-        the Eclipse IDE you maximize your Yocto Project design experience.  
-        Installing and configuring the Plug-in results in an environment that 
-        has extensions specifically designed to let you more easily develop software.  
-        These extensions allow for cross-compilation and deployment and execution of 
-        your output into a QEMU emulation session.  
-        You can also perform cross-debugging and profiling.  
-        The environment also has a suite of tools that allows you to perform 
-        remote profiling, tracing, collection of power data, collection of 
-        latency data, and collection of performance data.
-    </para>
-    <para>
-        This section describes how to install and configure the Eclipse IDE 
-        Yocto Plug-in and how to use it to develop your Yocto Project.
-    </para>
-
-<section id='setting-up-the-eclipse-ide'>
-    <title>Setting Up the Eclipse IDE</title>
-    <para>
-        To develop within the Eclipse IDE you need to do the following:
-        <orderedlist>
-            <listitem><para>Be sure the optimal version of Eclipse IDE 
-            is installed.</para></listitem>
-            <listitem><para>Install required Eclipse plug-ins prior to installing 
-            the Eclipse Yocto Plug-in.</para></listitem>
-            <listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem>
-        </orderedlist>
-    </para>
-
-    <section id='installing-eclipse-ide'>
-    <title>Installing Eclipse IDE</title>
-        <para>
-            It is recommended that you have the Helios 3.6.1 version of the 
-            Eclipse IDE installed on your development system.  
-            If you don’t have this version you can find it at 
-            <ulink url='http://www.eclipse.org/downloads'></ulink>.  
-            From that site, choose the Eclipse Classic version.  
-            This version contains the Eclipse Platform, the Java Development 
-            Tools (JDT), and the Plug-in Development Environment.
-        </para>
-        <para>
-            Once you have downloaded the tarball, extract it into a clean 
-            directory and complete the installation.
-        </para>
-        <para>
-            One issue exists that you need to be aware of regarding the Java 
-            Virtual machine’s garbage collection (GC) process.  
-            The GC process does not clean up the permanent generation 
-            space (PermGen).  
-            This space stores meta-data descriptions of classes.  
-            The default value is set too small and it could trigger an 
-            out-of-memory error such as the following:
-            <literallayout class='monospaced'>
-     Java.lang.OutOfMemoryError: PermGen space
-            </literallayout>
-        </para>
-        <para>
-            This error causes the application to hang.
-        </para>
-        <para>
-            To fix this issue you can use the &dash;&dash;vmargs option when you start 
-            Eclipse to increase the size of the permanent generation space:
-            <literallayout class='monospaced'>
-     eclipse &dash;&dash;vmargs &dash;&dash;XX:PermSize=256M
-            </literallayout>
-        </para>
-    </section>
-
-    <section id='installing-required-plug-ins-and-the-eclipse-yocto-plug-in'>
-    <title>Installing Required Plug-ins and the Eclipse Yocto Plug-in</title>
-        <para>
-            Before installing the Yocto Plug-in you need to be sure that the 
-            CDT 7.0, RSE 3.2, and Autotools plug-ins are all installed in the 
-            following order.  
-            After installing these three plug-ins, you can install the 
-            Eclipse Yocto Plug-in.  
-            Use the following URLs for the plug-ins:
-            <orderedlist>
-                <listitem><para><emphasis>CDT 7.0</emphasis> – 
-                <ulink url='http://download.eclipse.org/tools/cdt/releases/helios/'></ulink>:  
-                For CDT main features select the checkbox so you get all items.  
-                For CDT optional features expand the selections and check 
-                “C/C++ Remote Launch”.</para></listitem>
-                <listitem><para><emphasis>RSE 3.2</emphasis> – 
-                <ulink url='http://download.eclipse.org/tm/updates/3.2'></ulink>:  
-                Check the box next to “TM and RSE Main Features” so you select all 
-                those items.  
-                Note that all items in the main features depend on 3.2.1 version.  
-                Expand the items under “TM and RSE Uncategorized 3.2.1” and 
-                select the following:  “Remote System Explorer End-User Runtime”, 
-                “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://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/1.0'></ulink>:
-                Check the box next to “Development tools &amp; SDKs for Yocto Linux” 
-                to select all the items.</para></listitem>
-            </orderedlist>
-        </para>
-        <para>
-            Follow these general steps to install a plug-in:
-            <orderedlist>
-                <listitem><para>From within the Eclipse IDE select the 
-                “Install New Software” item from the “Help” menu.</para></listitem>
-                <listitem><para>Click “Add…” in the “Work with:” area.</para></listitem>
-                <listitem><para>Enter the URL for the repository and leave the “Name” 
-                field blank.</para></listitem>
-                <listitem><para>Check the boxes next to the software you need to 
-                install and then complete the installation.  
-                For information on the specific software packages you need to include, 
-                see the previous list.</para></listitem>
-            </orderedlist>
-        </para>
-    </section>
-
-    <section id='configuring-the-plug-in'>
-    <title>Configuring the Plug-in</title>
-        <para>
-            Configuring the Eclipse Yocto Plug-in involves choosing the Cross 
-            Compiler Options, selecting the Target Architecture, and choosing 
-            the Target Options.  
-            These settings are the default settings for all projects.  
-            You do have opportunities to change them later if you choose to when 
-            you configure the project.  
-            See “Configuring the Cross Toolchain” section later in the manual.
-        </para>
-        <para>
-            To start, you need to do the following from within the Eclipse IDE:
-            <itemizedlist>
-                <listitem><para>Choose Windows -&gt; Preferences to display 
-                the Preferences Dialog</para></listitem>
-                <listitem><para>Click “Yocto SDK”</para></listitem>
-            </itemizedlist>
-        </para>
-
-        <section id='configuring-the-cross-compiler-options'>
-        <title>Configuring the Cross-Compiler Options</title>
-            <para>
-                Choose between ‘SDK Root Mode’ and ‘Poky Tree Mode’ for Cross 
-                Compiler Options.
-                <itemizedlist>
-                    <listitem><para><emphasis>SDK Root Mode</emphasis> – Select this mode 
-                    when you are not concerned with building an image or you do not have 
-                    a Poky build tree on your system.  
-                    For example, suppose you are an application developer and do not 
-                    need to build an image.  
-                    You just want to use an architecture-specific toolchain on an 
-                    existing kernel and root filesystem.  
-                    When you use SDK Root Mode you are using the toolchain installed 
-                    in the <filename>/opt/poky</filename> directory.</para></listitem>
-                    <listitem><para><emphasis>Poky Tree Mode</emphasis> – Select this mode 
-                    if you are concerned with building images for hardware or your 
-                    development environment already has a build tree.  
-                    In this case you likely already have a Poky build tree installed on 
-                    your system or you (or someone else) will be building one.
-                    When you use the Poky Tree Mode you are using the toolchain bundled 
-                    inside the Poky build tree.  
-                    If you use this mode you must also supply the Poky Root Location 
-                    in the Preferences Dialog.</para></listitem>
-                </itemizedlist>
-            </para>
-        </section>
-
-        <section id='configuring-the-sysroot'>
-        <title>Configuring the Sysroot</title>
-            <para>
-                Specify the sysroot, which is used by both the QEMU user-space 
-                NFS boot process and by the cross-toolchain regardless of the 
-                mode you select (SDK Root Mode or Poky Tree Mode).  
-                For example, sysroot is the location to which you extract the 
-                downloaded image’s root filesystem to through the ADT Installer.
-            </para>
-        </section>
-
-        <section id='selecting-the-target-architecture'>
-        <title>Selecting the Target Architecture</title>
-            <para>
-                Use the pull-down Target Architecture menu and select the 
-                target architecture.
-            </para>
-            <para>
-                The Target Architecture is the type of hardware you are 
-                going to use or emulate.  
-                This pull-down menu should have the supported architectures.  
-                If the architecture you need is not listed in the menu then you 
-                will need to re-visit 
-                <xref linkend='adt-prepare'>
-                “Preparing to Use the Application Development Toolkit (ADT)”</xref> 
-                section  earlier in this document.
-            </para>
-        </section>
-
-        <section id='choosing-the-target-options'>
-        <title>Choosing the Target Options</title>
-            <para>
-                You can choose to emulate hardware using the QEMU emulator, or you 
-                can choose to use actual hardware.
-                <itemizedlist>
-                    <listitem><para><emphasis>External HW</emphasis> – Select this option 
-                    if you will be using actual hardware.</para></listitem>
-                    <listitem><para><emphasis>QEMU</emphasis> – Select this option if 
-                    you will be using the QEMU emulator.  
-                    If you are using the emulator you also need to locate the Kernel 
-                    and you can specify custom options.</para>
-                    <para>In Poky Tree Mode the kernel you built will be located in the 
-                    Poky Build tree in <filename>tmp/deploy/images</filename> directory.   
-                    In SDK Root Mode the pre-built kernel you downloaded is located 
-                    in the directory you specified when you downloaded the image.</para>
-                    <para>Most custom options are for advanced QEMU users to further 
-                    customize their QEMU instance.  
-                    These options are specified between paired angled brackets.  
-                    Some options must be specified outside the brackets.
-                    In particular, the options <filename>serial</filename>, 
-                    <filename>nographic</filename>, and <filename>kvm</filename> must all 
-                    be outside the brackets.  
-                    Use the <filename>man qemu</filename> command to get help on all the options
-                    and their use.  
-                    The following is an example:
-                        <literallayout class='monospaced'>
-    serial ‘&lt;-m 256 -full-screen&gt;’
-                        </literallayout>
-                    </para>
-                    <para>
-                    Regardless of the mode, Sysroot is already defined in the “Sysroot” 
-                    field.</para></listitem>
-                </itemizedlist>
-            </para>
-            <para>
-                Click the “OK” button to save your plug-in configurations.
-            </para>
-        </section>
-    </section>
-</section>
-
-<section id='creating-the-project'>
-<title>Creating the Project</title>
-    <para>
-        You can create two types of projects:  Autotools-based, or Makefile-based.  
-        This section describes how to create autotools-based projects from within 
-        the Eclipse IDE.  
-        For information on creating projects in a terminal window see 
-        <xref linkend='using-the-command-line'> “Using the Command Line”</xref> 
-        section.
-    </para>
-    <para>
-        To create a project based on a Yocto template and then display the source code, 
-        follow these steps:
-        <orderedlist>
-            <listitem><para>Select File -> New -> Project.</para></listitem>
-            <listitem><para>Double click “CC++”.</para></listitem>
-            <listitem><para>Double click “C Project” to create the project.</para></listitem>
-            <listitem><para>Double click “Yocto SDK Project”.</para></listitem>
-            <listitem><para>Select “Hello World ANSI C Autotools Project”.  
-            This is an Autotools-based project based on a Yocto Project template.</para></listitem>
-            <listitem><para>Put a name in the “Project name:” field.</para></listitem>
-            <listitem><para>Click “Next”.</para></listitem>
-            <listitem><para>Add information in the “Author” field.</para></listitem>
-            <listitem><para>Use “GNU General Public License v2.0” for the License.</para></listitem>
-            <listitem><para>Click “Finish”.</para></listitem>
-            <listitem><para>Answer ‘Yes” to the open perspective prompt.</para></listitem>
-            <listitem><para>In the Project Explorer expand your project.</para></listitem>
-            <listitem><para>Expand ‘src’.</para></listitem>
-            <listitem><para>Double click on your source file and the code appears 
-            in the window.  
-            This is the template.</para></listitem>
-        </orderedlist>
-    </para>
-</section>
-
-<section id='configuring-the-cross-toolchains'>
-<title>Configuring the Cross-Toolchains</title>
-    <para>
-        The previous section, <xref linkend='configuring-the-cross-compiler-options'>
-        “Configuring the Cross-Compiler Options”</xref>, set up the default project 
-        configurations.  
-        You can change these settings for a given project by following these steps:
-        <orderedlist>
-            <listitem><para>Select Project -> Invoke Yocto Tools -> Reconfigure Yocto.  
-            This brings up the project Yocto Settings Dialog.  
-            Settings are inherited from the default project configuration.  
-            The information in this dialogue is identical to that chosen earlier 
-            for the Cross Compiler Option (SDK Root Mode or Poky Tree Mode), 
-            the Target Architecture, and the Target Options.  
-            The settings are inherited from the Yocto Plug-in configuration performed 
-            after installing the plug-in.</para></listitem>
-            <listitem><para>Select Project -> Reconfigure Project.  
-            This runs the <filename>autogen.sh</filename> in the workspace for your project.  
-            The script runs <filename>libtoolize</filename>, <filename>aclocal</filename>,
-            <filename>autoconf</filename>, <filename>autoheader</filename>, 
-            <filename>automake &dash;&dash;a</filename>, and 
-            <filename>./configure</filename>.</para></listitem>
-        </orderedlist>
-    </para>
-</section>
-
-<section id='building-the-project'>
-<title>Building the Project</title>
-    <para>
-        To build the project, select Project -&gt; Build Project.  
-        You should see the console updated and you can note the cross-compiler you are using.
-    </para>
-</section>
-
-<section id='starting-qemu-in-user-space-nfs-mode'>
-<title>Starting QEMU in User Space NFS Mode</title>
-    <para>
-        To start the QEMU emulator from within Eclipse, follow these steps:
-        <orderedlist>
-            <listitem><para>Select Run -> External Tools -> External Tools Configurations...
-            This selection brings up the External Tools Configurations Dialogue.</para></listitem>
-            <listitem><para>Go to the left navigation area and expand ‘Program’.  
-            You should find the image listed.  
-            For example, qemu-x86_64-poky-linux.</para></listitem>
-            <listitem><para>Click on the image.  
-            This brings up a new environment in the main area of the External 
-            Tools Configurations Dialogue.  
-            The Main tab is selected.</para></listitem>
-            <listitem><para>Click “Run” next.  
-            This brings up a shell window.</para></listitem>
-            <listitem><para>Enter your host root password in the shell window at the prompt.  
-            This sets up a Tap 0 connection needed for running in user-space NFS mode.</para></listitem>
-            <listitem><para>Wait for QEMU to launch.</para></listitem>
-            <listitem><para>Once QEMU launches you need to determine the IP Address 
-            for the user-space NFS.  
-            You can do that by going to a terminal in the QEMU and entering the 
-            <filename>ipconfig</filename> command.</para></listitem>
-        </orderedlist>
-    </para>
-</section>
-
-<section id='deploying-and-debugging-the-application'>
-<title>Deploying and Debugging the Application</title>
-    <para>
-        Once QEMU is running you can deploy your application and use the emulator 
-        to perform debugging.  
-        Follow these steps to deploy the application.
-        <orderedlist>
-            <listitem><para>Select Run -> Debug Configurations...</para></listitem>
-            <listitem><para>In the left area expand “C/C++Remote Application”.</para></listitem>
-            <listitem><para>Locate your project and select it to bring up a new 
-            tabbed view in the Debug Configurations dialogue.</para></listitem>
-            <listitem><para>Enter the absolute path into which you want to deploy 
-            the application.  
-            Use the Remote Absolute File Path for C/C++Application:.  
-            For example, enter <filename>/usr/bin/&lt;programname&gt;</filename>.</para></listitem>
-            <listitem><para>Click on the Debugger tab to see the cross-tool debugger 
-            you are using.</para></listitem>
-            <listitem><para>Create a new connection to the QEMU instance 
-            by clicking on “new”.</para></listitem>
-            <listitem><para>Select “TCF, which means Target Communication Framework.</para></listitem>
-            <listitem><para>Click “Next”.</para></listitem>
-            <listitem><para>Clear out the “host name” field and enter the IP Address 
-            determined earlier.</para></listitem>
-            <listitem><para>Click Finish to close the new connections dialogue.</para></listitem>
-            <listitem><para>Use the drop-down menu now in the “Connection” field and pick 
-            the IP Address you entered.</para></listitem>
-            <listitem><para>Click “Debug” to bring up a login screen and login.</para></listitem>
-            <listitem><para>Accept the debug perspective.</para></listitem>
-        </orderedlist>
-    </para>
-</section>
-
-<section id='running-user-space-tools'>
-<title>Running User-Space Tools</title>
-    <para>
-        As mentioned earlier in the manual several tools exist that enhance 
-        your development experience.  
-        These tools are aids in developing and debugging applications and images.  
-        You can run these user-space tools from within the Yocto Eclipse 
-        Plug-in through the Window -> YoctoTools menu.
-    </para>
-    <para>
-        Once you pick a tool you need to configure it for the remote target. 
-        Every tool needs to have the connection configured. 
-        You must select an existing TCF-based RSE connection to the remote target. 
-        If one does not exist, click "New" to create one.
-    </para>
-    <para>
-        Here are some specifics about the remote tools:
-        <itemizedlist>
-            <listitem><para><emphasis>OProfile:</emphasis>  Selecting this tool causes 
-            the oprofile-server on the remote target to launch on the local host machine.  
-            The oprofile-viewer must be installed on the local host machine and the 
-            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.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>
-            <listitem><para><emphasis>Lttng-ust:</emphasis>  Selecting this tool runs 
-            "usttrace" on the remote target, transfers the output data back to the 
-            local host machine and uses "lttv-gui" to graphically display the output.  
-            The "lttv-gui" must be installed on the local host machine to use this tool.  
-            For information on how to use "lttng" to trace an application, see 
-            <ulink url='http://lttng.org/files/ust/manual/ust.html'></ulink>.</para>
-            <para>For "Application" you must supply the absolute path name of the 
-            application to be traced by user mode lttng.  
-            For example, typing <filename>/path/to/foo</filename> triggers 
-            <filename>usttrace /path/to/foo</filename> on the remote target to trace the 
-            program <filename>/path/to/foo</filename>.</para>
-            <para>"Argument" is passed to <filename>usttrace</filename>
-            running on the remote target.</para></listitem>
-            <listitem><para><emphasis>PowerTOP:</emphasis>  Selecting this tool runs 
-            "PowerTOP" on the remote target machine and displays the results in a 
-            new view called "powertop".</para>
-            <para>"Time to gather data(sec):" is the time passed in seconds before data 
-            is gathered from the remote target for analysis.</para>
-            <para>"show pids in wakeups list:" corresponds to the -p argument 
-            passed to "powertop".</para></listitem>
-            <listitem><para><emphasis>LatencyTOP and Perf:</emphasis>  "LatencyTOP" 
-            identifies system latency, while "perf" monitors the system's 
-            performance counter registers. 
-            Selecting either of these tools causes an RSE terminal view to appear 
-            from which you can run the tools. 
-            Both tools refresh the entire screen to display results while they run.</para></listitem>
-        </itemizedlist>
-    </para>
-</section> 
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
-->
--- a/documentation/adt-manual/adt-intro.xml
+++ b/documentation/adt-manual/adt-intro.xml
@@ -1,117 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id='adt-intro'>
-
-<title>Application Development Toolkit (ADT) User's Guide</title>
-
-<para>
-    Welcome to the Application Development Toolkit User’s Guide.  This manual provides 
-    information that lets you get going with the ADT to develop projects using the Yocto 
-    Project.
-</para>
-
-<section id='book-intro'>
-    <title>Introducing the Application Development Toolkit (ADT)</title>
-    <para>
-        Fundamentally, the ADT consists of an architecture-specific cross-toolchain and 
-        a matching sysroot that are both built by the Poky build system.  
-        The toolchain and sysroot are based on a metadata configuration and extensions, 
-        which allows you to cross develop for the target on the host machine.
-    </para>
-    <para>
-        Additionally, to provide an effective development platform, the Yocto Project 
-        makes available and suggests other tools as part of the ADT.  
-        These other tools include the Eclipse IDE Yocto Plug-in, an emulator (QEMU), 
-        and various user-space tools that greatly enhance your development experience.
-    </para>
-    <para>
-        The resulting combination of the architecture-specific cross-toolchain and sysroot 
-        along with these additional tools yields a custom-built, cross-development platform 
-        for a user-targeted product.
-    </para>
-    
-    <section id='the-cross-toolchain'>
-        <title>The Cross-Toolchain</title>
-        <para>
-            The cross-toolchain consists of a cross-compiler, cross-linker, and cross-debugger 
-            that are all generated through a Poky build that is based on your metadata 
-            configuration or extension for your targeted device.  
-            The cross-toolchain works with a matching target sysroot.
-        </para>
-    </section>
-
-    <section id='sysroot'>
-        <title>Sysroot</title>
-        <para>
-            The matching target sysroot contains needed headers and libraries for generating 
-            binaries that run on the target architecture.  
-            The sysroot is based on the target root filesystem image that is built by 
-            Poky and uses the same metadata configuration used to build the cross-toolchain.
-        </para>
-    </section>
-
-    <section id='the-qemu-emulator'>
-        <title>The QEMU Emulator</title>
-        <para>
-            The QEMU emulator allows you to simulate your hardware while running your 
-            application or image.  
-            QEMU is installed several ways:  as part of the Poky tree, ADT installation 
-            through a toolchain tarball, or through the ADT Installer.
-        </para>
-    </section>
-
-    <section id='user-space-tools'>
-        <title>User-Space Tools</title>
-        <para>
-            User-space tools are included as part of the distribution.  
-            You will find these tools helpful during development.  
-            The tools include LatencyTOP, PowerTOP, OProfile, Perf, SystemTap, and Lttng-ust.  
-            These tools are common development tools for the Linux platform.
-        <itemizedlist>
-            <listitem><para><emphasis>LatencyTOP</emphasis> – LatencyTOP focuses on latency 
-                that causes skips in audio,
-                stutters in your desktop experience, or situations that overload your server 
-                even when you have plenty of CPU power left.  
-                You can find out more about LatencyTOP at 
-                <ulink url='http://www.latencytop.org/'></ulink>.
-            </para></listitem>
-            <listitem><para><emphasis>PowerTOP</emphasis> – Helps you determine what   
-                software is using the most power.  
-                You can find out more about PowerTOP at 
-                <ulink url='http://www.linuxpowertop.org/'></ulink>.
-            </para></listitem>
-            <listitem><para><emphasis>OProfile</emphasis> – A system-wide profiler for Linux 
-                systems that is capable 
-                of profiling all running code at low overhead.  
-                You can find out more about OProfile at 
-                <ulink url='http://oprofile.sourceforge.net/about/'></ulink>.
-            </para></listitem>
-            <listitem><para><emphasis>Perf</emphasis> – Performance counters for Linux used 
-                to keep track of certain 
-                types of hardware and software events.  
-                For more information on these types of counters see 
-                <ulink url='https://perf.wiki.kernel.org/index.php'></ulink> and click 
-                on “Perf tools.”
-            </para></listitem>
-            <listitem><para><emphasis>SystemTap</emphasis> – A free software infrastructure 
-                that simplifies 
-                information gathering about a running Linux system.  
-                This information helps you diagnose performance or functional problems.  
-                SystemTap is not available as a user-space tool through the Yocto Eclipse IDE Plug-in.  
-                See <ulink url='http://sourceware.org/systemtap'></ulink> for more information 
-                on SystemTap.
-            </para></listitem>
-            <listitem><para><emphasis>Lttng-ust</emphasis> – A User-space Tracer designed to 
-                provide detailed information on user-space activity.  
-                See <ulink url='http://lttng.org/ust'></ulink> for more information on Lttng-ust.
-            </para></listitem>
-        </itemizedlist>
-        </para>
-    </section>
-</section>
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
-->
--- a/documentation/adt-manual/adt-manual-customization.xsl
+++ b/documentation/adt-manual/adt-manual-customization.xsl
@@ -1,8 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-  
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
-
-<!--  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>  -->
-
-</xsl:stylesheet>
--- a/documentation/adt-manual/adt-manual.xml
+++ b/documentation/adt-manual/adt-manual.xml
@@ -1,70 +0,0 @@
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<book id='adt-manual' lang='en' 
-      xmlns:xi="http://www.w3.org/2003/XInclude"
-      xmlns="http://docbook.org/ns/docbook"
-      >
-    <bookinfo>
-
-        <mediaobject>
-            <imageobject>
-                <imagedata fileref='figures/adt-title.png' 
-                    format='SVG' 
-                    align='left' scalefit='1' width='100%'/>
-            </imageobject>    
-        </mediaobject>
-
-        <title></title> 
-
-        <authorgroup>
-            <author>
-                <firstname>Jessica</firstname> <surname>Zhang</surname>
-                <affiliation>
-                    <orgname>Intel Corporation</orgname>
-                </affiliation>
-                <email>jessica.zhang@intel.com</email>
-            </author>
-        </authorgroup>
-
-        <revhistory>
-            <revision>
-                <revnumber>1.0</revnumber>
-                <date>6 April 2011</date>
-                <revremark>Initial Document released with Yocto Project 1.0 on 6 April 2011.</revremark>
-            </revision>
-        </revhistory>
-
-    <copyright>
-      <year>2010-2011</year>
-      <holder>Linux Foundation</holder>
-    </copyright>
-
-    <legalnotice>
-      <para>
-        Permission is granted to copy, distribute and/or modify this document under 
-        the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
-      </para>
-    </legalnotice>
-
-    </bookinfo>
-
-    <xi:include href="adt-intro.xml"/>
-
-    <xi:include href="adt-prepare.xml"/>
-
-    <xi:include href="adt-package.xml"/>
-
-    <xi:include href="adt-eclipse.xml"/>
-
-    <xi:include href="adt-command.xml"/>
-
-<!--    <index id='index'>
-      <title>Index</title>
-    </index>
-->
-
-</book>
-<!-- 
-vim: expandtab tw=80 ts=4 
-->
--- a/documentation/adt-manual/adt-package.xml
+++ b/documentation/adt-manual/adt-package.xml
@@ -1,82 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id='adt-package'>
-<title>Optionally Customizing the Development Packages Installation</title>
-    <para>
-        Because the Yocto Project is suited for embedded Linux development it is 
-        likely that you will need to customize your development packages installation.  
-        For example, if you are developing a minimal image then you might not need 
-        certain packages (e.g. graphics support packages).  
-        Thus, you would like to be able to remove those packages from your sysroot.
-    </para>
-
-<section id='package-management-systems'>
-    <title>Package Management Systems</title>
-    <para>
-        The Yocto Project supports the generation of root filesystem files using 
-        three different Package Management Systems (PMS):
-    <itemizedlist>
-        <listitem><para><emphasis>OPKG</emphasis> – A less well known PMS whose use 
-            originated in the OpenEmbedded and OpenWrt embedded Linux projects.  
-            This PMS works with files packaged in an <filename>.ipk</filename> format.
-            See <ulink url='http://en.wikipedia.org/wiki/Opkg'></ulink> for more 
-            information about OPKG.</para></listitem>
-        <listitem><para><emphasis>RPM</emphasis> – A more widely known PMS intended for GNU/Linux 
-            distributions.  
-            This PMS works with files packaged in an <filename>.rms</filename> format.
-            The Yocto Project currently installs through this PMS by default.  
-            See <ulink url='http://en.wikipedia.org/wiki/RPM_Package_Manager'></ulink>
-            for more information about RPM.</para></listitem>
-        <listitem><para><emphasis>Debian</emphasis> – The PMS for Debian-based systems 
-            is built on many PMS tools.  
-            The lower-level PMS tool dpkg forms the base of the Debian PMS.  
-            For information on dpkg see 
-            <ulink url='http://en.wikipedia.org/wiki/Dpkg'></ulink>.</para></listitem>
-    </itemizedlist>
-    </para>
-</section>
-
-<section id='configuring-the-pms'>
-    <title>Configuring the PMS</title>
-    <para>
-        Whichever PMS you are using you need to be sure that the 
-        <filename>PACKAGE_CLASSES</filename> variable in the <filename>conf/local.conf</filename>
-        file is set to reflect that system.  
-        The first value you choose for the variable specifies the package file format for the root
-        filesystem.
-        Additional values specify additional formats for convenience or testing.  
-        See the configuration file for details.
-    </para>
-    <para>
-        As an example, consider a scenario where you are using OPKG and you want to add 
-        the libglade package to sysroot.
-    </para>
-    <para>
-        First, you should generate the ipk file for the libglade package and add it 
-        into a working opkg repository.  
-        Use these commands:
-        <literallayout class='monospaced'>
-     $ bitbake libglade
-     $ bitbake package-index
-        </literallayout>
-    </para>
-    <para>
-        Next, source the environment setup script.  
-        Follow that by setting up the installation destination to point to your 
-        sysroot as <filename>&lt;sysroot dir&gt;</filename>.  
-        Finally, have an opkg configuration file <filename>&lt;conf file&gt;</filename>
-        that corresponds to the opkg repository you have just created. 
-        The following command forms should now work:
-        <literallayout class='monospaced'>
-     $ opkg-cl –f &lt;conf file&gt; -o &lt;sysroot dir&gt; update
-     $ opkg-cl –f &lt;conf file&gt;> -o &lt;sysroot dir&gt; --force-overwrite install libglade
-     $ opkg-cl –f &lt;conf file&gt; -o &lt;sysroot dir&gt; --force-overwrite install libglade-dbg
-     $ opkg-cl –f &lt;conf file&gt; -o &lt;sysroot dir&gt; --force-overwrite install libglade-dev
-        </literallayout>
-    </para>
-</section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
-->
--- a/documentation/adt-manual/adt-prepare.xml
+++ b/documentation/adt-manual/adt-prepare.xml
@@ -1,244 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id='adt-prepare'>
-
-<title>Preparing to Use the Application Development Toolkit (ADT)</title>
-
-<para>
-    In order to use the ADT it must be installed, the environment setup script must be 
-    sourced, and the kernel and filesystem image specific to the target architecture must exist.  
-    This section describes how to install the ADT, set up the environment, and provides 
-    some reference information on kernels and filesystem images.
-</para>
-
-<section id='installing-the-adt'>
-    <title>Installing the ADT</title>
-    <para>
-        You can install the ADT three ways.  
-        However, we recommend configuring and running the ADT Installer script.  
-        Running this script automates much of the process for you.  
-        For example, the script allows you to install the QEMU emulator and 
-        user-space NFS, define which root filesystem profiles to download, 
-        and allows you to define the target sysroot location.
-    </para>
-    <note>
-        If you need to generate the ADT tarball you can do so using the following command:
-        <literallayout class='monospaced'>
-     $ bitbake adt-installer
-        </literallayout>
-        This command generates the file <filename>adt-installer.tar.bz2</filename>
-        in the <filename>../build/tmp/deploy/sdk</filename> directory.
-    </note>
-
-    <section id='configuring-and-running-the-adt-installer'>
-        <title>Configuring and Running the ADT Installer</title>
-        <para>
-            The ADT Installer is contained in a tarball that can be built using 
-            <filename>bitbake adt-installer</filename>. 
-            Yocto Project has a pre-built ADT Installer tarball that you can download 
-            from <filename>tmp/deploy/sdk</filename> located in the build directory.
-        </para>
-
-        <note>
-            You can install and run the ADT Installer tarball in any directory you want.
-        </note>
-
-        <para>
-            Before running the ADT Installer you need to configure it by editing 
-            the <filename>adt-installer.conf</filename> file, which is located in the 
-            directory where the ADT Installer tarball was installed.  
-            Your configurations determine which kernel and filesystem image are downloaded.  
-            The following list describes the variables you can define for the ADT Installer.  
-            For configuration values and restrictions see the comments in  
-            the <filename>adt-installer.conf</filename> file:
-
-            <itemizedlist>
-                <listitem><para><filename>YOCTOADT_IPKG_REPO</filename> – This area 
-                includes the IPKG-based packages and the root filesystem upon which 
-                the installation is based.  
-                If you want to set up your own IPKG repository pointed to by 
-                <filename>YOCTOADT_IPKG_REPO</filename>, you need to be sure that the 
-                directory structure follows the same layout as the reference directory 
-                set up at <ulink url='http://adtrepo.yoctoproject.org'></ulink>.  
-                Also, your repository needs to be accessible through HTTP.
-                </para></listitem>
-                <listitem><para><filename>YOCTOADT-TARGETS</filename> – The machine 
-                target architectures for which you want to set up cross-development 
-                environments.
-                </para></listitem>
-                <listitem><para><filename>YOCTOADT_QEMU</filename> – Indicates whether 
-                or not to install the emulator QEMU.
-                </para></listitem>
-                <listitem><para><filename>YOCTOADT_NFS_UTIL</filename> – Indicates whether 
-                or not to install user-mode NFS.  
-                If you plan to use the Yocto Eclipse IDE plug-in against QEMU, 
-                you should install NFS.
-                    <note>
-                    To boot QEMU images using our userspace NFS server, you need 
-                    to be running portmap or rpcbind. 
-                    If you are running rpcbind, you will also need to add the -i 
-                    option when rpcbind starts up. 
-                    Please make sure you understand the security implications of doing this. 
-                    Your firewall settings may also have to be modified to allow 
-                    NFS booting to work.
-                    </note>
-                </para></listitem>
-                <listitem><para><filename>YOCTOADT_ROOTFS_&lt;arch&gt;</filename> - The root 
-                filesystem images you want to download.
-                </para></listitem>
-                <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_IMAGE_&lt;arch&gt;</filename> - The 
-                root filesystem used to extract and create the target sysroot.
-                </para></listitem>
-                <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_LOC_&lt;arch&gt;</filename> - The 
-                location of the target sysroot that will be set up on the development machine.
-                </para></listitem>
-            </itemizedlist>
-        </para>
-
-        <para>
-            After you have configured the <filename>adt-installer.conf</filename> file, 
-            run the installer using the following command:
-            <literallayout class='monospaced'>
-     $ adt_installer
-            </literallayout>
-        </para>
-
-        <para>
-            Once the installer begins to run you are asked whether you want to run in 
-            interactive or silent mode.  
-            If you want to closely monitor the installation then choose “I” for interactive 
-            mode rather than “S” for silent mode.  
-            Follow the prompts from the script to complete the installation.
-        </para>
-
-        <para>
-            Once the installation completes, the cross-toolchain is installed in 
-            <filename>/opt/poky/$SDKVERSION</filename>.
-        </para>
-
-        <para>
-            Before using the ADT you need to run the environment setup script for 
-            your target architecture also located in <filename>/opt/poky/$SDKVERSION</filename>.
-            See the <xref linkend='setting-up-the-environment'>“Setting Up the Environment”</xref> 
-            section for information.
-        </para>
-    </section>
-
-    <section id='using-an-existing-toolchain-tarball'>
-        <title>Using an Existing Toolchain Tarball</title>
-        <para>
-            If you do not want to use the ADT Installer you can install the toolchain 
-            and the sysroot by hand.  
-            Follow these steps:
-            <orderedlist>
-                <listitem><para>Locate and download the architecture-specific toolchain 
-                tarball from <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.0'></ulink>.
-                Look in the ‘toolchain’ folder and then open up the folder that matches your 
-                host development system (i.e. 'i686' for 32-bit machines or 'x86_64' 
-                for 64-bit machines).  
-                Then, select the toolchain tarball whose name includes the appropriate 
-                target architecture.
-                <note>
-                    If you need to build the toolchain tarball use the 
-                    <filename>bitbake meta-toolchain</filename> command after you have 
-                    sourced the poky-build-init script.  
-                    The tarball will be located in the build directory at 
-                    <filename>tmp/deploy/sdk</filename> after the build.
-                </note>
-                </para></listitem>
-                <listitem><para>Make sure you are in the root directory and then expand 
-                the tarball.  
-                The tarball expands into the <filename>/opt/poky/$SDKVERSION</filename> directory.
-                </para></listitem>
-                <listitem><para>Set up the environment by sourcing the environment set up 
-                script.  
-                See the <xref linkend='setting-up-the-environment'>“Setting Up the Environment”</xref>
-                for information.
-                </para></listitem>
-            </orderedlist>
-        </para>
-    </section>
-
-    <section id='using-the-toolchain-from-within-the-build-tree'>
-        <title>Using the Toolchain from Within the Build Tree</title>
-        <para>
-            A final way of accessing the toolchain is from the build tree.  
-            The build tree can be set up to contain the architecture-specific cross toolchain.  
-            To populate the build tree with the toolchain you need to run the following command:
-            <literallayout class='monospaced'>  
-     $ bitbake meta-ide-support
-            </literallayout>
-        </para>
- 
-        <para>
-            Before running the command you need to be sure that the 
-            <filename>conf/local.conf</filename> file in the build directory has 
-            the desired architecture specified for the <filename>MACHINE</filename> 
-            variable.
-            See the <filename>local.conf</filename> file for a list of values you 
-            can supply for this variable.  
-            You can populate the build tree with the cross-toolchains for more 
-            than a single architecture.  
-            You just need to edit the <filename>local.conf</filename> file and re-run 
-            the BitBake command.
-        </para>
-
-        <para>
-            Once the build tree has the toolchain you need to source the environment 
-            setup script so that you can run the cross-tools without having to locate them.  
-            See the <xref linkend='setting-up-the-environment'>“Setting Up the Environment”</xref>
-            for information.
-        </para>
-    </section>
-</section>
-
-<section id='setting-up-the-environment'>
-    <title>Setting Up the Environment</title>
-    <para>
-        Before you can use the cross-toolchain you need to set up the environment by 
-        sourcing the environment setup script.  
-        If you used adt_installer or used an existing ADT tarball to install the ADT,
-        then you can find this script in the <filename>/opt/poky/$SDKVERSION</filename>
-        directory.  
-        If you are using the ADT from a Poky build tree, then look in the build 
-        directory in <filename>tmp</filename> for the setup script.
-    </para>
-
-    <para> 
-        Be sure to run the environment setup script that matches the architecture for 
-        which you are developing.  
-        Environment setup scripts begin with the string “environment-setup” and include as 
-        part of their name the architecture.  
-        For example, the environment setup script for a 64-bit IA-based architecture would 
-        be the following: 
-        <literallayout class='monospaced'>
-     /opt/poky/environment-setup-x86_64-poky-linux
-        </literallayout>
-    </para>
-</section>
-
-<section id='kernels-and-filesystem-images'>
-    <title>Kernels and Filesystem Images</title>
-    <para>
-        You will need to have a kernel and filesystem image to boot using your 
-        hardware or the QEMU emulator.  
-        That means you either have to build them or know where to get them.  
-        You can find lots of details on how to get or build images and kernels for your 
-        architecture in the "Yocto Project Quick Start" found at 
-        <ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html'></ulink>.
-        <note> 
-            Yocto Project provides basic kernels and filesystem images for several 
-            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-1.0/'></ulink>
-            and are ideal for experimentation within Yocto Project.
-        </note>
-    </para>
-</section>
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
-->
--- a/documentation/adt-manual/figures/adt-title.png
+++ b/documentation/adt-manual/figures/adt-title.png
--- a/documentation/adt-manual/style.css
+++ b/documentation/adt-manual/style.css
@@ -1,968 +0,0 @@
-/* 
-   Generic XHTML / DocBook XHTML CSS Stylesheet.
-   
-   Browser wrangling and typographic design by
-      Oyvind Kolas / pippin@gimp.org
-
-   Customised for Poky by
-      Matthew Allum / mallum@o-hand.com
-
-   Thanks to:
-     Liam R. E. Quin
-     William Skaggs
-     Jakub Steiner
-
-   Structure
-   ---------
-
-   The stylesheet is divided into the following sections:
-
-       Positioning
-          Margins, paddings, width, font-size, clearing.
-       Decorations
-          Borders, style
-       Colors
-          Colors
-       Graphics
-          Graphical backgrounds
-       Nasty IE tweaks
-          Workarounds needed to make it work in internet explorer,
-          currently makes the stylesheet non validating, but up until
-          this point it is validating.
-       Mozilla extensions
-          Transparency for footer
-	  Rounded corners on boxes
-
-*/
-
-
-  /*************** /
- /  Positioning   /
-/ ***************/
-
-body {
-  font-family: Verdana, Sans, sans-serif;
- 
-  min-width: 640px;
-  width: 80%;
-  margin:  0em auto;
-  padding: 2em 5em 5em 5em;
-  color: #333;
-}
-
-.reviewer {
-  color: red;
-}
-
-h1,h2,h3,h4,h5,h6,h7 {
-  font-family: Arial, Sans;
-  color: #00557D;
-  clear: both;
-}
-
-h1 {
-  font-size: 2em;
-  text-align: left;
-  padding: 0em 0em 0em 0em;
-  margin: 2em 0em 0em 0em;
-}
-
-h2.subtitle {
-  margin: 0.10em 0em 3.0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 1.8em;
-  padding-left: 20%;
-  font-weight: normal;
-  font-style: italic;
-}
-
-h2 {
-  margin: 2em 0em 0.66em 0em;
-  padding: 0.5em 0em 0em 0em;
-  font-size: 1.5em;
-  font-weight: bold;
-}
-
-h3.subtitle {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 142.14%;
-  text-align: right;
-}
-
-h3 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 140%;
-  font-weight: bold;
-}
-
-h4 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 120%;
-  font-weight: bold;
-}
-
-h5 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-h6 {
-  margin: 1em 0em 0em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 80%;
-  font-weight: bold;
-}
-
-.authorgroup {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  padding-top: 256px;
-  background-image: url("figures/adt-title.png");
-  background-position: left top;
-  margin-top: -256px;
-  padding-right: 50px;
-  margin-left: 0px;
-  text-align: right;
-  width: 740px;
-}
-
-h3.author {
-  margin: 0em 0me 0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-weight: normal;
-  font-size: 100%;
-  color: #333;
-  clear: both;
-}
-
-.author tt.email {
-  font-size: 66%;
-}
-
-.titlepage hr {
-  width: 0em;
-  clear: both;
-}
-
-.revhistory {
-  padding-top: 2em;
-  clear: both;
-}
-
-.toc,
-.list-of-tables,
-.list-of-examples,
-.list-of-figures {
-  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
-}
-
-.toc p,
-.list-of-tables p,
-.list-of-figures p,
-.list-of-examples p {
-  padding: 0em 0em 0em 0em;
-  padding: 0em 0em 0.3em;
-  margin: 1.5em 0em 0em 0em;
-}
-
-.toc p b,
-.list-of-tables p b,
-.list-of-figures p b,
-.list-of-examples p b{
-  font-size: 100.0%;
-  font-weight: bold;
-}
-
-.toc dl,
-.list-of-tables dl,
-.list-of-figures dl,
-.list-of-examples dl {
-  margin: 0em 0em 0.5em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dt {
-  margin: 0em 0em 0em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dd {
-  margin: 0em 0em 0em 2.6em;
-  padding: 0em 0em 0em 0em;
-}
-
-div.glossary dl,
-div.variablelist dl {
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  font-weight: normal;
-  width: 20em;
-  text-align: right;
-}
-
-.variablelist dl dt {
-  margin-top: 0.5em;
-}
-
-.glossary dl dd,
-.variablelist dl dd {
-  margin-top: -1em;
-  margin-left: 25.5em;
-}
-
-.glossary dd p,
-.variablelist dd p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-
-div.calloutlist table td {
-  padding: 0em 0em 0em 0em;
-  margin: 0em 0em 0em 0em;
-}
-
-div.calloutlist table td p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-div p.copyright {
-  text-align: left;
-}
-
-div.legalnotice p.legalnotice-title {
-  margin-bottom: 0em;
-}
-
-p {
-  line-height: 1.5em;
-  margin-top: 0em;
-  
-}
-
-dl {
-  padding-top: 0em;
-}
-
-hr {
-  border: solid 1px;
-}
-
-
-.mediaobject,
-.mediaobjectco {
-  text-align: center;
-}
-
-img {
-  border: none;
-}
-
-ul {
-  padding: 0em 0em 0em 1.5em;
-}
-
-ul li {
-  padding: 0em 0em 0em 0em;
-}
-
-ul li p {
-  text-align: left;
-}
-
-table {
-  width :100%;
-}
-
-th {
-  padding: 0.25em;
-  text-align: left;
-  font-weight: normal;
-  vertical-align: top;
-}
-
-td {
-  padding: 0.25em;
-  vertical-align: top;
-}
-
-p a[id] {
-  margin: 0px;
-  padding: 0px;
-  display: inline;
-  background-image: none;
-} 
-
-a {
-  text-decoration: underline;
-  color: #444;
-}
-
-pre {
-    overflow: auto;
-}
-
-a:hover {
-  text-decoration: underline;
-  /*font-weight: bold;*/
-}
-
-
-div.informalfigure,
-div.informalexample,
-div.informaltable,
-div.figure,
-div.table,
-div.example {
-  margin: 1em 0em;
-  padding: 1em;
-  page-break-inside: avoid;
-}
-
-
-div.informalfigure p.title b,
-div.informalexample p.title b,
-div.informaltable p.title b,
-div.figure p.title b,
-div.example p.title b,
-div.table p.title b{
-    padding-top: 0em;
-    margin-top: 0em;
-    font-size: 100%;
-    font-weight: normal;
-}
-
-.mediaobject .caption, 
-.mediaobject .caption p  {
-  text-align: center;
-  font-size: 80%;  
-  padding-top: 0.5em;
-  padding-bottom: 0.5em;
-}
-
-.epigraph {
-  padding-left: 55%;
-  margin-bottom: 1em;
-}
-
-.epigraph p {
-  text-align: left;
-}
-
-.epigraph .quote {
-  font-style: italic;
-}
-.epigraph .attribution {
-  font-style: normal;
-  text-align: right;
-}
-
-span.application {
-  font-style: italic;
-}
-
-.programlisting {
-  font-family: monospace;
-  font-size: 80%;
-  white-space: pre;
-  margin: 1.33em 0em;
-  padding: 1.33em;
-}
-
-.tip,
-.warning,
-.caution,
-.note {
-  margin-top: 1em;
-  margin-bottom: 1em;
-
-}
-
-/* force full width of table within div */
-.tip table,
-.warning table,
-.caution table,
-.note table {
-  border: none;
-  width: 100%;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  padding: 0.8em 0.0em 0.0em 0.0em;
-  margin : 0em 0em 0em 0em;
-}
-
-.tip p,
-.warning p,
-.caution p,
-.note p {
-  margin-top: 0.5em;
-  margin-bottom: 0.5em;
-  padding-right: 1em;
-  text-align: left;
-}
-
-.acronym {
-  text-transform: uppercase;
-}
-
-b.keycap,
-.keycap {
-  padding: 0.09em 0.3em;
-  margin: 0em;
-}
-
-.itemizedlist li {
-  clear: none;
-}
-
-.filename {
-  font-size: medium;
-  font-family: Courier, monospace;
-}
-
-
-div.navheader, div.heading{
-  position: absolute;
-  left: 0em;
-  top: 0em;
-  width: 100%;
-  background-color: #cdf;
-  width: 100%;
-}
-
-div.navfooter, div.footing{
-  position: fixed;
-  left: 0em;
-  bottom: 0em;
-  background-color: #eee;
-  width: 100%;
-}
-
-
-div.navheader td,
-div.navfooter td {
-  font-size: 66%;
-}
-
-div.navheader table th {
-  /*font-family: Georgia, Times, serif;*/
-  /*font-size: x-large;*/
-  font-size: 80%;
-}
-
-div.navheader table {
-  border-left: 0em;
-  border-right: 0em;
-  border-top: 0em;
-  width: 100%;
-}
-
-div.navfooter table {
-  border-left: 0em;
-  border-right: 0em;
-  border-bottom: 0em;
-  width: 100%;
-}
-
-div.navheader table td a,
-div.navfooter table td a {
-  color: #777;
-  text-decoration: none;
-}
-
-/* normal text in the footer */
-div.navfooter table td {
-  color: black;
-}
-
-div.navheader table td a:visited,
-div.navfooter table td a:visited {
-  color: #444;
-}
-
-
-/* links in header and footer */
-div.navheader table td a:hover,
-div.navfooter table td a:hover {
-  text-decoration: underline;
-  background-color: transparent;
-  color: #33a;
-}
-
-div.navheader hr,
-div.navfooter hr {
-  display: none;
-}
-
-
-.qandaset tr.question td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.qandaset tr.answer td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-.answer td {
-  padding-bottom: 1.5em;
-}
-
-.emphasis {
-  font-weight: bold;
-}
-
-
-  /************* /
- / decorations  /
-/ *************/
-
-.titlepage {
-}
-
-.part .title {
-}
-
-.subtitle {
-    border: none;
-}
-
-/*
-h1 {
-  border: none;
-}
-
-h2 {
-  border-top: solid 0.2em;
-  border-bottom: solid 0.06em;
-}
-
-h3 {
-  border-top: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h4 {
-  border: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h5 {
-  border: 0em;
-}
-*/
-
-.programlisting {
-  border: solid 1px;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example {
-  border: 1px solid;
-}
-
-
-
-.tip,
-.warning,
-.caution,
-.note {
-  border: 1px solid;
-}
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom: 1px solid;
-}
-
-.question td {
-  border-top: 1px solid black;
-}
-
-.answer {
-}
-
-
-b.keycap,
-.keycap {
-  border: 1px solid;
-}
-  
-
-div.navheader, div.heading{
-  border-bottom: 1px solid;
-}
-
-
-div.navfooter, div.footing{
-  border-top: 1px solid;
-}
-
-  /********* /
- /  colors  /
-/ *********/
-
-body {
-  color: #333;
-  background: white;
-}
-
-a {
-  background: transparent;
-}
-
-a:hover {
-  background-color: #dedede;
-}
-
-
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7,
-h8 {
-  background-color: transparent;
-}
-
-hr {
-  border-color: #aaa;
-}
-
-
-.tip, .warning, .caution, .note {
-  border-color: #aaa;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom-color: #aaa;
-}
-
-
-.warning {
-  background-color: #fea;
-}
-
-.caution {
-  background-color: #fea;
-}
-
-.tip {
-  background-color: #eff;
-}
-
-.note {
-  background-color: #dfc;
-}
-
-.glossary dl dt, 
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  color: #044;
-}
-
-div.figure,
-div.table,
-div.example,
-div.informalfigure,
-div.informaltable,
-div.informalexample {
-  border-color: #aaa;
-}
-
-pre.programlisting {
-  color: black;
-  background-color: #fff;
-  border-color: #aaa;
-  border-width: 2px;
-}
-
-.guimenu,
-.guilabel,
-.guimenuitem {
-  background-color: #eee;
-}
-
-
-b.keycap,
-.keycap {
-  background-color: #eee;
-  border-color: #999;
-}
-
-
-div.navheader {
-  border-color: black;
-}
-
-
-div.navfooter {
-  border-color: black;
-}
-
-
-  /*********** /
- /  graphics  /
-/ ***********/
-
-/*
-body {
-  background-image: url("images/body_bg.jpg");
-  background-attachment: fixed;
-}
-
-.navheader,
-.note,
-.tip {
-  background-image: url("images/note_bg.jpg");
-  background-attachment: fixed;
-}
-
-.warning,
-.caution {
-  background-image: url("images/warning_bg.jpg");
-  background-attachment: fixed;
-}
-
-.figure,
-.informalfigure,
-.example,
-.informalexample,
-.table,
-.informaltable {
-  background-image: url("images/figure_bg.jpg");
-  background-attachment: fixed;
-}
-
-*/
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7{
-}
-
-/*
-Example of how to stick an image as part of the title.
-
-div.article .titlepage .title
-{
-  background-image: url("figures/white-on-black.png");
-  background-position: center;
-  background-repeat: repeat-x;
-}
-*/
-
-div.preface .titlepage .title, 
-div.colophon .title, 
-div.chapter .titlepage .title,
-div.article .titlepage .title 
-{
-}
-
-div.section div.section .titlepage .title,
-div.sect2 .titlepage .title {
-    background: none;
-}
-
-
-h1.title {
-  background-color: transparent;
-  background-image: url("figures/yocto-project-bw.png");
-  background-repeat: no-repeat;
-  height: 256px;
-  text-indent: -9000px;
-  overflow:hidden;
-}
-
-h2.subtitle {
-  background-color: transparent;
-  text-indent: -9000px;
-  overflow:hidden;
-  width: 0px;
-  display: none;
-}
-
-  /*************************************** /
- /  pippin.gimp.org specific alterations  /
-/ ***************************************/
-
-/*
-div.heading, div.navheader {
-  color: #777;
-  font-size: 80%;
-  padding: 0;
-  margin: 0;
-  text-align: left;
-  position: absolute;
-  top: 0px;
-  left: 0px;
-  width: 100%;
-  height: 50px;
-  background: url('/gfx/heading_bg.png') transparent;
-  background-repeat: repeat-x;
-  background-attachment: fixed;
-  border: none;
-}
-
-div.heading a {
-  color: #444;
-}
-
-div.footing, div.navfooter {
-  border: none;
-  color: #ddd;
-  font-size: 80%;
-  text-align:right;
-
-  width: 100%;
-  padding-top: 10px;
-  position: absolute;
-  bottom: 0px;
-  left: 0px;
-
-  background: url('/gfx/footing_bg.png') transparent;
-}
-*/
-
-
-
-  /****************** /
- /  nasty ie tweaks  /
-/ ******************/
-
-/*
-div.heading, div.navheader {
-  width:expression(document.body.clientWidth + "px");
-}
-
-div.footing, div.navfooter {
-  width:expression(document.body.clientWidth + "px");
-  margin-left:expression("-5em");
-}
-body {
-  padding:expression("4em 5em 0em 5em");
-}
-*/
-
-  /**************************************** /
- / mozilla vendor specific css extensions  /
-/ ****************************************/
-/*
-div.navfooter, div.footing{
-  -moz-opacity: 0.8em;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example,
-.tip,
-.warning,
-.caution,
-.note {
-  -moz-border-radius: 0.5em;
-}
-
-b.keycap,
-.keycap {
-  -moz-border-radius: 0.3em;
-}
-*/
-
-table tr td table tr td {
-  display: none;
-}
-
-
-hr {
-  display: none;
-}
-
-table {
-  border: 0em;
-}
-
- .photo {
-  float: right;
-  margin-left:   1.5em;
-  margin-bottom: 1.5em;
-  margin-top: 0em;
-  max-width:      17em;
-  border:     1px solid gray;
-  padding:    3px;
-  background: white;
-}
- .seperator {
-   padding-top: 2em;
-   clear: both;
-  }
-
-  #validators {
-      margin-top: 5em;
-      text-align: right;
-      color: #777;
-  }
-  @media print {
-      body {
-          font-size: 8pt;
-      }
-      .noprint {
-          display: none;
-      }
-  }
-
-
-.tip,
-.note {
-   background: #666666;
-   color: #fff;   
-   padding: 20px;
-   margin: 20px;
-}
-
-.tip h3,
-.note h3 {
-   padding: 0em;
-   margin: 0em;
-   font-size: 2em;
-   font-weight: bold;
-   color: #fff;   
-}
-
-.tip a,
-.note a {
-   color: #fff;   
-   text-decoration: underline;
-}
--- a/documentation/bsp-guide/Makefile
+++ b/documentation/bsp-guide/Makefile
@@ -2,7 +2,7 @@ XSLTOPTS = --stringparam html.stylesheet style.css \
           --stringparam  chapter.autolabel 1 \
           --stringparam  section.autolabel 1 \
           --stringparam  section.label.includes.component.label 1 \
-         --xinclude
+	   --xinclude

 ##
 # These URI should be rewritten by your distribution's xml catalog to
@@ -20,18 +20,16 @@ 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 bsp-guide.pdf figures/bsp-title.png
+	tar -cvzf bsp-guide.tgz style.css bsp-guide.html figures/bsp-title.png

 validate:
 	xmllint --postvalid --xinclude --noout bsp-guide.xml

-MANUALS = bsp-guide.html bsp-guide.pdf
-FIGURES = figures/*.png
-STYLESHEET = *.css
+OUTPUTS = bsp-guide.pdf bsp-guide.html
+SOURCES = *.png *.xml *.css *.svg

 publish:
-	scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/bsp-guide
-	scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/bsp-guide/figures
+	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/

 clean:
 	rm -f $(OUTPUTS)
--- a/documentation/bsp-guide/bsp-guide.xml
+++ b/documentation/bsp-guide/bsp-guide.xml
@@ -23,7 +23,7 @@
                <affiliation>
                    <orgname>Intel Corporation</orgname>
                </affiliation>
-                <email>richard.purdie@linuxfoundation.org</email>
+                <email>richard@linux.intel.com</email>
            </author>
        </authorgroup>

@@ -31,13 +31,7 @@
            <revision>
                <revnumber>0.9</revnumber>
                <date>27 October 2010</date>
-                <revremark>This manual revision is the initial manual and corresponds to the 
-                    Yocto Project 0.9 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.0</revnumber>
-                <date>6 April 2011</date>
-                <revremark>This manual revision corresponds to the Yocto Project 1.0 Release.</revremark>
+                <revremark>Beta Draft</revremark>
            </revision>
        </revhistory>

--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -60,35 +60,15 @@
                <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-n450
+     meta-intel_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
@@ -103,7 +83,7 @@ meta-&lt;bsp_name&gt;/conf/layer.conf
 meta-&lt;bsp_name&gt;/conf/machine/*.conf
 meta-&lt;bsp_name&gt;/recipes-bsp/*
 meta-&lt;bsp_name&gt;/recipes-graphics/*            
-meta-&lt;bsp_name&gt;/recipes-kernel/linux/linux-yocto_git.bbappend
+meta-&lt;bsp_name&gt;/recipes-kernel/linux/linux-yocto-stable.bbappend
                </programlisting>
            </para>

@@ -127,7 +107,7 @@ meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/fix_open_max_prepr
 meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/macro_tweak.patch
 meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/nodolt.patch
 meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb
-meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend
+meta-crownbay/recipes-kernel/linux/linux-wrs_git.bbappend
                </programlisting>
            </para>

@@ -180,10 +160,10 @@ meta-&lt;bsp_name&gt;/binary/&lt;bootable_images&gt;
            </programlisting>

            <para>
-                This optional area contains useful pre-built kernels and user-space filesystem 
+                This optional area contains useful pre-built kernels and userspace filesystem 
                images appropriate to the target system.
-                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. 
+                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. 
                You can use these kernels and images to get a system running and quickly get started 
                on development tasks.
            </para>
@@ -217,8 +197,7 @@ 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}/"
@@ -336,7 +315,7 @@ meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb
            <section id='bsp-filelayout-kernel'>
            <title>Linux Kernel Configuration</title>
            <programlisting>
-meta-&lt;bsp_name&gt;/recipes-kernel/linux/linux-yocto_git.bbappend
+meta-&lt;bsp_name&gt;/recipes-kernel/linux/linux-yocto-stable.bbappend
            </programlisting>

            <para>
@@ -351,27 +330,27 @@ meta-&lt;bsp_name&gt;/recipes-kernel/linux/linux-yocto_git.bbappend
                directory.
            </para>
            <para>
-                Suppose you use a BSP that uses the <filename>linux-yocto_git.bb</filename> kernel, 
+                Suppose you use a BSP that uses the <filename>linux-yocto-stable_git.bb</filename> kernel, 
                which is the preferred kernel to use for developing a new BSP using the Yocto Project.
                In other words, you have selected the kernel in your 
                <filename>&lt;bsp_name&gt;.conf</filename> file by adding the following statement:
                <programlisting>
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-stable"
                </programlisting>
-                You would use the <filename>linux-yocto_git.bbappend</filename> file to append 
+                You would use the <filename>linux-yocto-stable_git.bbappend</filename> file to append 
                specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.
            </para>
            <para>
                Now take a look at the existing "crownbay" BSP.
                The append file used is:
                <programlisting>
-meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend
+meta-crownbay/recipes-kernel/linux/linux-yocto-stable_git.bbappend
                </programlisting>
                The file contains the following:
                <programlisting>
 FILESEXTRAPATHS := "${THISDIR}/${PN}"
 COMPATIBLE_MACHINE_crownbay = "crownbay"
-KMACHINE_crownbay = "yocto/standard/crownbay"
+KMACHINE_crownbay = "crownbay"
                </programlisting>
                This append file adds "crownbay" as a compatible machine,
                and additionally sets a Yocto Kernel-specific variable that identifies the name of the 
@@ -392,7 +371,7 @@ KMACHINE_crownbay = "yocto/standard/crownbay"
                For example, suppose you had a set of configuration options in a file called 
                <filename>defconfig</filename>.  
                If you put that file inside a directory named 
-                <filename class='directory'>/linux-yocto</filename> and then added 
+                <filename class='directory'>/linux-yocto-stable</filename> and then added 
                a SRC_URI statement such as the following to the append file, those configuration
                options will be picked up and applied when the kernel is built.
                <programlisting>
@@ -412,14 +391,13 @@ SRC_URI += "file://defconfig \
                </programlisting>
            </para>
            <para>
-                The FILESEXTRAPATHS variable is in boilerplate form here in order to make it easy 
-                to do that.
+                The FILESEXTRAPATHS variable is boilerplated here in order to make it easy to do that.
                It basically allows those configuration files to be found by the build process.
            </para>
            <note><para>
                Other methods exist to accomplish grouping and defining configuration options.
                For example, you could directly add configuration options to the Yocto kernel 
-                <filename class='directory'>meta</filename> branch for your BSP.
+                <filename class='directory'>wrs_meta</filename> branch for your BSP.
                The configuration options will likely end up in that location anyway if the BSP gets 
                added to the Yocto Project. 
                For information on how to add these configurations directly, see the 
@@ -429,7 +407,7 @@ SRC_URI += "file://defconfig \
            </para>
            <para>
                In general, however, the Yocto Project maintainers take care of moving the SRC_URI-specified 
-                configuration options to the <filename class='directory'>meta</filename> branch.
+                configuration options to the <filename class='directory'>wrs_meta</filename> branch.
                Not only is it easier for BSP developers to not have to worry about putting those 
                configurations in the branch, but having the maintainers do it allows them to apply 
                'global' knowledge about the kinds of common configuration options multiple BSPs in 
@@ -555,22 +533,19 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
            </para>

            <para>
-	      For cases where you can substitute something and still maintain functionality, 
-              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, 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.
+	      For cases where you can substitute something and still maintain functionality, the Poky website 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 requirements.  
+              If present, this fully 'de-featured' BSP will be named meta-&lt;bsp_name&gt; (i.e. the
+	      normal default naming convention).  
+              If available, this is the simplest the most preferred option.
              This, of course, assumes the resulting functionality meets requirements.
            </para>

            <para>
-	      If however, a non-encumbered version is unavailable or the 'free' version 
-              would provide unsuitable functionality or quality, you can use 
-              an encumbered version.  
+	      If however, a non-encumbered version is unavailable or the 'free' version would provide unsuitable
+	      functionality or quality, an encumbered version can be used.  
+              Encumbered versions of a BSP are given names of the form meta-&lt;bsp_name&gt;-nonfree.
            </para>

            <para>  
@@ -584,23 +559,14 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"

 		<para>
 		  Get a license key (or keys) for the encumbered BSP by visiting 
-                  a website and providing the name of the BSP and your email address
-                  through a web form.
-                </para>
- 
-<!--
                  <ulink url='https://pokylinux.org/bsp-keys.html'>https://pokylinux.org/bsp-keys.html</ulink>
 		  and give the name of the BSP and your e-mail address in the web form.
 		</para>

-                COMMENT:  This link is not implemented at this point.  
-
 		<programlisting>
 		  [screenshot of dialog box]
 		</programlisting>

-->
-
 		<para>
 		  After agreeing to any applicable license terms, the
 		  BSP key(s) will be immediately sent to the address
@@ -609,7 +575,7 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
 		</para>

 		<programlisting>
-		  $ BSPKEY_&lt;keydomain&gt;=&lt;key&gt; bitbake core-image-sato
+		  $ BSPKEY_&lt;keydomain&gt;=&lt;key&gt; bitbake poky-image-sato
 		</programlisting>

 		<para>
@@ -643,8 +609,7 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
 		  encumbered BSP.  
                  These prompts usually take the form of instructions
 		  needed to manually fetch the encumbered package(s)
-		  and md5 sums into the required directory 
-                  (e.g. the <filename>poky/build/downloads</filename>).
+		  and md5 sums into the required directory (e.g. the poky/build/downloads)
                  Once the manual package fetch has been
 		  completed, restart the build to continue where
 		  it left off.
@@ -654,21 +619,25 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
              </listitem>
              <listitem>
 		<para>
-		  Get a full-featured BSP recipe rather than a key.
-                  You can do this by visiting the applicable BSP download page from the Yocto 
-                  Project website at
-                  <ulink url='http://yoctoproject.org/download/board-support-package-bsp-downloads'></ulink>.
-		  BSP tarballs that have proprietary information can be downloaded after agreeing 
-                  to licensing requirements as part of the download process. 
-                  Obtaining the code this way allows you to build an encumbered image with 
-                  no changes at all as compared to the normal build. 
-                </para>
+		  Get a full-featured BSP recipe rather than a key, by
+		  visiting
+		  <ulink url='https://pokylinux.org/bsps.html'>https://pokylinux.org/bsps.html</ulink>.
+		  Accepting the license agreement(s) presented will
+		  subsequently allow you to download a tarball
+		  containing a full-featured BSP that is legally cleared for
+		  your use by the just-given license agreement(s).
+		  This method will also allow the encumbered image to
+		  be built with no change at all to the normal build
+		  process.
+		</para>
              </listitem>
 	    </orderedlist>
 	    <para>
 	      Note that the third method is also the only option available
-	      when downloading pre-compiled images generated from non-free BSPs.  
-              Those images are likewise available at from the Yocto Project website.
+	      when downloading pre-compiled images generated from
+	      non-free BSPs.  
+              Those images are likewise available at
+	      <ulink url='https://pokylinux.org/bsps.html'>https://pokylinux.org/bsps.html</ulink>.
            </para> 
        </section>

--- a/documentation/bsp-guide/figures/bsp-title.png
+++ b/documentation/bsp-guide/figures/bsp-title.png
--- a/documentation/bsp-guide/figures/poky-ref-manual.png
+++ b/documentation/bsp-guide/figures/poky-ref-manual.png
--- a/documentation/bsp-guide/style.css
+++ b/documentation/bsp-guide/style.css
@@ -50,13 +50,9 @@ body {
  color: #333;
 }

-.reviewer {
-  color: red;
-}
-
 h1,h2,h3,h4,h5,h6,h7 {
  font-family: Arial, Sans;
-  color: #00557D;
+  color:#999999;
  clear: both;
 }

@@ -80,7 +76,7 @@ h2 {
  margin: 2em 0em 0.66em 0em;
  padding: 0.5em 0em 0em 0em;
  font-size: 1.5em;
-  font-weight: bold;
+  font-weight: normal;
 }

 h3.subtitle {
@@ -94,28 +90,28 @@ h3 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
  font-size: 140%;
-  font-weight: bold;
+  font-weight: normal;
 }

 h4 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
  font-size: 120%;
-  font-weight: bold;
+  font-weight: normal;
 }

 h5 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
+  font-size: 110.000%;
+  border-bottom: 1px solid black;
 }

 h6 {
  margin: 1em 0em 0em 0em;
  padding: 1em 0em 0em 0em;
  font-size: 80%;
-  font-weight: bold;
+  font-weight: normal;
 }

 .authorgroup {
@@ -128,7 +124,7 @@ h6 {
  padding-right: 50px;
  margin-left: 0px;
  text-align: right;
-  width: 740px;
+  width: 700px;
 }

 h3.author {
@@ -136,7 +132,6 @@ h3.author {
  padding: 0em 0em 0em 0em;
  font-weight: normal;
  font-size: 100%;
-  color: #333;
  clear: both;
 }

@@ -159,7 +154,6 @@ h3.author {
 .list-of-examples,
 .list-of-figures {
  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
 }

 .toc p,
@@ -936,7 +930,7 @@ table {

 .tip,
 .note {
-   background: #666666;
+   background: #91ae35;
   color: #fff;   
   padding: 20px;
   margin: 20px;
--- a/documentation/kernel-manual/Makefile
+++ b/documentation/kernel-manual/Makefile
@@ -16,23 +16,27 @@ 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 kernel-manual.pdf style.css figures/kernel-title.png figures/kernel-architecture-overview.png
+	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

-MANUALS = kernel-manual.html kernel-manual.pdf
-FIGURES = figures/*.png
-STYLESHEET = *.css
+OUTPUTS = kernel-manual.tgz kernel-manual.html kernel-manual.pdf
+SOURCES = *.png *.xml *.css

 publish:
-	scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/kernel-manual
-	scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/kernel-manual/figures
+	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/

 clean:
 	rm -f $(OUTPUTS)
--- a/documentation/kernel-manual/figures/kernel-big-picture.png
+++ b/documentation/kernel-manual/figures/kernel-big-picture.png
--- a/documentation/kernel-manual/figures/kernel-title.png
+++ b/documentation/kernel-manual/figures/kernel-title.png
--- a/documentation/kernel-manual/figures/yocto-project-transp.png
+++ b/documentation/kernel-manual/figures/yocto-project-transp.png
--- a/documentation/kernel-manual/kernel-how-to.xml
+++ b/documentation/kernel-manual/kernel-how-to.xml
@@ -425,18 +425,18 @@ repository.

                <literallayout class='monospaced'>
     # full description of the changes
-     &gt; git whatchanged &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
-        &gt; eg: git whatchanged yocto/standard/base..yocto/standard/common-pc/base
+     &gt; git whatchanged &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;
+        &gt; eg: git whatchanged standard..common_pc-standard

     # summary of the changes
-     &gt; git log --pretty=oneline --abbrev-commit &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+     &gt; git log --pretty=oneline --abbrev-commit &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;

     # source code changes (one combined diff)
-     &gt; git diff &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
-     &gt; git show &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+     &gt; git diff &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;
+     &gt; git show &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;

     # dump individual patches per commit
-     &gt; git format-patch -o &lt;dir&gt; &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+     &gt; git format-patch -o &lt;dir&gt; &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;

     # determine the change history of a particular file
     &gt; git whatchanged &lt;path to file&gt;
@@ -467,15 +467,15 @@ repository.
     # determine which branches contain a feature
     &gt; git branch --contains &lt;tag&gt;

-     # show the changes in a kernel type
-     &gt; git whatchanged yocto/base..&lt;kernel type&gt;
-        &gt; eg: git whatchanged yocto/base..yocto/standard/base
+     # show the changes in a kernel type - (0.9 examples)
+     &gt; git whatchanged wrs_base..&lt;kernel type&gt;
+        &gt; eg: git whatchanged wrs_base..standard
                </literallayout>

                <para>
                    You can use many other comparisons to isolate BSP changes.
                    For example, you can compare against kernel.org tags (e.g. v2.6.27.18, etc), or
-                    you can compare against subsystems (e.g. git whatchanged mm).
+                    you can compare agains subsystems (e.g. git whatchanged mm).
                </para>
            </section>
        </section>
@@ -600,7 +600,7 @@ repository.
                <para>
                    Distributed development with git is possible when you use a universally 
                    agreed-upon unique commit identifier (set by the creator of the commit) that maps to a
-                    specific change set with a specific parent.  
+                    specific changeset with a specific parent.  
                    This identifier is created for you when
                    you create a commit, and is re-created when you amend, alter or re-apply
                    a commit.  
@@ -733,10 +733,10 @@ repository.

                    <para>
                        For example, the following command pushes the changes from your local branch
-                        <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name 
-                        in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.37</filename>.
+                        <filename>common_pc-standard</filename> to the remote branch with the same name 
+                        in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.27</filename>.
                    <literallayout class='monospaced'>
-     &gt; push ssh://git.mycompany.com/pub/git/kernel-2.6.37 yocto/standard/common-pc/base:yocto/standard/common-pc/base
+     &gt; push ssh://git.mycompany.com/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard
                    </literallayout>
                    </para>

@@ -866,9 +866,9 @@ repository.

                <para>
                    The following commands illustrate some of the steps you could use to
-                    import the yocto/standard/common-pc/base kernel into a secondary SCM:
+                    import the common_pc-standard kernel into a secondary SCM:
                <literallayout class='monospaced'>
-     &gt; git checkout yocto/standard/common-pc/base
+     &gt; git checkout common_pc-standard
     &gt; cd .. ; echo linux/.git &gt; .cvsignore
     &gt; cvs import -m "initial import" linux MY_COMPANY start
                </literallayout>
@@ -881,8 +881,8 @@ repository.
                <para>
                    The following commands illustrate how you can condense and merge two BSPs into a second SCM:
                <literallayout class='monospaced'>
-     &gt; git checkout yocto/standard/common-pc/base
-     &gt; git merge yocto/standard/common-pc-64/base
+     &gt; git checkout common_pc-standard
+     &gt; git merge common_pc_64-standard
     # resolve any conflicts and commit them
     &gt; cd .. ; echo linux/.git &gt; .cvsignore
     &gt; cvs import -m "initial import" linux MY_COMPANY start
@@ -1006,12 +1006,9 @@ That's it. Configure and build.
            <title>Creating a BSP Based on an Existing Similar BSP</title>

            <para>
-                This section provides an example for creating a BSP
-                that is based on an existing, and hopefully, similar
-                one.  It assumes you will be using a local kernel
-                repository and will be pointing the kernel recipe at
-                that.  Follow these steps and keep in mind your
-                particular situation and differences:
+                This section provides an example for creating a BSP that is based on an existing, and hopefully, 
+                similar one.  
+                Follow these steps and keep in mind your particular situation and differences:

            <orderedlist>
                <listitem><para>
@@ -1019,14 +1016,16 @@ That's it. Configure and build.
                </para>
                
                <para>
-                    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.yoctoproject.org/cgit/cgit.cgi/meta-intel/'></ulink>, such as 
-                    <filename>meta-intel/meta-emenlow/conf/machine/emenlow.conf</filename>.
+                    You can start with something in <filename>meta/conf/machine</filename>.  
+                    Or, <filename>meta-emenlow/conf/machine</filename> has an example in its own layer.
                </para>
                
                <para>
+                    The most up-to-date machines that are probably most similar to yours and that you might want 
+                    to look at are <filename>meta/conf/machine/atom-pc.conf</filename> and 
+                    <filename>meta-emenlow/conf/machine/emenlow.conf</filename>.  
+                    Both of these files were either just added or upgraded to use the Yocto Project kernel 
+                    at <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/'></ulink>.
                    The main difference between the two is that "emenlow" is in its own layer.
                    It is in its own layer because it needs extra machine-specific packages such as its 
                    own video driver and other supporting packages.  
@@ -1050,21 +1049,19 @@ That's it. Configure and build.
                <para>
                    As an example consider this:
                    <itemizedlist>
-                        <listitem><para>Copy meta-emenlow to meta-mymachine</para></listitem>
+                        <listitem><para>Copy meta-emenlow</para></listitem>
                        <listitem><para>Fix or remove anything you do not need.  
                        For this example the only thing left was the kernel directory with a 
-                        <filename>linux-yocto_git.bbappend</filename>
-                        file
-                        and <filename>meta-mymachine/conf/machine/mymachine.conf</filename>
-                        (linux-yocto is the kernel listed in
-                        <filename>meta-emenlow/conf/machine/emenlow.conf</filename>)</para></listitem>.
+                        <filename>linux-yocto-stable_git.bbappend</filename> file 
+                        (linux-yocto-stable is the kernel listed in 
+                        <filename>meta-crownbay/conf/machine/crownbay.conf</filename></para></listitem>.
                        <listitem><para>Add a new entry in the <filename>build/conf/bblayers.conf</filename> 
-                        so the new layer can be found by BitBake.</para></listitem>
+                        so the new layer can be found by Bitbake.</para></listitem>
                    </itemizedlist>
                </para></listitem>
                
                <listitem><para>
-                    Create a machine branch for your machine.
+                    Get an image with a working kernel built.
                </para>

                <para>
@@ -1073,52 +1070,58 @@ 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.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
+     $ git clone --bare git://git.pokylinux.org/linux-2.6-windriver.git
+     linux-2.6-windriver.git
+     $ git clone linux-2.6-windriver.git linux-2.6-windriver
                    </literallayout>
                </para>
                
                <para>
                    Now create a branch in the local clone and push it to the bare clone:
                    <literallayout class='monospaced'>
-     $ git checkout -b yocto/standard/mymachine origin/yocto/standard/base
-     $ git push origin yocto/standard/mymachine:yocto/standard/mymachine
+     $ git checkout -b crownbay-standard origin/standard 
+     $ git push origin crownbay-standard:crownbay-standard
                    </literallayout>
-                </para></listitem>
+                </para>
               
+                <para>
+                    At this point, your git tree should compile.
+                </para></listitem>
+                
                <listitem><para>
-                    In a layer, create a <filename>linux-yocto_git.bbappend</filename> 
+                    In a layer, create a <filename>linux-yocto-stable_git.bbappend</filename> 
                    file with the following:
                </para>       
                
                <para>
                    <literallayout class='monospaced'>
-     FILESEXTRAPATHS := "${THISDIR}/${PN}"
-     COMPATIBLE_MACHINE_mymachine = "mymachine"
+     COMPATIBLE_MACHINE = ${MACHINE}

     # It is often nice to have a local clone of the kernel repository, to
     # allow patches to be staged, branches created, and so forth.  Modify
     # KSRC to point to your local clone as appropriate.

-     KSRC ?= /path/to/your/bare/clone/for/example/linux-yocto-2.6.37.git
+     # KSRC ?= /path/to/your/bare/clone/yocto-kernel

-     # KMACHINE is the branch to be built, or alternatively 
+     # KMACHINE is the branch to be built, or alternateively 
     # KBRANCH can be directly set.
-     # KBRANCH is set to KMACHINE in the main linux-yocto_git.bb
-     # KBRANCH ?= "${LINUX_KERNEL_TYPE}/${KMACHINE}"

-     KMACHINE_mymachine  = "yocto/standard/mymachine"
+     # KBRANCH ?= "${KMACHINE}-${LINUX_KERNEL_TYPE}"

-     SRC_URI = "git://${KSRC};nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
+     # SRC_URI = "git://${KSRC};nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
                    </literallayout>
                </para>

+                <para>
+                    In the previous sample file you need to update and remove the comment from 
+                    the KSRC assignment and also remove the comment from the SRC_URI line.
+                </para>
+                
                <para>
                    After doing that, select the machine in <filename>build/conf/local.conf</filename>:
                    <literallayout class='monospaced'>
      #
-      MACHINE ?= "mymachine"
+      MACHINE ?= "crownbay"
      #
                    </literallayout>
                </para>
@@ -1126,12 +1129,8 @@ That's it. Configure and build.
                <para>
                    You should now be able to build and boot an image with the new kernel:
                    <literallayout class='monospaced'>
-     $ bitbake core-image-sato-live
+     $ bitbake poky-image-sato-live
                    </literallayout>
-                </para></listitem>
-
-                <listitem><para>
-                    Modify the kernel configuration for your machine.
                </para>
                
                <para>
@@ -1150,22 +1149,17 @@ That's it. Configure and build.
                    And, another <filename>.cfg</filename> file would contain:
                    <literallayout class='monospaced'>
     CONFIG_LOG_BUF_SHIFT=18
-                    </literallayout>

-                <para>
-                    These config fragments could then be picked up and
-                    applied to the kernel .config by appending them to the kernel SRC_URI:
-                </para>
+     http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/

-                    <literallayout class='monospaced'>
-     SRC_URI_append_mymachine = " file://some.cfg \
+     SRC_URI_append_crownbay = " file://some.cfg \
                                  file://other.cfg \
                               "
                    </literallayout>
                </para>
                
                <para>
-                    You could also add these directly to the git repository <filename>meta</filename>
+                    You could also add these directly to the git repository <filename>wrs_meta</filename>
                    branch as well.
                    However, the former method is a simple starting point.
                </para></listitem>
@@ -1179,7 +1173,7 @@ That's it. Configure and build.
                <para>
                    Practically speaking, to generate the patches, you'd go to the source in the build tree:
                    <literallayout class='monospaced'>
-     build/tmp/work/mymachine-poky-linux/linux-yocto-2.6.37+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+
+     build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+
 0431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux
                    </literallayout>
                </para>
@@ -1188,7 +1182,7 @@ That's it. Configure and build.
                    Then, modify the code there, using quilt to save the changes, and recompile until 
                    it works:
                    <literallayout class='monospaced'>
-     $ bitbake -c compile -f linux-yocto
+     $ bitbake -c compile -f linux-yocto-stable
                    </literallayout>
                </para></listitem>
                
@@ -1197,7 +1191,7 @@ That's it. Configure and build.
                    SRC_URI location.
                    The patch is applied the next time you do a clean build.
                    Of course, since you have a branch for the BSP in git, it would be better to put it there instead.
-                    For example, in this case, commit the patch to the "yocto/standard/mymachine" branch, and during the 
+                    For example, in this case, commit the patch to the "crownbay-standard" branch, and during the 
                    next build it is applied from there.
                </para></listitem>
            </orderedlist>
--- a/documentation/kernel-manual/kernel-manual.xml
+++ b/documentation/kernel-manual/kernel-manual.xml
@@ -31,13 +31,7 @@
            <revision>
                <revnumber>0.9</revnumber>
                <date>24 November 2010</date>
-                <revremark>This revision is the initial document draft and corresponds with 
-                    the Yocto Project 0.9 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.0</revnumber>
-                <date>6 April 2011</date>
-                <revremark>This revision corresponds with the Yocto Project 1.0 Release.</revremark>
+                <revremark>Beta Draft</revremark>
            </revision>
        </revhistory>

--- a/documentation/kernel-manual/style.css
+++ b/documentation/kernel-manual/style.css
@@ -56,7 +56,7 @@ body {

 h1,h2,h3,h4,h5,h6,h7 {
  font-family: Arial, Sans;
-  color: #00557D;
+  color:#999999;
  clear: both;
 }

@@ -79,8 +79,9 @@ h2.subtitle {
 h2 {
  margin: 2em 0em 0.66em 0em;
  padding: 0.5em 0em 0em 0em;
-  font-size: 1.5em;
+  font-size: 2em;
  font-weight: bold;
+  color: black;
 }

 h3.subtitle {
@@ -93,29 +94,29 @@ h3.subtitle {
 h3 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
-  font-size: 140%;
+  font-size: 150%;
  font-weight: bold;
+  color: black;
+  border-bottom: 2px solid black;
 }

 h4 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
-  font-size: 120%;
-  font-weight: bold;
+  font-size: 130%;
+  border-bottom: 1px solid black;
 }

 h5 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
+  font-size: 120%;
 }

 h6 {
  margin: 1em 0em 0em 0em;
  padding: 1em 0em 0em 0em;
-  font-size: 80%;
-  font-weight: bold;
+  font-size: 100%;
 }

 .authorgroup {
@@ -123,12 +124,12 @@ h6 {
  background-repeat: no-repeat;
  padding-top: 256px;
  background-image: url("figures/kernel-title.png");
-  background-position: left top;
+  background-position: top;
  margin-top: -256px;
  padding-right: 50px;
-  margin-left: 0px;
+  margin-left: 50px;
  text-align: right;
-  width: 740px;
+  width: 700px;
 }

 h3.author {
@@ -136,7 +137,6 @@ h3.author {
  padding: 0em 0em 0em 0em;
  font-weight: normal;
  font-size: 100%;
-  color: #333;
  clear: both;
 }

@@ -159,7 +159,6 @@ h3.author {
 .list-of-examples,
 .list-of-figures {
  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
 }

 .toc p,
@@ -247,6 +246,7 @@ div.legalnotice p.legalnotice-title {
 p {
  line-height: 1.5em;
  margin-top: 0em;
+  color: black; font-size: 100%;
  
 }

@@ -946,7 +946,7 @@ table {

 .tip,
 .note {
-   background: #666666;
+   background: #91ae35;
   color: #fff;   
   padding: 20px;
   margin: 20px;
--- a/documentation/kernel-manual/yocto-project-kernel-manual-customization.xsl
+++ b/documentation/kernel-manual/yocto-project-kernel-manual-customization.xsl
@@ -3,6 +3,6 @@
  
  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />

-<!--  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>  -->
+  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>

 </xsl:stylesheet>
--- a/documentation/poky-ref-manual/Makefile
+++ b/documentation/poky-ref-manual/Makefile
@@ -3,7 +3,7 @@ XSLTOPTS = --stringparam html.stylesheet style.css \
           --stringparam  appendix.autolabel A \
           --stringparam  section.autolabel 1 \
           --stringparam  section.label.includes.component.label 1 \
-         --xinclude
+	   --xinclude

 ##
 # These URI should be rewritten by your distribution's xml catalog to
@@ -21,18 +21,16 @@ 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/poky-title.png figures/ss-sato.png
+	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

-MANUALS = poky-ref-manual.html poky-ref-manual.pdf
-FIGURES = figures/*.png
-STYLESHEET = *.css
+OUTPUTS = poky-ref-manual.tgz poky-ref-manual.html poky-ref-manual.pdf 
+SOURCES = *.png *.xml *.css *.svg

 publish:
-	scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/poky-ref-manual
-	scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/poky-ref-manual/figures
+	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/

 clean:
 	rm -f $(OUTPUTS)
--- a/documentation/poky-ref-manual/development.xml
+++ b/documentation/poky-ref-manual/development.xml
@@ -12,7 +12,7 @@
    </para>

        <section id="platdev-appdev-external-sdk">
-        <title>External Development Using the Application Development Toolkit (ADT)</title>
+        <title>External Development Using the Poky SDK</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,41 +45,17 @@
        </section>

        <section id="using-the-eclipse-and-anjuta-plug-ins">
-        <title>Using the Eclipse Plug-in</title>
+        <title>Using the Eclipse and Anjuta Plug-ins</title>
        <para>
-            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 
+            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 
            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>
@@ -91,13 +67,12 @@
                <literallayout class='monospaced'>
     Help -> Install New Software
                </literallayout>
-                Specify the target URL as 
-                <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink>.
+                Specify the target URL as <ulink url='http://www.yoctoproject.org/downloads/eclipse-plug-in/'></ulink>.
            </para>
            <para>
                If you want to download the source code for the plug-in you can find it in the Poky 
                git repository, which has a web interface, and is located at
-                <ulink url="http://git.yoctoproject.org"></ulink> under IDE Plugins.
+                <ulink url="http://git.pokylinux.org/cgit.cgi/eclipse-poky"></ulink>.
            </para>
  
                <section id="installing-and-setting-up-the-eclipse-ide">
@@ -326,14 +301,15 @@
                Plug-in are all required. 
                The Poky Anjuta Plug-in is available to download as a tarball at the OpenedHand 
                labs <ulink url="http://labs.o-hand.com/anjuta-poky-sdk-plugin/"></ulink> page or 
-                directly from the Poky Git repository located at git://git.yoctoproject.org/anjuta-poky.
-                You can access the source code from a web interface to the repository at
-                <ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins.
+                directly from the Poky Git repository located at 
+                <ulink url="git://git.pokylinux.org/anjuta-poky"></ulink>.
+                You can also access a web interface to the repository at
+                <ulink url="http://git.pokylinux.org/?p=anjuta-poky.git;a=summary"></ulink>.
             </para>
             <para>
                See the README file contained in the project for more information on 
                Anjuta dependencies and building the plug-in. 
-                If you want to disable remote gdb debugging, pass the "&dash;&dash;disable-gdb-integration" switch when 
+                If you want to disable remote gdb debugging, pass the "--disable-gdb-integration" switch when 
                you configure the plug-in.
            </para>
                <section id="setting-up-the-anjuta-plugin">
@@ -383,8 +359,8 @@
                        triplet is "i586-poky-linux".</para></listitem>
                        <listitem><para>Kernel: Use the file chooser to select the kernel used with QEMU.</para></listitem>
                        <listitem><para>Root filesystem: Use the file chooser to select the root 
-                        filesystem directory.  This directory is where you use "runqemu-extract-sdk" to extract the 
-                        core-image-sdk tarball.</para></listitem>
+                        filesystem directory.  This directory is where you use "poky-extract-sdk" to extract the 
+                        poky-image-sdk tarball.</para></listitem>
                     </itemizedlist>
                </para>
                </section>
@@ -440,10 +416,6 @@
                </para>
                </section>
            </section>
-
-
-->
-
        </section>

        <section id="platdev-appdev-qemu">
@@ -719,7 +691,7 @@
                </literallayout>
                Once the binary is built you can find it here: 
                <programlisting>
-tmp/sysroots/&lt;host-arch&gt;/usr/bin/&lt;target-abi&gt;-gdb 
+tmp/sysroots/&lt;host-arch&lt;/usr/bin/&lt;target-abi&gt;-gdb 
                </programlisting>
            </para>

@@ -738,7 +710,7 @@ tmp/sysroots/&lt;host-arch&gt;/usr/bin/&lt;target-abi&gt;-gdb
            <para>
                Perhaps the easiest is to have an 'sdk' image that corresponds to the plain
                image installed on the device. 
-                In the case of 'core-image-sato', 'core-image-sdk' would contain suitable symbols. 
+                In the case of 'poky-image-sato', 'poky-image-sdk' would contain suitable symbols. 
                Because the sdk images already have the debugging symbols installed it is just a 
                question of expanding the archive to some location and then informing GDB. 
            </para>
@@ -764,17 +736,17 @@ tmp/sysroots/&lt;host-arch&gt;/usr/bin/&lt;target-abi&gt;-gdb
                <filename>tmp/rootfs</filename>:
                <programlisting>
 tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
-tmp/work/&lt;target-abi&gt;/core-image-sato-1.0-r0/temp/opkg.conf -o \
+tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/temp/opkg.conf -o \
 tmp/rootfs/ update
                </programlisting></para></listitem>
                <listitem><para>Install the debugging information:
                <programlisting>
 tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
-tmp/work/&lt;target-abi&gt;/core-image-sato-1.0-r0/temp/opkg.conf \
+tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/temp/opkg.conf \
 -o tmp/rootfs install foo

 tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
-tmp/work/&lt;target-abi&gt;/core-image-sato-1.0-r0/temp/opkg.conf \
+tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/temp/opkg.conf \
 -o tmp/rootfs install foo-dbg
                </programlisting></para></listitem>
            </orderedlist>
@@ -937,8 +909,8 @@ $ opreport -cl

        <para>
            A graphical user interface for OProfile is also available. 
-            You can download and build it from the Yocto Project at
-            <ulink url="http://git.yoctoproject.org/cgit.cgi/oprofileui/"></ulink>. 
+            You can download and build it from svn at
+            <ulink url="http://svn.o-hand.com/repos/oprofileui/trunk/"></ulink>. 
            If the "tools-profile" image feature is selected, all necessary binaries
            are installed onto the target device for OProfileUI interaction.
        </para>
@@ -954,7 +926,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. 
@@ -963,12 +935,13 @@ $ 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://git.yoctoproject.org/cgit.cgi/oprofileui/tree/README'>
+            If so, see the <ulink url='http://svn.o-hand.com/repos/oprofileui/trunk/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">
@@ -1065,7 +1038,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. 
+                version of the kernel (e.g. 2.6.23). 
                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>. 
--- a/documentation/poky-ref-manual/extendpoky.xml
+++ b/documentation/poky-ref-manual/extendpoky.xml
@@ -46,7 +46,7 @@
                "do_install" tasks.
                The <glossterm><link linkend='var-S'>S</link></glossterm> variable defines the 
                directory containing the source code, which is set to <glossterm><link linkend='var-WORKDIR'>
-                WORKDIR</link></glossterm> in this case - the directory BitBake uses for the build.
+                WORKDIR</link></glossterm> in this case - the directory Bitbake uses for the build.
            </para>
            <programlisting>
 DESCRIPTION = "Simple helloworld application"
@@ -68,7 +68,7 @@ do_install() {
 }
            </programlisting>
            <para>
-                By default, the "helloworld", "helloworld-dbg" and "helloworld-dev"
+                By default, the "helloworld", "helloworld-dbg" and "hellworld-dev"
                packages are built. 
                For information on how to customize the packaging process, see
                <link linkend='usingpoky-extend-addpkg-files'>Controlling Package Content</link>.
@@ -81,13 +81,13 @@ do_install() {
                Applications that use autotools such as <filename>autoconf</filename> and 
                <filename>automake</filename> require a recipe that has a source archive listed in 
                <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> and 
-                also inherits autotools, which instructs BitBake to use the
+                <filename>also inherits autotools</filename>, which instructs Bitbake to use the
                <filename>autotools.bbclass</filename> file, which contains the definitions of all the steps
                needed to build an autotooled application.
                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.3.bb</filename>)
+                Following is one example: (<filename>hello_2.2.bb</filename>)
            </para>
            <programlisting>
 DESCRIPTION = "GNU Helloworld application"
@@ -114,13 +114,13 @@ inherit autotools gettext
            <para>
                Applications that use GNU <filename>make</filename> also require a recipe that has
                the source archive listed in <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>. 
-                You do not need to add a "do_compile" step since by default BitBake 
+                You do not need to add a <function>do_compile</function> step since by default Bitbake 
                starts the <filename>make</filename> command to compile the application. 
                If you need additional <filename>make</filename> options you should store them in the 
                <glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></glossterm> variable.
-                BitBake passes these options into the <filename>make</filename> GNU invocation. 
+                Bitbake passes these options into the <filename>make</filename> GNU invocation. 
                Note that a "do_install" task is still required.
-                Otherwise BitBake runs an empty "do_install" task by default. 
+                Otherwise Bitbake runs an empty "do_install" task by default. 
            </para>
            <para>
                Some applications might require extra parameters to be passed to the compiler.
@@ -209,8 +209,8 @@ FILES_sxpm = "${bindir}/sxpm"
            <title>Post Install Scripts</title>

            <para>
-                To add a post-installation script to a package, add a <filename>pkg_postinst_PACKAGENAME()
-                </filename> function to the <filename>.bb</filename> file and use 
+                To add a post-installation script to a package, add a <function>pkg_postinst_PACKAGENAME()
+                </function> function to the <filename>.bb</filename> file and use 
                <filename>PACKAGENAME</filename> as the name of the package you want to attach to the 
                <filename>postinst</filename> script.
                Normally <glossterm><link linkend='var-PN'>PN</link></glossterm> can be used, which 
@@ -269,9 +269,9 @@ fi
                The following example shows the form for the two lines you need:
            </para>
            <programlisting>
-IMAGE_INSTALL = "task-core-x11-base package1 package2"
+IMAGE_INSTALL = "task-poky-x11-base package1 package2"

-inherit core-image
+inherit poky-image
            </programlisting>
            <para>
                By creating a custom image, a developer has total control
@@ -283,11 +283,11 @@ inherit core-image
            </para>
            <para>
                The other method for creating a custom image is to modify an existing image. 
-                For example, if a developer wants to add "strace" into "core-image-sato", they can use 
+                For example, if a developer wants to add "strace" into "poky-image-sato", they can use 
                the following recipe:
            </para>
            <programlisting>
-require core-image-sato.bb
+require poky-image-sato.bb

 IMAGE_INSTALL += "strace"
            </programlisting>
@@ -298,8 +298,8 @@ IMAGE_INSTALL += "strace"
            <para>
                For complex custom images, the best approach is to create a custom task package
                that is used to build the image or images. 
-                A good example of a tasks package is 
-                <filename>meta/recipes-sato/tasks/task-poky.bb</filename>. 
+                A good example of a tasks package is <filename>meta/recipes-sato/tasks/task-poky.bb
+                </filename>. 
                The <glossterm><link linkend='var-PACKAGES'>PACKAGES</link></glossterm> 
                variable lists the task packages to build along with the complementary
                -dbg and -dev packages. 
@@ -355,7 +355,7 @@ RRECOMMENDS_task-custom-tools = "\
                <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>
                variable. 
                To create these features, the best reference is 
-                <filename>meta/classes/core-image.bbclass</filename>, which shows how poky achieves this. 
+                <filename>meta/classes/poky-image.bbclass</filename>, which shows how poky achieves this. 
                In summary, the file looks at the contents of the 
                <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>
                variable and then maps that into a set of tasks or packages. 
@@ -364,16 +364,6 @@ RRECOMMENDS_task-custom-tools = "\
                Users can add extra features by extending the class or creating a custom class for use 
                with specialized image <filename>.bb</filename> files.
            </para>
-            <para>
-                Poky ships with two SSH servers you can use in your images: Dropbear and OpenSSH. 
-                Dropbear is a minimal SSH server appropriate for resource-constrained environments,
-                while OpenSSH is a well-known standard SSH server implementation.
-                By default, core-image-sato is configured to use Dropbear.
-                The core-image-basic and core-image-lsb images both include OpenSSH.
-                To change these defaults, edit the <filename>IMAGE_FEATURES</filename> variable
-                so that it sets the image you are working with to include ssh-server-dropbear 
-                or ssh-server-openssh.
-            </para>
        </section>

        <section id='usingpoky-extend-customimage-localconf'>
@@ -412,7 +402,7 @@ DISTRO_EXTRA_RDEPENDS += "strace"
            </para>
            <programlisting>
 $ bitbake -c clean task-boot task-base task-poky
-$ bitbake core-image-sato
+$ bitbake poky-image-sato
            </programlisting>
        </section>

@@ -494,7 +484,7 @@ COMPATIBLE_MACHINE = '(qemux86|qemumips)'
            <title>Adding a Formfactor Configuration File</title>
            <para>
                A formfactor configuration file provides information about the 
-                target hardware on which Poky is running and information that Poky cannot 
+                target hardware on which Poky is running, and information that Poky cannot 
                obtain from other sources such as the kernel.  
                Some examples of information contained in a formfactor configuration file include 
                framebuffer orientation, whether or not the system has a keyboard, 
@@ -505,10 +495,10 @@ COMPATIBLE_MACHINE = '(qemux86|qemumips)'
                Reasonable defaults are used in most cases, but if customization is 
                necessary you need to create a <filename>machconfig</filename> file 
                under <filename>meta/packages/formfactor/files/MACHINENAME/</filename>,
-                where <filename>MACHINENAME</filename> is the name for which this information
+                where <literal>MACHINENAME</literal> is the name for which this information
                applies. 
                For information about the settings available and the defaults, see 
-                <filename>meta/recipes-bsp/formfactor/files/config</filename>. 
+                <filename>meta/packages/formfactor/files/config</filename>. 
                Following is an example for qemuarm:
            </para>
            <programlisting>
@@ -529,7 +519,7 @@ DISPLAY_SUBPIXEL_ORDER=vrgb
    <section id="usingpoky-changes">
        <title>Making and Maintaining Changes</title>
        <para>
-            Because Poky is extremely configurable and flexible, we recognize that people will want 
+            Because Poky offers extreme configurability and flexibility, we recognize that people will want 
            to extend, configure or optimize Poky for their specific uses.
            To best keep pace with future Poky changes we recommend you make controlled changes to Poky.
        </para>
@@ -541,12 +531,12 @@ DISPLAY_SUBPIXEL_ORDER=vrgb
        </para>

        <section id="usingpoky-changes-layers">
-          <title>BitBake Layers</title>
+          <title>Bitbake Layers</title>
          <para>
                Often, people want to extend Poky either by adding packages
                or by overriding files contained within Poky to add their own
                functionality. 
-                BitBake has a powerful mechanism called
+                Bitbake has a powerful mechanism called
                "layers", which provides a way to handle this extension in a fully
                supported and non-invasive fashion.
           </para>
@@ -575,7 +565,7 @@ BBLAYERS = " \
           </para>

          <para>
-               BitBake parses each <filename>conf/layer.conf</filename> file for each layer in BBLAYERS
+               Bitbake parses each <filename>conf/layer.conf</filename> file for each layer in BBLAYERS
               and adds the recipes, classes and configuration contained within the layer to Poky.
               To create your own layer, independent of the main Poky repository,
               simply create a directory with a <filename>conf/layer.conf</filename> file and
@@ -613,14 +603,14 @@ BBFILE_PRIORITY_emenlow = "6"
                Note the use of the <glossterm><link linkend='var-LAYERDIR'>LAYERDIR</link></glossterm> 
                variable with the immediate expansion operator.
                The LAYERDIR variable expands to the directory of the current layer and
-                requires the immediate expansion operator so that BitBake does not wait to expand the variable 
+                requires the immediate expansion operator so that Bitbake does not wait to expand the variable 
                when it's parsing a different directory.
            </para>
            <para>
-                BitBake can locate where other bbclass and configuration files are applied through 
+                Bitbake can locate where other bbclass and configuration files are applied through 
                the <glossterm><link linkend='var-BBPATH'>BBPATH</link></glossterm>
                environment variable. 
-                For these cases, BitBake uses the first file with the matching name found in BBPATH.
+                For these cases, Bitbake uses the first file with the matching name found in BBPATH.
                This is similar to the way the PATH variable is used for binaries. 
                We recommend, therefore, that you use unique bbclass and configuration file names in your
                custom layer.
@@ -634,7 +624,7 @@ BBFILE_PRIORITY_emenlow = "6"
                    tree.</para></listitem>
                </itemizedlist>
                Following these recommendations keeps your Poky tree and its configuration entirely
-                inside COREBASE.
+                inside POKYBASE.
            </para>
        </section>

@@ -674,7 +664,7 @@ BBFILE_PRIORITY_emenlow = "6"
    variables allowing moves to be made towards generating checksums and allowing
    use of the dependency information in other parts of bitbake.
    
-    Signed-off-by: Richard Purdie richard.purdie@linuxfoundation.org
+    Signed-off-by: Richard Purdie rpurdie@linux.intel.com
            </literallayout>

            <para>
@@ -714,7 +704,7 @@ BBFILE_PRIORITY_emenlow = "6"
                Usually, version increases occur only to packages.
                However, if for some reason PV changes but does not increase, you can increase the 
                <glossterm><link linkend='var-PE'>PE</link></glossterm> variable (Package Epoch).
-                The PE variable defaults to "0".
+                The PE variable defaults to '0'.
            </para>
            <para>
                Version numbering strives to follow the 
@@ -747,14 +737,14 @@ BBFILE_PRIORITY_emenlow = "6"
            <para>
                The core component of any development effort with Poky is often an 
                automated build testing framework and an image generation process. 
-                You can use these core components to check that the metadata can be built, 
+                You can use these core components to check that the metadata is buildable, 
                highlight when commits break the build, and provide up-to-date images that 
                allow people to test the end result and use it as a base platform for further 
                development. 
                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.yoctoproject.org:8010'>poky autobuilder</ulink>
+                See <ulink url='http://autobuilder.pokylinux.org:8010'>poky autobuilder</ulink>
                for an example implementation that uses buildbot.
            </para>
            <para>
@@ -823,8 +813,7 @@ BBFILE_PRIORITY_emenlow = "6"
            For a standard recipe not related to 
            <glossterm><link linkend='var-MACHINE'>MACHINE</link></glossterm> the location is
            <filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
-            For target device-dependent packages you should use the <filename>MACHINE</filename>
-            variable instead of 
+            For target device-dependent packages you should use the MACHINE variable instead of 
            <glossterm><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></glossterm> 
            in the directory name.
        </para>
@@ -865,19 +854,19 @@ BBFILE_PRIORITY_emenlow = "6"
                into the new patch file:

                <literallayout class='monospaced'>
-     quilt new NAME-OF-PATCH.patch
+quilt new NAME-OF-PATCH.patch
                </literallayout>

                After notifying quilt, add all modified files into that patch:
                <literallayout class='monospaced'>
-     quilt add file1 file2 file3
+quilt add file1 file2 file3
                </literallayout>

                You can now start editing. 
                Once you are done editing, you need to use quilt to generate the final patch that 
                will contain all your modifications.
                <literallayout class='monospaced'>
-     quilt refresh
+quilt refresh
                </literallayout>

                You can find the resulting patch file in the
@@ -970,7 +959,7 @@ LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
                This practice allow you to just track the "COPYING" file as long as it is kept up to date. 
            </para>
            <tip>
-                If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match 
+                If you specify an empty or invalid "md5" parameter, Bitbake returns an md5 mis-match 
                error and displays the correct "md5" parameter value during the build. The correct parameter
                is also captured in the build log. 
            </tip>
--- a/documentation/poky-ref-manual/faq.xml
+++ b/documentation/poky-ref-manual/faq.xml
@@ -108,7 +108,7 @@
                </listitem>
                <listitem>
                    <para>
-                    Send us BitBake recipes if you have them (see the Poky handbook to find out how to create recipes)
+                    Send us bitbake recipes if you have them (see the Poky handbook to find out how to create recipes)
                    </para>
                </listitem>
            </itemizedlist>
@@ -148,7 +148,7 @@
        </question>
        <answer>
            <para>
-                To add a package you need to create a BitBake recipe - see the Poky handbook to find out how to create a recipe.
+                To add a package you need to create a bitbake recipe - see the Poky handbook to find out how to create a recipe.
            </para>
        </answer>
    </qandaentry>
@@ -248,8 +248,7 @@
    <qandaentry>
        <question>
            <para>
-                I see lots of 404 responses for files on 
-                http://autobuilder.yoctoproject.org/sources/*. Is something wrong?
+                I see lots of 404 responses for files on http://pokylinux.org/sources/*. Is something wrong?
            </para>
        </question>
        <answer>
@@ -332,204 +331,22 @@
        </question>
        <answer>
            <para>
-                If the same build is failing in totally different and random ways the most likely explanation is that either the hardware you're running it on has some problem or if you are running it under virtualisation, the virtualisation probably has bugs. Poky processes a massive amount of data causing lots of network, disk and cpu activity and is sensitive to even single bit failure in any of these areas. Totally random failures have always been traced back to hardware or virtualisation issues.
+                If the same build is failing in totally different and random ways the most likely explaination is that either the hardware you're running it on has some problem or if you are running it under virtualisation, the virtualisation probably has bugs. Poky processes a massive amount of data causing lots of network, disk and cpu activity and is senstive to even single bit failure in any of these areas. Totally random failures have always been traced back to hardware or virtualisation issues.
            </para>
        </answer>
    </qandaentry>
    <qandaentry>
        <question>
            <para>
-                What do we need to ship for license compliance?
+                What do we need to ship for licence complience?
            </para>
        </question>
        <answer>
            <para>
-                This is a difficult question and you need to consult your lawyer for the answer for your specific case. Its worth bearing in mind that for GPL compliance there needs to be enough information shipped to allow someone else to rebuild the same end result as you are shipping. This means sharing the source code, any patches applied to it but also any configuration information about how that package was configured and built.
+                This is a difficult question and you need to consult your lawyer for the answer for your specific case. Its worth bearing in mind that for GPL complience there needs to be enough information shipped to allow someone else to rebuild the same end result as you are shipping. This means sharing the source code, any patches applied to it but also any configuration information about how that package was configured and built.
            </para>
        </answer>
    </qandaentry>
-
-    <qandaentry>
-        <question>
-            <para>
-                How do I disable the cursor on my touchscreen device?
-            </para>
-        </question>
-        <answer>
-            <para>
-                You need to create a form factor file as described in 
-                <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref>
-                and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one.
-                <literallayout class='monospaced'>
-     HAVE_TOUCHSCREEN=1
-                </literallayout>
-            </para>
-        </answer>
-    </qandaentry>
-
-    <qandaentry>
-        <question>
-            <para>
-                How do I make sure connected network interfaces are brought up by default?
-            </para>
-        </question>
-        <answer>
-            <para>
-                The default interfaces file provided by the netbase recipe does not 
-                automatically bring up network interfaces. 
-                Therefore you will need to add a BSP-specific netbase that includes an interfaces 
-                file.
-                See <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref>
-                for information on creating these types of miscellaneous recipe files.
-            </para>
-            <para>
-                For example, add the following files to your layer:
-                <literallayout class='monospaced'>
-     meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
-     meta-MACHINE/recipes-bsp/netbase/netbase_4.44.bbappend
-                </literallayout>
-            </para>
-        </answer>
-    </qandaentry>
-
-    <qandaentry>
-        <question>
-            <para>
-                How do I create images with more free space?
-            </para>
-        </question>
-        <answer>
-            <para>
-                Images are created to be 1.2 times the size of the populated root filesystem. 
-                To modify this ratio so that there is more free space available you need to 
-                set the configuration value <filename>IMAGE_OVERHEAD_FACTOR</filename>.  
-                For example, setting <filename>IMAGE_OVERHEAD_FACTOR</filename> to 1.5 sets 
-                the image size ratio to one and a half times the size of the populated 
-                root filesystem.
-                <literallayout class='monospaced'>
-     IMAGE_OVERHEAD_FACTOR = "1.5"
-                </literallayout>
-            </para>
-        </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 does Poky obtain source code and will it work behind my firewall or proxy server?
-            </para>
-        </question>
-        <answer>
-            <para>
-                The way Poky obtains source code is highly configurable.
-                You can setup Poky to get source code in most environmnents if 
-                HTTP transport is available.
-            </para>
-            <para>
-                When Poky searches for source code it first tries the local download directory.
-                If that location fails, Poky tries PREMIRRORS, the upstream source, 
-                and then MIRRORS in that order.
-            </para>
-            <para>
-                By default, Poky uses the Yocto Project source PREMIRRORS for SCM-based sources, 
-                upstreams for normal tarballs and then falls back to a number of other mirrors 
-                including the Yocto Project source mirror if those fail.
-            </para>
-            <para>
-                As an example, you could add a specific server for Poky to attempt before any
-                others by adding something like the following to the <filename>local.conf</filename>
-                configuration file:
-                <literallayout class='monospaced'>
-     PREMIRRORS_prepend = "\
-     git://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
-                </literallayout>
-            </para>
-            <para>
-                These changes cause Poky to intercept GIT, FTP, HTTP, and HTTPS
-                requests and direct them to the <filename>http://</filename> sources mirror.
-                You can use <filename>file://</filename> urls to point to local directories 
-                or network shares as well.
-            </para>
-            <para>
-                Aside from the previous technique, these options also exist:
-                <literallayout class='monospaced'>
-     BB_NO_NETWORK = "1"
-                </literallayout>
-             </para>
-             <para>
-                 This statement tells BitBake to throw an error instead of trying to access the 
-                 Internet.
-                 This technique is useful if you want to ensure code builds only from local sources.
-             </para>
-             <para>
-                 Here is another technique:
-                 <literallayout class='monospaced'>
-     BB_FETCH_PREMIRRORONLY = "1"
-                 </literallayout>
-             </para>
-             <para>
-                 This statement limits Poky to pulling source from the PREMIRRORS only.
-                 Again, this technique is useful for reproducing builds.
-             </para>
-             <para>
-                 Here is another technique:
-                 <literallayout class='monospaced'>
-     BB_GENERATE_MIRROR_TARBALLS = "1"
-                 </literallayout>
-             </para>
-             <para>
-                 This statement tells Poky to generate mirror tarballs.
-                 This technique is useful if you want to create a mirror server.
-                 If not, however, the technique can simply waste time during the build.
-             </para>
-             <para>
-                 Finally, consider an example where you are behind an HTTP-only firewall.
-                 You could make the following changes to the <filename>local.conf</filename>
-                 configuration file as long as the premirror server is up to date:
-                 <literallayout class='monospaced'>
-     PREMIRRORS_prepend = "\
-     ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
-     BB_FETCH_PREMIRRORONLY = "1" 
-                 </literallayout>
-             </para>
-             <para>
-                 These changes would cause Poky to successfully fetch source over HTTP and 
-                 any network accesses to anything other than the premirror would fail.
-             </para>
-             <para>
-                 Poky also honors the standard environment variables 
-                 <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, 
-                 <filename>https_proxy</filename>, and <filename>all_proxy</filename>
-                 to redirect requests through proxy servers.
-             </para>
-        </answer>
-    </qandaentry>
-
-
-
 </qandaset>
 </appendix>
 <!-- 
--- a/documentation/poky-ref-manual/figures/cropped-yocto-project-bw.png
+++ b/documentation/poky-ref-manual/figures/cropped-yocto-project-bw.png
--- a/documentation/poky-ref-manual/figures/poky-ref-manual.png
+++ b/documentation/poky-ref-manual/figures/poky-ref-manual.png
--- a/documentation/poky-ref-manual/figures/poky-title.png
+++ b/documentation/poky-ref-manual/figures/poky-title.png
--- a/documentation/poky-ref-manual/figures/yocto-project-transp.png
+++ b/documentation/poky-ref-manual/figures/yocto-project-transp.png
--- a/documentation/poky-ref-manual/introduction.xml
+++ b/documentation/poky-ref-manual/introduction.xml
@@ -8,8 +8,8 @@
    <title>Welcome to Poky!</title>

    <para>
-        Poky is the build tool in the Yocto Project.
-        The Yocto Project uses Poky to build images (kernel, system, and application software) for 
+        Poky is the build tool in Yocto Project.
+        Yocto Project uses Poky to build images (kernel, system, and application software) for 
        targeted hardware.
    </para>

@@ -59,7 +59,7 @@
    <screenshot>
    <mediaobject>
        <imageobject>
-            <imagedata fileref="figures/ss-sato.png" format="PNG" align='center' scalefit='1' width="100%" contentdepth="100%"/>
+            <imagedata fileref="screenshots/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>
@@ -69,7 +69,7 @@

    <para>
        Poky has a growing open source community and is also backed up by commercial organizations 
-        including Intel&reg; Corporation.
+        including <ulink url="http://www.intel.com/">Intel Corporation</ulink>.
    </para>
 </section>

@@ -78,8 +78,7 @@
    <para>
        The sections in this reference manual describe different aspects of Poky. 
        The <link linkend='usingpoky'>'Using Poky'</link> section provides an overview of the components 
-        that make up Poky followed by information about using Poky and debugging images created in 
-        the Yocto Project. 
+        that make up Poky followed by information about using Poky and debugging images created in Yocto Project. 
        The <link linkend='extendpoky'>'Extending Poky'</link> and 
        <link linkend='bsp'>'Board Support Packages'</link> sections provide information 
        about how to extend and customize Poky along with advice on how to manage these changes. 
@@ -91,7 +90,7 @@
    </para>

    <para>
-        This manual applies to Poky Release 5.0 (Bernard).
+        This manual applies to Poky Release 4.0 (laverne).
    </para>
 </section>

@@ -119,7 +118,7 @@
        <title>Releases</title>

        <para>Periodically, we make releases of Poky available
-            at <ulink url='http://yoctoproject.org/downloads/poky/'/>.
+            at <ulink url='http://pokylinux.org/releases/'/>.
            These releases are more stable and more rigorously tested than the nightly development images.
        </para>
    </section>
@@ -130,7 +129,7 @@
        <para>
            We make nightly builds of Poky for testing purposes and to make the
            latest developments available. The output from these builds is available
-            at <ulink url='http://autobuilder.yoctoproject.org/'/>.
+            at <ulink url='http://autobuilder.pokylinux.org/'/>.
            The numbers used in the builds increase for each subsequent build and can be used to 
            reference a specific build.
        </para>
@@ -153,8 +152,8 @@

        <para>
            Poky is available from our git repository located at
-            git://git.yoctoproject.org/poky.git; a web interface to the repository
-            can be accessed at <ulink url='http://git.yoctoproject.org/'/>.
+            git://git.pokylinux.org/poky.git; a web interface to the repository
+            can be accessed at <ulink url='http://git.pokylinux.org/'/>.
        </para>

        <para>
--- a/documentation/poky-ref-manual/poky-ref-manual.xml
+++ b/documentation/poky-ref-manual/poky-ref-manual.xml
@@ -9,14 +9,14 @@
 
        <mediaobject>
            <imageobject>
-                <imagedata fileref='figures/poky-title.png' 
+                <imagedata fileref='figures/poky-ref-manual.png' 
                    format='SVG' 
-                    align='left' scalefit='1' width='100%'/>
+                    align='center' scalefit='1' width='100%'/>
            </imageobject>    
        </mediaobject>

-        <title></title>
-
+        <title>Poky Reference Manual</title>
+        <subtitle>A Guide and Reference to Poky</subtitle>
        <authorgroup>
            <author>
                <firstname>Richard</firstname> <surname>Purdie</surname>
@@ -47,11 +47,6 @@
                <date>24 November 2010</date>
                <revremark>Poky Master Documentation</revremark>
            </revision>
-            <revision>
-                <revnumber>5.0+git</revnumber>
-                <date>6 April 2011</date>
-                <revremark>Released with Yocto Project 1.0 (Bernard 5.0).</revremark>
-            </revision>
        </revhistory>

    <copyright>
--- a/documentation/poky-ref-manual/ref-bitbake.xml
+++ b/documentation/poky-ref-manual/ref-bitbake.xml
@@ -9,7 +9,7 @@
        BitBake is a program written in Python that interprets the metadata that makes up Poky. 
        At some point, people wonder what actually happens when you enter:
    <literallayout class='monospaced'>
-     $ bitbake core-image-sato
+     $ bitbake poky-image-sato
    </literallayout>
    </para>
   
@@ -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>meta/conf/</filename>.
-            BitBake finds it by examining the <filename>BBPATH</filename> environment 
-            variable and looking for the <filename>meta/conf/</filename> 
+            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> 
            directory.
        </para>

        <para>
            In Poky, <filename>bitbake.conf</filename> lists other configuration 
-            files to include from a <filename>conf/</filename> 
-            directory below the directories listed in <filename>BBPATH</filename>. 
+            files to include from a <filename class="directory">conf/</filename> 
+            directory below the directories listed in <varname>BBPATH</varname>. 
            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>
+            configuration files are available in the <filename class="directory">
            meta/conf/distro/</filename> directory and valid machine configuration 
-            files in the <filename>meta/conf/machine/</filename> 
+            files in the <filename class="directory">meta/conf/machine/</filename> 
            directory. 
-            Within the <filename>meta/conf/machine/include/</filename> 
+            Within the <filename class="directory">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 <filename>BBPATH</filename> in the same way as
+            under the paths in <varname>BBPATH</varname> in the same way as
            configuration files.
        </para>

@@ -79,29 +79,31 @@
            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>.bb</filename> files. 
-            By default, the BBFILES variable specifies the <filename>meta/recipes-*/
-            </filename> directory within Poky. 
+            <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. 
            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>.bb</filename> file in BBFILES and 
+            BitBake parses each <filename class="extension">.bb</filename> file in BBFILES and 
            stores the values of various variables.  
-            In summary, for each <filename>.bb</filename> 
+            In summary, for each <filename class="extension">.bb</filename> 
            file the configuration plus the base class of variables are set, followed 
-            by the data in the <filename>.bb</filename> file 
+            by the data in the <filename class="extension">.bb</filename> file 
            itself, followed by any inherit commands that
-            <filename>.bb</filename> file might contain.
+            <filename class="extension">.bb</filename> file might contain.
        </para>

        <para>
-            Because parsing <filename>.bb</filename> files is a time 
+            Because parsing <filename class="extension">.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>.bb</filename> 
+            This cache is invalid if the timestamp of the <filename class="extension">.bb</filename> 
            file itself changes, or if the timestamps of any of the include, 
-            configuration or class files the <filename>.bb</filename>
+            configuration or class files the <filename class="extension">.bb</filename>
            file depends on changes.
        </para>
    </section>
@@ -110,12 +112,12 @@
        <title>Preferences and Providers</title>

        <para>
-            Once all the <filename>.bb</filename> files have been 
-            parsed, BitBake starts to build the target (core-image-sato in the previous section's 
+            Once all the <filename class="extension">.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  
            the target. 
-            In the case of "core-image-sato", it would lead to <filename>task-base.bb</filename>,  
+            In the case of "poky-image-sato", it would lead to <filename>task-base.bb</filename>,  
            which in turn leads to packages like <application>Contacts</application>, 
            <application>Dates</application> and <application>BusyBox</application>.
            These packages in turn depend on glibc and the toolchain.
@@ -123,7 +125,7 @@

        <para>
            Sometimes a target might have multiple providers.
-            A common example is "virtual/kernel", which is provided by each kernel package. 
+            An 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>
@@ -193,18 +195,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 tasks have all their dependencies met, and the thread threshold has not been 
+            those taksks 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>build/tmp/stamps/*/</filename>). 
+            <filename class="directory">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>.bb</filename> file basis.
+            <filename class="extension">.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 
--- a/documentation/poky-ref-manual/ref-classes.xml
+++ b/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>.bb</filename> files. Any metadata usually found in a 
-    <filename>.bb</filename> file can also be placed in a class 
+    <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 
    file. Class files are identified by the extension 
-    <filename>.bbclass</filename> and are usually placed 
-    in a <filename>classes/</filename> directory beneath the 
-    <filename>meta*/</filename> directory or the directory pointed
-    by BUILDDIR (e.g. <filename>build/</filename>)in the same way as
-    <filename>.conf</filename> files in the <filename 
+    <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 
    class="directory">conf</filename> directory. Class files are searched for 
-    in BBPATH in the same was as <filename>.conf</filename> files too.
+    in BBPATH in the same was as <filename class="extension">.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>.bb</filename> 
+        The base class is special in that every <filename class="extension">.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 <filename>oe_runmake</filename>.
+        used functions such as <function>oe_runmake</function>.
    </para>
 </section>

@@ -43,13 +43,13 @@
    <title>Autotooled Packages - <filename>autotools.bbclass</filename></title>

    <para>
-        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.
+        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.
    </para>

    <para>
@@ -60,29 +60,26 @@
    <itemizedlist>
      <listitem>
        <para>
-            <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.
+            '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.
        </para>
      </listitem>
      <listitem>
        <para>
-            <filename>do_compile</filename> &dash; runs <filename>make</filename> with 
-            arguments that specify the compiler and linker. 
-            You can pass additional arguments through 
+            'do_compile' runs <command>make</command> with arguments specifying 
+            the compiler and linker. Additional arguments can be passed through 
            the <glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link>
            </glossterm> variable.
        </para>
      </listitem>
      <listitem>
        <para>
-            <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.
+            '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.
        </para>
      </listitem>
    </itemizedlist>
@@ -94,31 +91,54 @@

    <para>
        Several programs can fulfill the same or similar function and
-        be installed with the same name. 
-        For example, the <filename>ar</filename> 
+        they can be installed with the same name. For example the <command>ar</command> 
        command is available from the "busybox", "binutils" and "elfutils" packages. 
-        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 
+        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 
        and symlinks the highest priority binary during installation or removal 
        of packages.
-    </para>
-    <para>
+
        Four variables control this class:
    </para>
-    <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>
+
+
+    <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>
+
    <para>
 	Currently, only one binary per package is supported.
    </para>
@@ -152,7 +172,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>sysroots/</filename>
+        paths to point into the <filename class="directory">sysroots/</filename>
        directory so all builds which use the script will use the correct 
        directories for the cross compiling layout.
    </para>
@@ -195,7 +215,7 @@
    </para>

    <para>
-        Result of their work are <filename>tmp/deploy/source/</filename> 
+        Result of their work are <filename class="directory">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.
@@ -299,7 +319,7 @@
    </para>
    <para>
        This means that each kernel module built is packaged separately and inter-module dependencies are
-        created by parsing the <filename>modinfo</filename> output. If all modules are
+        created by parsing the <command>modinfo</command> 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>
@@ -383,7 +403,7 @@

    <para>
        Only the most useful/important classes are covered here but there are 
-        others, see the <filename>meta/classes</filename> directory for the rest. 
+        others, see the <filename class="directory">meta/classes</filename> directory for the rest. 
    </para>
 </section>

--- a/documentation/poky-ref-manual/ref-images.xml
+++ b/documentation/poky-ref-manual/ref-images.xml
@@ -5,83 +5,62 @@
    <title>Reference: Images</title>

    <para>
-        Poky has several standard images covering most people's standard needs. 
-        Use the following command to list the supported images:
-        <literallayout class='monospaced'>
-     $ ls meta*/recipes*/images/*.bb
-        </literallayout>
-        Images are listed below along with details of what they contain:
+        Poky has several standard images covering most people's standard needs. A full 
+        list of image targets can be found by looking in the directories 
+        <filename class="directory">  meta/recipes-core/images/</filename>, 
+        <filename class="directory">  meta/recipes-extended/images/</filename>, 
+        <filename class="directory">  meta/recipes-sato/images/</filename> and 
+        <filename class="directory">  meta/recipes-tbd/meta/</filename>. The standard 
+        images are listed below along with details of what they contain:
    </para>

-    <note>
-        Building an image without GNU Public License Version 3 (GPLv3) components is 
-        only supported for minimal and base images.
-        Furthermore, if you are going to build an image using non-GPLv3 components,
-        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 EXTRA_IMAGE_FEATURES line
-     2. Set INCOMPATIBLE_LICENSE = "GPLv3"
-        </literallayout>
-    </note>
-
    <itemizedlist>
            <listitem>
                <para>
-                    <emphasis>core-image-minimal</emphasis> - A small image just capable 
-                    of allowing a device to boot.
+                    <emphasis>poky-image-minimal</emphasis> - A small image, just enough 
+                    to allow a device to boot
                </para>
            </listitem>
            <listitem>
                <para>
-                    <emphasis>core-image-base</emphasis> - A console-only image that fully 
-                    supports the target device hardware. 
+                    <emphasis>poky-image-base</emphasis> - console only image with full
+                    support of target device hardware
                </para>
            </listitem>
            <listitem>
                <para>
-                    <emphasis>core-image-core</emphasis> - An X11 image with simple 
-                    applications such as terminal, editor, and file manager.
+                    <emphasis>poky-image-core</emphasis> - X11 image with simple apps like
+                    terminal, editor and file manager
                </para>
            </listitem>
            <listitem>
                <para>
-                    <emphasis>core-image-sato</emphasis> - An X11 image with Sato theme and
-                    Pimlico applications. 
-                    The image also contains terminal, editor, and file manager.
+                    <emphasis>poky-image-sato</emphasis> - X11 image with Sato theme and
+                    Pimlico applications. Also contains terminal, editor and file manager.
                </para>
            </listitem>
            <listitem>
                <para>
-                    <emphasis>core-image-sato-dev</emphasis> - An X11 image similar to 
-                    core-image-sato but
-                    also includes a native toolchain and libraries needed to build applications 
-                    on the device itself. The image also includes testing and profiling tools 
-                    as well as debug symbols.  This image was formerly core-image-sdk.
+                    <emphasis>poky-image-sdk</emphasis> - X11 image like poky-image-sato but
+                    also include native toolchain and libraries needed to build applications 
+                    on the device itself. Also includes testing and profiling tools and debug
+                    symbols.
                </para>
            </listitem>
            <listitem>
                <para>
-                    <emphasis>core-image-lsb</emphasis> - An image suitable for implementations 
-                    that conform to Linux Standard Base (LSB).
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis>meta-toolchain</emphasis> - This image generates a tarball 
-                    that contains a stand-alone toolchain that can be used externally to Poky. 
-                    The tarball is self-contained and unpacks to the 
-                    <filename class="directory">/opt/poky</filename> directory. 
-                    The tarball also contains a copy of QEMU and the scripts necessary to run 
+                    <emphasis>meta-toolchain</emphasis> - This generates a tarball containing
+                    a standalone toolchain which can be used externally to Poky. It is self
+                    contained and unpacks to the <filename class="directory">/opt/poky</filename>
+                    directory. It also contains a copy of QEMU and the scripts necessary to run 
                    poky QEMU images.
                </para>
            </listitem>
            <listitem>
                <para>
-                    <emphasis>meta-toolchain-sdk</emphasis> - This image includes everything in 
+                    <emphasis>meta-toolchain-sdk</emphasis> - This includes everything in 
                    meta-toolchain but also includes development headers and libraries
-                    to form a complete standalone SDK. 
-                    See the <link linkend='platdev-appdev-external-sdk'> 
+                    forming a complete standalone SDK. See the <link linkend='platdev-appdev-external-sdk'> 
                    External Development Using the Poky SDK</link> section for more information.
                </para>
            </listitem>
--- a/documentation/poky-ref-manual/ref-structure.xml
+++ b/documentation/poky-ref-manual/ref-structure.xml
@@ -28,12 +28,13 @@
            Consequently, most users do not need to worry about BitBake.
            The <filename class="directory">bitbake/bin/</filename> directory is placed 
            into the PATH environment variable by the 
-            <link linkend="structure-core-script">oe-init-build-env</link> script.
+            <link linkend="structure-core-script">poky-init-build-env</link> script.
        </para>

        <para>
-            For more information on BitBake, see the BitBake on-line manual at 
-            <ulink url="http://bitbake.berlios.de/manual/"/>.
+            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/"/>.
        </para>
    </section>

@@ -47,7 +48,7 @@
            It is also possible to place output and configuration 
            files in a directory separate from the Poky source.
            For information on separating output from the Poky source, see <link 
-            linkend='structure-core-script'>oe-init-build-env</link>.
+            linkend='structure-core-script'>poky-init-build-env</link>.
        </para>
    </section>

@@ -61,7 +62,7 @@
        </para>
    </section>

-<!--    <section id='structure-core-meta-extras'>
+    <section id='structure-core-meta-extras'>
        <title><filename class="directory">meta-extras/</filename></title>

        <para>
@@ -70,25 +71,8 @@
            This metadata is disabled by default and is not supported as part of Poky.
        </para>
    </section>
-->

-    <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-***'>
+    <section id='structure-core-meta-***'>
        <title><filename class="directory">meta-***/</filename></title>

        <para>
@@ -96,7 +80,6 @@
            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>
@@ -104,12 +87,12 @@
        <para>
            This directory contains various integration scripts that implement 
            extra functionality in the Poky environment (e.g. QEMU scripts).
-            The <link linkend="structure-core-script">oe-init-build-env</link> script appends this
+            The <link linkend="structure-core-script">poky-init-build-env</link> script appends this
            directory to the PATH environment variable.
        </para>
    </section>

-<!--    <section id='structure-core-sources'>
+    <section id='structure-core-sources'>
        <title><filename class="directory">sources/</filename></title>

        <para>
@@ -141,7 +124,6 @@
            <filename class="extension">.md5</filename> file as well.
        </para>
    </section>
-->

    <section id='handbook'>
        <title><filename class="directory">documentation</filename></title>
@@ -154,7 +136,7 @@
    </section>

    <section id='structure-core-script'>
-        <title><filename>oe-init-build-env</filename></title>
+        <title><filename>poky-init-build-env</filename></title>

        <para>
            This script sets up the Poky build environment. 
@@ -168,7 +150,7 @@
        </para>

        <literallayout class='monospaced'>
-     $ source POKY_SRC/oe-init-build-env [BUILDDIR]
+     $ source POKY_SRC/poky-init-build-env [BUILDDIR]
        </literallayout>

        <para>
@@ -178,28 +160,11 @@
            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>

@@ -233,36 +198,6 @@
        </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>

@@ -276,14 +211,6 @@
        </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>

@@ -304,7 +231,7 @@
        <title><filename class="directory">build/tmp/deploy/deb/</filename></title>

        <para>
-            This directory receives any <filename>.deb</filename> packages produced by Poky.
+            This directory receives any .deb packages produced by Poky.
            The packages are sorted into feeds for different architecture types.
        </para>
    </section>
@@ -313,7 +240,7 @@
        <title><filename class="directory">build/tmp/deploy/rpm/</filename></title>

        <para>
-            This directory receives any <filename>.rpm</filename> packages produced by Poky.  
+            This directory receives any .rpm packages produced by Poky.  
            The packages re sorted into feeds for different architecture types.
        </para>
    </section>
@@ -330,7 +257,7 @@
    <section id='structure-build-tmp-deploy-ipk'>
        <title><filename class="directory">build/tmp/deploy/ipk/</filename></title>

-        <para>This directory receives <filename>.ipk</filename> packages produced by Poky.</para>
+        <para>This directory receives .ipk packages produced by Poky.</para>
    </section>

    <section id='structure-build-tmp-sysroots'>
@@ -586,15 +513,6 @@
        </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>

@@ -605,14 +523,6 @@
            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>
--- a/documentation/poky-ref-manual/ref-variables.xml
+++ b/documentation/poky-ref-manual/ref-variables.xml
@@ -87,22 +87,9 @@

        <glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm>
            <glossdef>
-                <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>
+                <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>
            </glossdef>
        </glossentry>

@@ -779,12 +766,6 @@ 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>
--- a/documentation/poky-ref-manual/resources.xml
+++ b/documentation/poky-ref-manual/resources.xml
@@ -18,8 +18,8 @@
    <title>Bugtracker</title>

    <para>
-        Problems with Poky should be reported using the Bugzilla application at 
-        <ulink url='http://bugzilla.yoctoproject.org/'></ulink>.
+        Problems with Poky should be reported in the 
+        <ulink url='http://bugzilla.pokylinux.org/'>bug tracker</ulink>.
    </para>
 </section>

@@ -74,11 +74,9 @@
            <ulink url='http://yoctoproject.org'>The Yocto Project website</ulink> - The home site
            for Yocto Project.
        </para></listitem>
-<!--        <listitem><para>
-            <ulink url='http://pokylinux.org'>The Poky website</ulink> - The home site
-            for Poky Linux.
+        <listitem><para>
+            <ulink url='http://pokylinux.org'>The Poky website</ulink> 
        </para></listitem>
-->
        <listitem><para>
            <ulink url='http://www.openedhand.com/'>OpenedHand</ulink> - The
            original company behind Poky.
@@ -98,8 +96,8 @@
            - The tool used to process Poky metadata.
        </para></listitem>
        <listitem><para>
-            <ulink url='http://bitbake.berlios.de/manual/'>BitBake User
-                Manual</ulink> - A comprehensive guide to the BitBake tool.
+            <ulink url='http://bitbake.berlios.de/manual/'>Bitbake User
+                Manual</ulink>
        </para></listitem>
        <listitem><para>
            <ulink url='http://pimlico-project.org/'>Pimlico</ulink> - A
@@ -150,7 +148,7 @@
 </programlisting>

    <para>
-        A Poky contributions tree (poky-contrib, git://git.yoctoproject.org/poky-contrib.git)
+        A Poky contributions tree (poky-contrib, git://git.pokylinux.org/poky-contrib.git)
        exists for people to stage contributions in, for regular contributors.
        If people desire such access, please ask on the mailing list. Usually
        access will be given to anyone with a proven track record of good patches.
--- a/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-1.png
+++ b/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-1.png
--- a/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-2.png
+++ b/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-2.png
--- a/documentation/poky-ref-manual/screenshots/ss-oprofile-viewer.png
+++ b/documentation/poky-ref-manual/screenshots/ss-oprofile-viewer.png
--- a/documentation/poky-ref-manual/screenshots/ss-sato.png
+++ b/documentation/poky-ref-manual/screenshots/ss-sato.png
--- a/documentation/poky-ref-manual/style.css
+++ b/documentation/poky-ref-manual/style.css
@@ -50,13 +50,9 @@ body {
  color: #333;
 }

-.reviewer {
-  color: red;
-}
-
 h1,h2,h3,h4,h5,h6,h7 {
  font-family: Arial, Sans;
-  color: #00557D;
+  color:#999999;
  clear: both;
 }

@@ -80,7 +76,7 @@ h2 {
  margin: 2em 0em 0.66em 0em;
  padding: 0.5em 0em 0em 0em;
  font-size: 1.5em;
-  font-weight: bold;
+  font-weight: normal;
 }

 h3.subtitle {
@@ -94,41 +90,41 @@ h3 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
  font-size: 140%;
-  font-weight: bold;
+  font-weight: normal;
 }

 h4 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
  font-size: 120%;
-  font-weight: bold;
+  font-weight: normal;
 }

 h5 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
+  font-size: 110.000%;
+  border-bottom: 1px solid black;
 }

 h6 {
  margin: 1em 0em 0em 0em;
  padding: 1em 0em 0em 0em;
  font-size: 80%;
-  font-weight: bold;
+  font-weight: normal;
 }

 .authorgroup {
  background-color: transparent;
  background-repeat: no-repeat;
  padding-top: 256px;
-  background-image: url("figures/poky-title.png");
+  background-image: url("figures/poky-ref-manual.png");
  background-position: left top;
  margin-top: -256px;
  padding-right: 50px;
-  margin-left: 0px;
+  margin-left: 50px;
  text-align: right;
-  width: 740px;
+  width: 600px;
 }

 h3.author {
@@ -136,7 +132,6 @@ h3.author {
  padding: 0em 0em 0em 0em;
  font-weight: normal;
  font-size: 100%;
-  color: #333;
  clear: both;
 }

@@ -159,7 +154,6 @@ h3.author {
 .list-of-examples,
 .list-of-figures {
  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
 }

 .toc p,
@@ -771,22 +765,12 @@ h6,
 h7{
 }

-/*
-Example of how to stick an image as part of the title.
-
-div.article .titlepage .title
-{
-  background-image: url("figures/white-on-black.png");
-  background-position: center;
-  background-repeat: repeat-x;
-}
-*/
-
 div.preface .titlepage .title, 
 div.colophon .title, 
-div.chapter .titlepage .title,
-div.article .titlepage .title 
-{
+div.chapter .titlepage .title {
+  background-image: url("images/title-bg.png");
+  background-position: bottom;
+  background-repeat: repeat-x;
 }

 div.section div.section .titlepage .title,
@@ -797,7 +781,7 @@ div.sect2 .titlepage .title {

 h1.title {
  background-color: transparent;
-  background-image: url("figures/poky-title.png");
+  background-image: url("poky-ref-manual.png");
  background-repeat: no-repeat;
  height: 256px;
  text-indent: -9000px;
@@ -946,7 +930,7 @@ table {

 .tip,
 .note {
-   background: #666666;
+   background: #91ae35;
   color: #fff;   
   padding: 20px;
   margin: 20px;
--- a/documentation/poky-ref-manual/usingpoky.xml
+++ b/documentation/poky-ref-manual/usingpoky.xml
@@ -5,7 +5,7 @@

    <para>
        This section gives an overview of the components that make up Poky 
-        followed by information about running poky builds and dealing with any
+        following by information about running poky builds and dealing with any
        problems that may arise.
    </para>

@@ -13,13 +13,13 @@
    <title>Poky Overview</title>

    <para>
-        The BitBake task executor together with various types of configuration files form the core of Poky.
-        This section overviews the BitBake task executor and the
+        The bitbake task executor together with various types of configuration files form the core of Poky.
+        This section overviews the bitbake task executor and the
        configuration files by describing what they are used for and they they interact.
    </para>
    
    <para>  
-        BitBake handles the parsing and execution of the data files. 
+        Bitbake handles the parsing and execution of the data files. 
        The data itself is of various types:
    <itemizedlist>
        <listitem><para>Recipes:  Provides details about particular pieces of software</para></listitem>
@@ -31,7 +31,7 @@
    </para>

    <para> 
-        BitBake knows how to combine multiple data sources together and refers to each data source
+        Bitbake knows how to combine multiple data sources together and refers to each data source
        as a <link linkend='usingpoky-changes-layers'>'layer'</link>.
    </para>

@@ -43,17 +43,17 @@
    </para>

    <section id='usingpoky-components-bitbake'>
-        <title>BitBake</title>
+        <title>Bitbake</title>

        <para>
-            BitBake is the tool at the heart of Poky and is responsible
+            Bitbake is the tool at the heart of Poky and is responsible
            for parsing the metadata, generating a list of tasks from it
-            and then executing them. To see a list of the options BitBake
+            and then executing them. To see a list of the options bitbake
            supports look at 'bitbake --help'.
        </para>

        <para>
-            The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
+            The most common usage for bitbake is <filename>bitbake &lt;packagename&gt;</filename>, where
            packagename is the name of the package you want to build (referred to as the 'target'
            in this manual). 
            The target often equates to the first part of a <filename>.bb</filename> filename.
@@ -63,14 +63,14 @@
     $ bitbake matchbox-desktop
            </literallayout>
            Several different versions of <filename>matchbox-desktop</filename> might exist.
-            BitBake chooses the one selected by the distribution configuration.
-            You can get more details about how BitBake chooses between different versions
+            Bitbake chooses the one selected by the distribution configuration.
+            You can get more details about how bitbake chooses between different versions
            and providers in the <link linkend='ref-bitbake-providers'>
            'Preferences and Providers'</link> section.
        </para>
        <para>
-            BitBake also tries to execute any dependent tasks first.
-            So for example, before building <filename>matchbox-desktop</filename> BitBake
+            Bitbake also tries to execute any dependent tasks first.
+            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>

@@ -131,14 +131,14 @@
    </para>
    <para>
        <literallayout class='monospaced'>
-     $ source oe-init-build-env [build_dir]
+     $ source poky-init-build-env [build_dir]
        </literallayout>
    </para>
    <para>
        The build_dir is the dir containing all the build's object files. The default 
        build dir is poky-dir/build. A different build_dir can be used for each of the targets. 
        For example, ~/build/x86 for a qemux86 target, and ~/build/arm for a qemuarm target.
-        Please refer to <link linkend="structure-core-script">oe-init-build-env</link>
+        Please refer to <link linkend="structure-core-script">poky-init-build-env</link>
        for more detailed information.
    </para>
    <para>
@@ -151,24 +151,13 @@
    </para>
    <para>
        The target is the name of the recipe you want to build. 
-        Common targets are the images in <filename>meta/recipes-core/images</filename>,
+        Common targets are the images in <filename>meta/recipes-core/images</filename>),
        <filename>/meta/recipes-sato/images</filename>, etc.
        Or, the target can be the name of a recipe for a specific piece of software such as 
        <application>busybox</application>. 
        For more details about the standard images available, see the 
        <link linkend="ref-images">'Reference: Images'</link> appendix.
    </para>
-    <note>
-        Building an image without GNU Public License Version 3 (GPLv3) components is 
-        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'>
@@ -194,12 +183,12 @@
    <para>
        The exact method for debugging Poky depends on the nature of the 
        problem and on the system's area from which the bug originates. 
-        Standard debugging practices such as comparison against the last 
-        known working version with examination of the changes and the re-application of steps 
+        Standard debugging practises such as comparison against the last 
+        known working version with examination of the changes and the reapplication of steps 
        to identify the one causing the problem are
        valid for Poky just as they are for any other system. 
-        Even though it is impossible to detail every possible potential failure, 
-        here are some general tips to aid in debugging:
+        It's impossible to detail every possible potential failure but here are some general
+        tips to aid in debugging:
    </para>

    <section id='usingpoky-debugging-taskfailures'>
@@ -208,7 +197,7 @@
        <para>The log file for shell tasks is available in <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>. 
            For example, the "compile" task of busybox 1.01 on the ARM spitz machine might be 
            <filename>tmp/work/armv5te-poky-linux-gnueabi/busybox-1.01/temp/log.do_compile.1234</filename>.
-            To see what BitBake runs to generate that log, look at the corresponding 
+            To see what bitbake runs to generate that log, look at the corresponding 
            <filename>run.do_taskname.pid </filename> file located in the same directory.
        </para>

@@ -225,10 +214,10 @@
            In most cases the series is: fetch, unpack, patch, configure,
            compile, install, package, package_write and build. 
            The default task is "build" and any tasks on which it depends build first - hence, 
-            the standard BitBake behaviour. 
+            the standard bitbake behaviour. 
            Some tasks exist, such as devshell, that are not part of the default build chain.  
            If you wish to run a task that is not part of the default build chain you can use the 
-            "-c" option in BitBake as follows:
+            "-c" option in bitbake as follows:
            <literallayout class='monospaced'>
     $ bitbake matchbox-desktop -c devshell
            </literallayout>
@@ -252,7 +241,7 @@
        <para>
            This sequence first builds <filename>matchbox-desktop</filename> and then recompiles it.
            The last command reruns all tasks, basically the packaging tasks, after the compile.
-            BitBake recognizes that the "compile" task was rerun and therefore understands that the other
+            Bitbake recognizes that the "compile" task was rerun and therefore understands that the other
            tasks also need to be run again.
        </para>

@@ -270,7 +259,7 @@
        <title>Dependency Graphs</title>

        <para>
-            Sometimes it can be hard to see why BitBake wants to build some other packages before a given 
+            Sometimes it can be hard to see why bitbake wants to build some other packages before a given 
            package you've specified.
            The <filename>bitbake -g targetname</filename> command creates the <filename>depends.dot</filename> and
            <filename>task-depends.dot</filename> files in the current directory. 
@@ -281,11 +270,11 @@
    </section>

    <section id='usingpoky-debugging-bitbake'>
-        <title>General BitBake Problems</title>
+        <title>General Bitbake Problems</title>

        <para>
-            You can see debug output from BitBake by using the "-D" option.
-            The debug output gives more information about what BitBake
+            You can see debug output from bitbake by using the "-D" option.
+            The debug output gives more information about what bitbake
            is doing and the reason behind it. 
            Each "-D" option you use increases the logging level.
            The most common usage is <filename>-DDD</filename>.
@@ -293,9 +282,9 @@

        <para>
            The output from <filename>bitbake -DDD -v targetname</filename> can reveal why
-            BitBake chose a certain version of a package or why BitBake
+            bitbake chose a certain version of a package or why bitbake
            picked a certain provider.
-            This command could also help you in a situation where you think BitBake did something 
+            This command could also help you in a situation where you think bitbake did something 
            unexpected.
        </para>
    </section>
@@ -307,7 +296,7 @@
            the command form <filename>bitbake -b somepath/somefile.bb</filename>. 
            This command form does not check for dependencies so you should use it
            only when you know its dependencies already exist. 
-            You can also specify fragments of the filename and BitBake checks for a unique match.
+            You can also specify fragments of the filename and bitbake checks for a unique match.
        </para>
    </section>

--- a/documentation/yocto-project-qs/Makefile
+++ b/documentation/yocto-project-qs/Makefile
@@ -22,13 +22,11 @@ tarball: html
 validate:
 	xmllint --postvalid --xinclude --noout yocto-project-qs.xml

-MANUALS = yocto-project-qs.html
-FIGURES = figures/*.png
-STYLESHEET = *.css
+OUTPUTS = yocto-project-qs.tgz yocto-project-qs.html
+SOURCES = *.png *.xml *.css

 publish:
-	scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/yocto-quick-start
-	scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/yocto-quick-start/figures
+	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/

 clean:
-	rm -f $(MANUALS)
+	rm -f $(OUTPUTS)
--- a/documentation/yocto-project-qs/figures/cropped-yocto-project-bw.png
+++ b/documentation/yocto-project-qs/figures/cropped-yocto-project-bw.png
--- a/documentation/yocto-project-qs/figures/white-on-black.png
+++ b/documentation/yocto-project-qs/figures/white-on-black.png
--- a/documentation/yocto-project-qs/figures/yocto-environment.png
+++ b/documentation/yocto-project-qs/figures/yocto-environment.png
--- a/documentation/yocto-project-qs/style.css
+++ b/documentation/yocto-project-qs/style.css
@@ -50,13 +50,9 @@ body {
  color: #333;
 }

-.reviewer {
-  color: red;
-}
-
 h1,h2,h3,h4,h5,h6,h7 {
  font-family: Arial, Sans;
-  color: #00557D;
+  color:#999999;
  clear: both;
 }

@@ -80,7 +76,7 @@ h2 {
  margin: 2em 0em 0.66em 0em;
  padding: 0.5em 0em 0em 0em;
  font-size: 1.5em;
-  font-weight: bold;
+  font-weight: normal;
 }

 h3.subtitle {
@@ -94,28 +90,28 @@ h3 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
  font-size: 140%;
-  font-weight: bold;
+  font-weight: normal;
 }

 h4 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
  font-size: 120%;
-  font-weight: bold;
+  font-weight: normal;
 }

 h5 {
  margin: 1em 0em 0.5em 0em;
  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
+  font-size: 110.000%;
+  border-bottom: 1px solid black;
 }

 h6 {
  margin: 1em 0em 0em 0em;
  padding: 1em 0em 0em 0em;
  font-size: 80%;
-  font-weight: bold;
+  font-weight: normal;
 }

 .authorgroup {
@@ -136,7 +132,6 @@ h3.author {
  padding: 0em 0em 0em 0em;
  font-weight: normal;
  font-size: 100%;
-  color: #333;
  clear: both;
 }

@@ -159,7 +154,6 @@ h3.author {
 .list-of-examples,
 .list-of-figures {
  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
 }

 .toc p,
@@ -247,6 +241,7 @@ div.legalnotice p.legalnotice-title {
 p {
  line-height: 1.5em;
  margin-top: 0em;
+  color: black; font-size: 100%;
  
 }

@@ -946,7 +941,7 @@ table {

 .tip,
 .note {
-   background: #666666;
+   background: #91ae35;
   color: #fff;   
   padding: 20px;
   margin: 20px;
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -13,10 +13,9 @@
    <title>Welcome!</title>
    <para>
        Welcome to the Yocto Project!  
-        The Yocto Project is an open-source collaboration project focused on embedded Linux
+        The Yocto Project (YP) is an open-source collaboration project focused on embedded Linux
        developers.
-        Amongst other things, the Yocto Project uses the Poky build tool to 
-        construct complete Linux images.
+        Amongst other things, YP uses the Poky build tool to construct complete Linux images.
    </para>
    <para>
        This short document will give you some basic information about the environment as well 
@@ -27,18 +26,11 @@
        and run it using the QEMU emulator.
    </para>
    <para>
-        For complete information on the Yocto Project, you should check out the 
+        For complete information on the Yocto Project you should check out the 
        <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>.
        You can find the latest builds, breaking news, full development documentation, and a 
        rich Yocto Project Development Community into which you can tap.
    </para>
-    <para>
-        Finally, you might find the Frequently Asked Questions (FAQ) for the Yocto Project
-        at <ulink url='https://wiki.yoctoproject.org/wiki/FAQ'>Yocto Project FAQ</ulink> and 
-        the FAQ appendix located in the 
-        <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
-        Poky Reference Manual</ulink> helpful.
-    </para>
 </section>

 <section id='yp-intro'>
@@ -47,7 +39,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 Yocto Project to design, develop, build, debug, simulate,
+        You can use components from the the Yocto Project to design, develop, build, debug, simulate,
        and test the complete software stack using Linux, the X Window System, GNOME Mobile-based
        application frameworks, and Qt frameworks.
    </para>
@@ -91,11 +83,11 @@
    </itemizedlist>

    <para>
-        The Yocto Project can generate images for many kinds of devices.  
+        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 the Yocto Project can boot inside a QEMU emulator, the 
+        Because an image developed with Yocto Project can boot inside a QEMU emulator, the 
        development environment works nicely as a test platform for developing embedded software.
    </para>

@@ -103,7 +95,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>
@@ -119,12 +111,7 @@
    <itemizedlist>
        <listitem>
            <para>A host system running a supported Linux distribution (i.e. recent releases of
-                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>
+                Fedora, OpenSUSE, Debian, and Ubuntu).</para>
        </listitem>
        <listitem>
            <para>The right packages.</para>
@@ -155,7 +142,7 @@
     unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
     python-pysqlite2 diffstat help2man make gcc build-essential \
     g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
-     mercurial autoconf automake groff
+     mercurial autoconf automake
            </literallayout>

        <para>
@@ -189,7 +176,7 @@
            
        <para>
            The latest release images for the Yocto Project are kept at 
-            <ulink url="http://yoctoproject.org/downloads/yocto-1.0/"></ulink>.
+            <ulink url="http://yoctoproject.org/downloads/yocto-0.9/"></ulink>.
            Nightly and developmental builds are also maintained.  However, for this 
            document a released version of Yocto Project is used.
        </para>
@@ -241,21 +228,11 @@
             recommend having at least 100GB of free disk space.
         </para></note>

-         <note><para>
-             By default, Poky searches for source code using a pre-determined order
-             through a set of locations.
-             If you encounter problems with Poky finding and downloading source code, see
-             the FAQ entry "How does Poky obtain source code and will it work behind my
-             firewall or proxy server?" in the 
-             <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
-             Poky Reference Manual</ulink>.
-         </para></note>
-
         <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/oe-init-build-env poky-5.0-build
+     $ wget http://www.yoctoproject.org/downloads/poky/poky-laverne-4.0.tar.bz2
+     $ tar xjf poky-laverne-4.0.tar.bz2
+     $ source poky-laverne-4.0/poky-init-build-env poky-4.0-build
             </literallayout>
         </para>

@@ -265,7 +242,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>

@@ -273,8 +250,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-4.0-build</filename> directory and executes the <command>cd</command>
+             command to make <filename>poky-4.0-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 
@@ -293,6 +270,15 @@
             <literallayout class='monospaced'>
     $ bitbake poky-image-sato
             </literallayout>
+             <note><para>
+                 If you are running Fedora 14 or another distribution 
+                 that ships with GNU make v3.82 you need to run the following two 
+                 <command>bitbake</command> commands instead:
+                 <literallayout class='monospaced'>
+     $ bitbake make-native
+     $ bitbake poky-image-sato
+                 </literallayout>
+             </para></note>
             <note><para>
                 BitBake requires Python 2.6.  For more information on this requirement, 
                 see the FAQ appendix in the 
@@ -301,7 +287,7 @@
             </para></note>
             The final command runs the image:
             <literallayout class='monospaced'>
-     $ runqemu qemux86
+     $ poky-qemu qemux86
             </literallayout>
             <note><para>
                 Depending on the number of processors and cores, the amount or RAM, the speed of your
@@ -366,11 +352,10 @@
        <section id='installing-the-toolchain'>
        <title>Installing the Toolchain</title>
         <para>
-             You can download the pre-built toolchain, which includes the runqemu script and 
-             support files, from 
-             <ulink url='http://yoctoproject.org/downloads/yocto-1.0/toolchain/'></ulink>.  
+             You can download the pre-built toolchain, which includes the poky-qemu script and 
+             support files, from <ulink url='http://yoctoproject.org/downloads/yocto-0.9/toolchain/'></ulink>.  
             Toolchains are available for 32-bit and 64-bit development systems from the 
-             <filename>i686</filename> and <filename>x86_64</filename> folders, respectively. 
+             <filename>i586</filename> and <filename>x86_64</filename> folders, respectively. 
             Each type of development system supports five target architectures.
             The tarball files are named such that a string representing the host system appears 
             first in the filename and then is immediately followed by a string representing
@@ -382,10 +367,10 @@

     Where:
         &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system: 
-                i686 or x86_64.
+                i586 or x86_64.
       
         &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
-                i686, x86_64, powerpc, mips, or arm.
+                i585, x86_64, powerpc, mips, or arm.
       
         &lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project.
         </literallayout>
@@ -396,7 +381,7 @@
         </para>

         <literallayout class='monospaced'>
-     yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2
+     yocto-eglibc-x86_64-i586-toolchain-sdk-0.9.tar.bz2
         </literallayout>

         <para>
@@ -408,7 +393,7 @@
         <para>
             <literallayout class='monospaced'>
     $ cd /
-     $ sudo tar -xvjf yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2
+     $ sudo tar -xvjf yocto-eglibc-x86_64-i586-toolchain-sdk-0.9.tar.bz2
             </literallayout>
         </para>
         </section>
@@ -418,7 +403,7 @@
         <para>
             You can download the pre-built Linux kernel and the filesystem image suitable for 
             running in the emulator QEMU from 
-             <ulink url='http://yoctoproject.org/downloads/yocto-1.0/machines/qemu'></ulink>.
+             <ulink url='http://yoctoproject.org/downloads/yocto-0.9/qemu'></ulink>.
             Be sure to use the kernel and filesystem image that matches the architecture you want 
             to simulate.
         </para>
@@ -470,10 +455,10 @@

     Where:
         &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
-                i686, x86_64, ppc603e, mips, or armv5te.
+                i586, x86_64, ppc603e, mips, or armv5te.

         &lt;<emphasis>if</emphasis>&gt; is a string representing an embedded application binary interface.
-              Not all setup scripts include this string.
+                Not all setup scripts include this string.
         </literallayout>

         <para>
@@ -481,16 +466,17 @@
         </para>

         <literallayout class='monospaced'>
-     $ runqemu &lt;<emphasis>qemuarch</emphasis>&gt; &lt;<emphasis>kernel</emphasis>&gt; &lt;<emphasis>filesystem_image</emphasis>&gt;
+     $ poky-qemu &lt;<emphasis>qemuarch</emphasis>&gt; &lt;<emphasis>kernel</emphasis>&gt; &lt;<emphasis>image</emphasis>&gt; &lt;<emphasis>fstype</emphasis>&gt;

     Where:
         &lt;<emphasis>qemuarch</emphasis>&gt; is a string representing the target architecture: qemux86, qemux86-64, 
                    qemuppc, qemumips, or qemuarm.

-         &lt;<emphasis>kernel</emphasis>&gt; is the architecture-specific kernel.
+         &lt;<emphasis>kernel</emphasis>&gt;    is the architecture-specific kernel.

-         &lt;<emphasis>filesystem_image</emphasis>&gt; is the .ext3 filesystem image.
+         &lt;<emphasis>image</emphasis>&gt;     is the .ext3 filesystem image.

+         &lt;<emphasis>fstype</emphasis>&gt;    is the filesystem type.
         </literallayout>

         <para>
@@ -500,8 +486,8 @@
         </para>

         <literallayout class='monospaced'>
-     $ source /opt/poky/environment-setup-i686-poky-linux 
-     $ runqemu qemux86 zImage-2.6.34-qemux86-1.0.bin yocto-image-sdk-qemux86-1.0.rootfs.ext3
+     $ source /opt/poky/environment-setup-i586-poky-linux 
+     $ poky-qemu qemui586 zImage-2.6.34-qemux86-0.9 yocto-image-sdk-qemux86-0.9.rootfs.ext3 ext3
         </literallayout>

         <para>
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Bruce Ashfield	e08dc5aaae	linux-yocto: add crownbay BSP infrastructure Updating the meta SRCREV to grab this linux-yocto commit: meta: add crownbay BSP infrastructure Import the 2.6.34 crownbay infrastructure and update for the 2.6.37 kernel. This also brings in the feature/drm-emgd that the crownbay requires. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>	2011-02-26 14:30:34 -08:00
Beth Flanagan	9ae2e2ef95	Merge branch 'bernard' of ssh://git.pokylinux.org/poky into bernard-1.0	2011-02-26 14:29:21 -08:00
Saul Wold	55b58a5d4c	task-poky-lsb: libqtopenqgl4 should be for qemux86 and atom-pc only Signed-off-by: Saul Wold <sgw@linux.intel.com>	2011-02-26 10:50:15 -08:00