commit d8c66bc71e9a0303f1d300b9fa59c60dbfe10056
author Patrick Williams <patrick@stwcx.xyz> Mon Jun 20 12:57:21 2016 -0500
committer Patrick Williams <patrick@stwcx.xyz> Fri Jun 24 15:22:19 2016 -0500
tree 0d5c0ade4cc7ae9d8df42bcb3ad376d95398465e
parent 353dbdaaa97d78d064f0638221f57311f21f0bb3

Squashed 'yocto-poky/' changes from b1f23d1..8358e54

Upgrade subtree to Yocto-2.1.

6c1c013 build-appliance-image: Update to krogoth head revision
5f84d65 syslinux.bbclass: Remove APPEND from variable dependency
d9dd864 bitbake: toaster-tests: tests for build dashboard
1cf8f21 bitbake: toaster: add modal to select custom image for editing
a40a3e6 bitbake: toaster: add build dashboard buttons to edit/create custom images
e65c980 bitbake: toaster-tests: make helper click on input before entering text
484cbf8 bitbake: toaster-tests: add tests for new custom image page
437b728 bitbake: toaster: prevent exception when Project.release is null
cfc22d3 bitbake: toaster: only prevent duplicate custom image names within a project
3036413 bitbake: toaster: disable/enable "Add layer" button according to input's content
040dbf6 bitbake: toaster: fix sorting after hiding a column in build tables
1b11b79 bitbake: toaster: ensure ToasterTable headings are reset when order by changes
9855840 image.bbclass: The wrong name is being used for the debug filesystem
38c7e2d image_types: Ensure rootfs dependencies cover DEBUGFS
0c3eaa7 syslinux.bbclass: The AUTO_SYSLINUXMENU value needs to be boolean
9c8a049 perf: pass DESTDIR in EXTRA_OEMAKE
9de7324 buildtools-tarball: set INHIBIT_DEFAULT_DEPS
ef09105 xf86-video-omapfb: remove EXTRA_OECONF_armv7a
c2f7da2 base.bbclass: Introduce PACKAGECONFIG_CONFARGS variable
e1c6890 git: update to 2.7.4
98bf7de license.bbclass: do write_deploy_manifest in image postprocessing
519600c devtool: sdk-update: fix handling of UNINATIVE_CHECKSUM changes
c7980b6 bitbake: main: fix processing of BBEVENTLOG
ee25d0e toasterconf.json: Update for krogoth release
b8e5de2 toasterconf.json: Remove fido from supported configurations
c59771e toasterconf.json: Update for krogoth release
d0bce0b toasterconf.json: Remove fido from supported configurations
d25eea3 poky-tiny.conf: set PREFERRED_VERSION_linux-yocto-tiny to 4.4
9f970b6 dev-manual, profile-manual, ref-manual: Purging Oprofile stuff
1d93104 ref-manual: Added description for the testsdk.bbclass.
db47094 ref-manual: Updated the remove-libtool.bbclass description.
a16eeca ref-manual: Added gobject-introspection.bbclass description.
3e761b4 ref-manual: Added reference for npm.bbclass.
5e50157 ref-manual: Fixed typo in the nopackages.bbclass description
f7b68c7 ref-manual: Added description for bash-completion.bbclass
ece900a ref-manual: Added nopackages.bbclass description. Fixed stray typo.
9143e9e ref-manual: Added description for the INSTALL_TIMEZONE_FILE variable.
6391dbf ref-manual: Updated the PREFERRED_PROVIDER variable with a note.
6d86f7a ref-manual: Dropped references to the autotools_stage class
4d5ff5e ref-manual, dev-manual: Scrubbed boot-directdisk and bootimg classes
cd2aaaa ref-manual: Updated the uninative.bbclass description.
e975d26 documentation: Converted "meta-yocto" to "meta-poky"
84452ee bsp-guide: Updated yocto-bsp create example output.
e00a62c ref-manual: Added the migration section for 2.1
02db9e6 yocto-project-qs, ref-manual: Upgraded minimum Git requirement
989841f ref-manual: Added rootfs-postcommands class description.
d06b343 ref-manual: Updated the EXTRA_OEMAKE variable description.
ecb2eb6 dev-manual: Updated "Additional Implementation Details" section
004b939 bitbake: lib/bb/utils: add docstring for contains()
524d04c ca-certificates: support Toybox
ecaf12e oetest: make console output more verbose
4946ecf dhcp: CVE-2016-2774
c219c6d buildtools-tarball: fix perl being included when building with ipk
9fe7738 buildtools-tarball.bb: fix unexpected operator
ed07f43 lib/oeqa/selftest/base.py: Correct a reference to meta/lib/oeqa/selftest
8953d83 oe-selftest: Correct the usage examples
dee47ad devtool: sdk-update: reset git metadata on update
396e64d build-appliance-image: Load TUN at startup
55068b1 default-providers.inc: set openssl PREFERRED_PROVIDER to openssl
74ab080 bind: CVE-2016-2088
d488d78 rpm: Disable __sync_add_and_fetch_8 on nios2
9d2d1ae kernel: fitimage: Fix do_deploy taskhash mismatch
4693593 images: zero out the rootfs_extra_space in initramfs images
8beb671 ext-sdk-prepare.py: exclude do_rm_work from unexpected output; create unit test
0262bc5 bitbake: bitbake-user-manual: Updated the 'bitbake -h' output example.
890ccd3 bitbake: bitbake-user-manual: Updated "Conditional Metadata" section
20a0121 bitbake: bitbake-user-manual: Updated discussion about using "inherit"
9f374c4 bitbake: providers: Add PREFERRED_RPROVIDER support
4b8b110 bitbake: providers: We don't depend on previous build results
8e7282c bitbake: cooker/knotty: Prefix parse logs with filename being parsed
1131303 bitbake: cooker: pass exception to finishAsyncCommand
ffa2ca0 fs-perms.txt: fix ROOT_HOME's permission
fd66a38 Revert "fs-perms.txt: fix ROOT_HOME's permission"
9ec9557 buildstats: Fix tracebacks for early task failures
7f9d01e default-providers: Update to use PREFERRED_RPROVIDER
76f4bbc oeqa/selftest/sstatetests: fix no-op sstate test
6326812 buildhistory: don't alter SDK creation stamps
bb40b5e dhcp: Enable update-rc.d service
27e202f meta/classes/qemu.bbclass: set -cpu of ppce5500/ppce6500 to e500mc
7c5823a shadow: Disable syslog for more commands
60a8719 devtool: upgrade: handle recipes where source is not first entry in SRC_URI
8353557 devtool: update-recipe: handle where SRC_URI is appended to with +=
aab3c8d linux-yocto: make aufs4 optional
d75d2be linux-yocto: tiny and pin ctrl config updates
8547cbf linux-yocto/4.4: BXT enablement
ffad386 linux-yocto/4.1: mainline SPI backports
4ba33a3 linux-yocto/4.4: gpio-pca953x: fix the "drive" property cannot read/write
86571db devtool: don't copy .git when building the eSDK
83eac65 package.bbclass: improve permission handling
eeae2ac fs-perms.txt: fix ROOT_HOME's permission
1db3dc8 runqemu: let ramfs equal to cpio.gz
a8c8e81 gcc-common.inc: String format tweak for available tunes
a7c426a pbzip2: fix LIC_FILES_CHKSUM following 1.1.12 -> 1.1.13 upgrade
1229009 pbzip2: don't skip do_configure
1e4ee30 useradd_base.bbclass: remove flock option '-w'
cb45ef3 matchbox-keyboard: Hide desktop launcher
69e20ca npm.bbclass: Stop packagenames containing underscores from being generated
c3c55478 bind: CVE-2016-1285 CVE-2016-1286
c4387a8 image.bbclass: add DEB_{PRE, POST}PROCESS_COMMANDS to rootfs_command_variables list
967bc74 rootfs.py: apply ROOTFS_POSTINSTALL_COMMAND to all package formats
f7352ca wic: fix bug in handling fsoptions
b2f5de5 buildtools-tarball.bb: set TOOLCHAIN_NEED_CONFIGSITE_CACHE to null
a460b04 rpm: more verbose errors in rpmTempFile
a43991d rootfs-postcommands: handle broken links when writing manifest
2c81e17 socat: Use c_ispeed and c_ospeed based upon libc
5c8124d archiver: Improve debug output
e912c46 kbd: remove uclibc-stdarg.patch
965fd3c image.bbclass: use max() instead of indexing booleans
6d85874 linux-yocto-tiny: fix KBRANCH
440d949 sudo: fix pam config on systemd systems
3fd5a6d sysvinit: make lastb.1 an alternative
175263e lib/oe/lsb: sanitise the distro identifier
9262d2f package.bbclass: handle links in sorted order
29cf263 sanity: allow sftp and ssh mirrors
f503317 toaster.bbclass: improve package information collection
88f4178 rsync: remove upstream's rebuild logic
8d59d06 rsync: pass cached configure values through the right variable
384e41c rsync: don't install acinclude.m4
e80800e Revert "oeqa/selftest/wic: add test case for sparse images"
45c0763 Revert "wic/utils/partitionedfs.py: assemble .wic images as sparse files"
e0e5426 bitbake: runqueue: Improve 'mulitiple .bb files are due to be built' message
380004b archiver: Ensure sstate-inputdir directory is created
3ad70a5 linux-yocto-tiny: fix COMPATIBLE_MACHINE
0e59727 glib-2.0: Put glib-compile-schemas back in -utils
d27ca36 oeqa/runexported.py: Fix exported test
85dbd7b oeqa/selftest/sstatetests: split 32/64 build host from no-op action tests
57be6dd util-linux: take ownership of hwclock if installed
acc1f96 meta: remove redundant ac_cv_sizeof_off_t assignments
92759d8 meta/site: remove sizeof_off_t
5602f64 archiver: Fix ASSUME_PROVIDED issues
fab626c distrodata: Exclude DATETIME reference from sstate checksum
faaeaf9 build-appliance-image: Support for VirtualBox guest additions
778121a local.conf.sample: Make it possible to override EXTRA_IMAGE_FEATURES
f947c27 poky.conf: add Fedora 23 to supported distros
f33a110 maintainers.inc: remove adt-installer
83d4fab local.conf.sample: remove reference to adt
52cfdb6 bitbake: toaster: fixes for customimage package not found
dae4ffb bitbake: data_smart: Restrict expansion regexp to not include : characters
7e739ac bitbake: tests/utils.py: test origvalue in a callback matches what is expected
e1e459e bitbake: lib/bb/utils.py: Fix a bug in edit_metadata() that could corrupt vars
43150ab oeqa/selftest/wic: add test case for sparse images
29bc2f7 wic/utils/partitionedfs.py: assemble .wic images as sparse files
7fdb061 image-vm.bbclass/image_types.bbclass: IMAGE_NAME -> IMAGE_LINK_NAME
04e1978 image_types.bbclass: fix elf
513ea49 image_types.bbclass: set nodesize for btrfs
bad434b libxml2: fix AM_PATH_XML2
9fe3d01 useradd_base.bbclass: prevent variable expansion in $opts
fb8e5f9 extrausers.bbclass: drop retry count for perform_user/group* calls
f737af4 build-perf-test: add eSDK installed size to metrics
50f5ca3 rpm: brace expansion is a bashism
66ecbd3 openssl.inc: minor packaging cleanup
e38ec0c systemd-systemctl-native: fix unit detection
4019058 apr-util: fix path in rules.mk for nativesdk
bdf453f bdwgc: installed-vs-shipped for nativesdk
12ca8df libsolv: fix installed-vs-shipped for nativesdk
c88c894 desktop-file-utils-native: disable emacs
d4f6c0e toaster: add DL_DIR and SSTATE_DIR to oe toasterconf
69b3f87 toaster.bbclass: strip task from the target
aa45c75 x11-common: Add PACKAGECONFIG for screen blanking
d366a33 opkg-utils: re-do find/ls code to not fail on filenames with spaces
5e360ca image-live.bbclass: fix iso + efi only
f5adb23 Add missing runtime dependency to python-pygobject
0720425 devtool: Create unlocked-sigs.inc containing items in the workspace
64cca7e sstatesig.py: Add a method to "unlock" recipes
1cb99dd populate_sdk_ext.bbclass: Enable locked sigs errors
2431ed7 sstatesig.py: Improve the SIGGEN_LOCKEDSIGS_TASKSIG_CHECK message
7e90280 sstatesig.py: Split single locked sigs check into multiple checks
7ce800c toasterconf.json: Set default distro to nodistro
1b7b548 dev-manual: Updated poky-floating-revisions file snippit example.
8d9e233 dev-manual: set correct task name for do_kernel_configme
6971029 poky-floating-revisions: Fix typo
14e2b90 toasterconf.json: Add DL_DIR and SSTATE_DIR to poky toasterconf
296dfbc build-appliance-image: Update to master head revision
00c4c9b poky: Convetion is 2.1, not 2.1.0
8cd1dec build-appliance-image: Update to master head revision
ecd58bb poky.conf: Bump version for 2.1.0 krogoth release
e955b5d bitbake: Update version to 1.30.0
4fd14e3 build-appliance-image: Update to master head revision
133224f documentation: Fixed references using the DISTRO_NAME variable
3831ca0 documentation: Updated release date in manual history tables.
b590fab dev-manual, ref-manual, sdk-manual: Removing oprofile references.
d2084cc Makefile: Removed adt-manual support
2677098 mega-manual: Removed the adt title .PNG file.
d9b4c80 README: Updated to remove the ADT manual and add the SDK manual.
9796cbb mega-manual.sed: Removed adt-manual processing
aa4b72b yocto-project-qs: Updated the minnowboard example.
f2505af poky.ent: Added lower-case distro name variable.
ee42a9b kernel-dev: Applied review comments to "Adding Recipe-Space Kernel Features"
d57fe7c ref-manual: Updated the PREFERRED_VERSION variable description.
53bade8 dev-manual: Added new section describing hardware and non-hardware config
763ae4e ref-manual: Updated verbiage on proxy handling
a1295ed ref-manual: Updated PREFERRED_VERSION variable description
879eec2 ref-manual: Updated debugging tips and tricks
23dbf81 kernel-dev: Added new "Adding Recipe-Space Kernel Features" section.
f30bfe9 kernel-dev: Updated the "Kernel Metadata Location" section.
53729bc sdk-manual: Removed three sections of writer notes.
9f0c571 sdk-manual: Applied review edits.
d4bdafa sdk-manual: Added sections in Appendix B.
d94fa00 dev-manual, profile-manual: Removed oprofile section and link
4f3dfa8 bitbake: bitbake: update LICENSE file with QUnit details
013984d bitbake: tests: browser Add test to run the js unit tests
7609888 bitbake: toaster: views jsunittest Add MACHINE and an extra layer to test project
fbc2c5d bitbake: toaster: tests Set MACHINE for the test projects
cb6b4eb bitbake: toaster: Add quint to project so that it can be used offline
18cb7fe bitbake: toaster: add rev dep column to image detail pages
7a309d9 bitbake: buildinfohelper: work around unicode exceptions
860cba8 bitbake: toasterui: update build in internal state
acb9407 bitbake: buildinfohelper: fix KeyError
52c8740 bitbake: toaster: get bitbake location from BBBASEDIR
f5d3ef6 bitbake: toaster: export BBBASEDIR variable
71ff9b9 bitbake: toaster: update projectconf.html for DL_DIR and SSTATE_DIR
705d44f bitbake: toaster: update view to support DL_DIR and SSTATE_DIR
4aafcae bitbake: toaster: use empty token
5ce4665 bitbake: toaster: runbuilds Clean up runbuilds
55b6fab bitbake: toaster: runbuilds Make runbuilds aware of the build CANCELLED state
f4cee88 bitbake: toaster: models Exclude the CANCELLED builds from get_number_of_builds
296d373 bitbake: toaster: mrb_section template Add build cancel button
f1b49dc bitbake: toaster: tables BuildsTable exclude cancelled builds
22242ae bitbake: buildinfohelper: Add handler for cancelling a build
9dcb9cb bitbake: toaster: bldcontrol models Add a cancelling state the BuildRequest
dfa8510 bitbake: toaster: models Add cancelled state to build outcome
5f862bb bitbake: toaster: update BuildEnvironmentController and BitbakeController
0db62c5 bitbake: toaster: libtoaster Update implementation of startABuild and cancelABuild
afab95c bitbake: toaster: xhr Update the implementation of the build cancellation request
eead032 bitbake: toaster: Move xhr calls for starting and stopping builds
f5aa970 bitbake: toaster: bldcontrol Add forceShutDown function to BitbakeController
d6992a8 bitbake: toasterui: shutdown on BuildCompleted event
c4ae028 bitbake: toaster: use bash explicitly
4adddfd bitbake: toaster: fix jethro build
b1a919a bitbake: toaster: update conf/local.conf
590a815 bitbake: toaster: stop bitbake server after the build
a8f6001 bitbake: toaster: add new parameter to _shellcmd
a43a16b bitbake: toaster: reimplement triggerBuild
ab18c20 bitbake: toaster: modified setLayers API
22fba9b bitbake: toaster: add brbe parameter to triggerBuild
829a0bd bitbake: toaster: remove release API
7068e8a bitbake: toaster: remove startBBServer API
9d4c62d bitbake: toasterui: fix brbe reporting
5bcce68 bitbake: buildinfohelper: improve handling of providermap
61b6b98 bitbake: uievent: improve BBUIEventQueue code
0b0d754 bitbake: toasterui: add brbe parameter to buildinfohelper
94ac3f0 bitbake: toaster: set BITBAKE_UI environment variable
e23a23b bitbake: toaster: get rid of noui option
f77baec bitbake: toaster: don't start bitbake server
4127fef image_types: use compress framework to produce checksums for images
60786b8 runqemu-gen-tapdevs: Add note about NetworkManager & tap devices
634aeed libtool: fix contaminated path to lt_truncate_bin
298d875 create-pull-request: fix for newer git
4faeff9 wget: fix build when len(TMPDIR) == 410
b667f4d sanity.bbclass: fix a hardcode in check_path_length()
94b3583 grub: remove unused 0001-Fix-build-with-glibc-2.20.patch
ef163ab glibc: remove unused CVE patches
b050ab2 clutter-gst-3.0: remove unused enable-tests.patch
064ebd5 cmake: remove unused dont-run-cross-binaries.patch
a71db4c tcl: remove unused fix-configure.patch
476eeea rpm: remove two unused patch
3d56864 ffmpeg, gstreamer1.0-libav: add textrel INSANE_SKIPs
8cc10a9 ffmpeg: Make configure options explicit
45c1944 bzip2: set correct soname
cbe33ec useradd.bbclass: remove user/group created by the package in clean* task
c115740 bitbake: fetch2/git.py: remove .indirectiondir workaround
4f07c22 bitbake: persist_data: Return str instead of unicode for sqlite3 text queries
d8f1f42 scripts/oe-selftest: avoid the creation of coverage file when coverage not installed
6e5e225 scripts/oe-selftest: remove coverage file if any coverage option is given
5edfec4 scripts/oe-selftest: remove unneeded coverage warning
8109e93 patch.bbclass: remove useless path assignment
7963613 gstreamer: remove now-redundant expansion in do_split_packages
37f4f5b package: do_split_packages: expand variables in extra_depends
2ed2089 xf86-video-intel: Add patch to fix some poor image quality
c1436b3 sanity: Increase minimum git version to 1.8.3.1
672545b scripts/oe-buildenv-internal: Fix regression in BB_ENV_EXTRAWHITE setting
f7fed7c license.bbclass: fix warnings when run in unprivileged "container" env
43071a0 externalsrc: avoid race in temporary git index file
f4f1d20 scripts/lib/bsp/help.py: Typo in help for yocto-bsp create
1bd2c8e bdwgc: use github repo for source location
0e6743b xf86-video-intel: Add patch to allow UXA to build
21e31c2 package_manager.py: better error handling in opkg's package listing
f2d5e20 systemd: make systemd-serialgetty optional
e699404 ncurses: reorder PACKAGES
f94ad4d bluez5.inc: remove obsolete workaround
a0cd8c0 buildtools-tarball: Add texinfo (for makeinfo)
9877795 cogl: fix G-I .typelib installation
b13184c classes/buildhistory: fix grammar in comments
e5c0a9f classes/buildhistory: fix filtering of depends-nokernel.dot
4d364f2 classes/buildhistory: optimise getting package size list
af5f423 bitbake: siggen: Ensure tainted stamps are accounted for with writing custom stamps
47e9e12 bitbake: siggen: Fix nostamp taint handling
8033627 bitbake: siggen: Add checksum recalculation/checking code
3e1b5e0 bitbake: siggen: Fix check calculation problem with file_checksums
39b637c bitbake: siggen: Drop misleading duplicate method
2c722e2 bitbake: tests/fetch.py: Improve unit tests for trusted network check
cf6d12d bitbake: fetch2: BB_ALLOWED_NETWORKS should not care about port numbers
158575c bitbake: toaster: orm better detect requires during CustomImageRecipe generation
c634473 bitbake: toaster: Correct typo on build form help text
c9ad1e6 bitbake: toaster: buildinfohelper Add additional metadata to the built layer
072a0b3 poky: Exclude DATE from DISTRO/SDK_VERSION checksums
f3c029f build-appliance-image: Exclude DDATETIME from task signature
7833eb4 image-vm: Exclude DISK_SIGNATURE_GENERATED from task signature
85ff4ff populate_sdk_ext: Exclude BBTASKDEPDATA from task signature
66412ab opkg-utils: opkg-build exit when fail to list files.
6b8f8a4 kernel-yocto: enforce SRC_URI specified branch
6ebd43c linux-yocto/4.4: UVC: Add support for R200 depth camera
6d2299f linux-yocto/4.4: fix PAT for 32bit x86
5559301 Revert "linux-yocto: Work around PAT issue on qemux86"
686c74f linux-yocto-dev: bump to v4.6-rcX
b3ba813 linux-yocto/4.1: ahci: backport AHCI runtime PM
8f7bbea linux-yocto/4.4: gpio-pca953x: add PCAL9535 interrupt support
4a50c05 linux-yocto/4.1: telemetry and dmaengine backports
31a10cb wic/isoimage-isohybrid.py: change cpio generated uid&gid to root
5cabf3b wic/isoimage-isohybrid.py: use glob to find initramfs location
5c60c36 bluez5: add ptest support
fc8b24d oe/patch: print cleaner error message when patch fails to apply
bf14014 oe/patch: more detailed error reporting
a2bf9e3 insane.bbclass: avoid false positives on library location
1f2f43c grub-efi.bbclass: use GRUB_ROOT rather than APPEND for root device
bf58526 bitbake.conf: Add BB_WORKERCONTEXT to HASHBASE_WHITELIST
1c1e851 gdb-cross-canadian: use PACKAGECONFIG for python and readline
370a50a base: Fixup PACKAGECONFIG incorrect mappings
dea3423 classes/packagegroup: Refactor code to be simpler
5defbcd default-distrovars.inc: remove libassuan from LGPLv2_WHITELIST_GPL-3.0
58d8123 libassuan: use package specific licensing
1f2a01b init-install-efi.sh: remove all root=foo from grub.cfg
3ce7d8c init-install.sh: fix disk_size
46eed0a ltp: fix test_proc_kill hanging
207ee90 ltp: add periodic output for memcg stress test
feafad1 epiphany: Depend on intltool-native for configure
2510239 image: Fix debugfs image type recursion loop
7dcb4c4 bitbake: toaster: tests Migrate landing page tests to Selenium
5b848fa bitbake: toaster: tests Migrate all projects page tests to Selenium
f2a38ea bitbake: toaster: tests Migrate project builds page tests to Selenium
961cd90 bitbake: toaster: tests Migrate all builds page and project page tests to Selenium
f859a3d bitbake: toaster: tests Migrate to Selenium for UI tests
965c72c yocto-bsp: Set correct default branches and branches base for i386, qemu and x86_64 archs
d110eba selftest/signing: Use packagedata to obtain PR value for signing test
34f11b5 lib/oe/packagedata: Add import os
0012b90 base.bbclass: avoid duplicate call to d.getVar('LICENSE', True)
efe73cb base.bbclass: drop obsolete HOSTTOOLS_WHITELIST_GPL-3.0
5293b83 man: use BUILD_CC and target include files for configure
5121705 scripts, lib: Don't limit traceback lengths to arbitrary values
3168134 bitbake: bitbake: Don't limit traceback lengths to arbitrary values
88ea0b9 image-vm.bbclass: remove invalid code
4d1df2c image-live.bbclass/image-vm.bbclass: remove duplicated code
d6d7526 bootimg.bbclass: merge it into image-live.bbclass
723fa56 boot-directdisk.bbclass: merge it into image-vm.bbclass
9e588481 man: fix several annoying compile/build warnings
aa13b97 image.bbclass: Make unneeded packages for a read-only rootfs configurable
4dde12f relocate_sdk: additional error checks
22bd875 systemd: fix build with gcrypt PACKAGECONFIG disabled
4b77909 devtool: modify: call shutdown on tinfoil when done
43da712 toolchain-shar-extract.sh: ensure all_proxy is allowed through
2aec71e oe-publish-sdk: exclude sstate-cache if publishing minimal SDK
8ef7016 oe-publish-sdk: prevent specifying a directory for the SDK argument
591b97c classes/populate_sdk_ext: support setting vars from environment at build time
c37d542 scripts, lib: Don't limit traceback lengths to arbitrary values
8049f25 pyton-numpy: Add definition of off_t size
b75505e image-live.bbclass: DEPENDS on syslinux
3ece012 ldconfig-native: Fix ELF flags on 64-bit binaries
d492aec recipes-support/rng-tools: Change runlevel start from S to 2, 3, 4, 5.
ab5c62e oeqa/runtime/parselogs.py: Add systemd unit circular dependencies errors.
9be3fb2 systemd-serialgetty: allow baud rate overriding
cf6788c psmisc: Remove including sys/user.h and __WORDSIZE
ede11b6 selftest: Added testcase decorator to tests
ccfe48c linux-yocto: add overlayfs feature
6ae0224 linux-yocto/4.4: broxton and usb type-c backports
e1ae3ee linux-yocto/4.4: drm/i915/skl: Fix DMC load on Skylake J0 and K0
0a1d621 linux-yocto/4.1: Intel Broxton: pwm backports
6ce8802 linux-yocto/4.1: Apollo Lake/Broxton mmc backports
a256628 linux-yocto/4.1: i2c: designware: Backport i2c patches
fbd209d linux-yocto/4.1: device property backports
ccf1b33 linux-yocto/qemuarm64: enable 32 bit compatibility
dacf9f2 linux-yocto/4.1: SMBus/iTCO backports
ab6fd48 default-distrovars.inc: remove gnutls + libtasn1 from LGPLv2_WHITELIST_GPL-3.0
2123a7e sanity.bbclass: Use pythonexception to raise real exceptions without backtraces
6af88d8 sanity: Require bitbake 1.29.1
1b2df6e uninative: Switch md5sum -> sha256
f719386 bitbake: cookerdata.py: remove slash in the end
e26087f bitbake: Bump version to 1.29.1
d73da22 bitbake: build/utils: Allow python functions to execute with real exception handling
672c07d bitbake: fetch2: Ensure that incorrect checksumed files are always renamed
2554be4 bitbake: cooker: fix CookerParser.shutdown()
53b5dc0 gcc: Fix musl ldso name for mips64
dd31bca selftest/buildoptions.py: use INHERIT +=
71db079 archiver.bbclass: addtask do_deploy_archives_setscene
1ca71e5 bitbake: cooker: Ensure bbappend order is deterministic
292c3e8 bitbake: checksum: In FileChecksumCache don't follow directory symlinks
326fc29 gcc-5.3/gcc-4.9: -fdebug-prefix-map support to remap relative path
9e20f94 ptest-runner_2.0.bb: Update recipe to point git.yoctoproject.org repo.
437841c man: fix src/Makefile to work with parallel make
abb5b46 oeqa/selftest/bbtests: Test bbappend order
ddbeb56 bitbake: cookerdata: Improve handling of ParseError
6dff639 gcc: Backport fixes for musl ssp configuration
ab20659 siteinfo: Fix musl 64bit targets
cd16b65 musl: Update to tip
0883aff buildhistory.bbclass: create image directory when needed
c093f7c runqemu: fix for iso
f1f9f89 init-live.sh: fix overlay fs
4e7eaed init-live.sh: fix ROOT_MOUNT
1622077 no-static-libs.inc: build static libusb1-native
b3e4a31 sstatesig: Ensure we keep native depends for allarch recipes
528a890 oe-selftest: generate .env only in test_image_env
21823cb build-appliance-image: Update to master head revision
7d251f7 build-appliance-image: Fix permissions
60656d0 bitbake: fetch2/wget.py: _check_latest_version_by_dir fix prefix detection
45ee2b1 bitbake: fetch2/wget.py: _check_latest_version_by_dir use group names
55cd35b conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used
e2b919c externalsrc: remove nostamp from do_configure
bbfc210 externalsrc: do not use do_configure[nostamp] for git srctrees
9ee403b archiver.bbclass: Just archive gcc-source for all gcc recipes
37683ef oeqa/utils/ftools: improve remove_from_file algorithm
3a934a8 scripts:/oe-selftest: Use timestamp instead of test names in coverage data file
71304d8 xcursor-transparent-theme: upgrade to latest git revision
7c5343a gdb: Fix build on mips64/musl
856be1f libunwind: Fix build on mips/mips64 for musl targets
dd61341 toolchain-shar-extract.sh: check the length for target_sdk_dir
c3c793b relocate_sdk: fixed .gccrelocprefix section handling
cc97d57 glib-2.0: Fix packaging
cef8bc9 gio-module-cache: Add class for Gio modules
0cda9d8 glib-2.0: Install gio-querymodules in main package
9ac1b6f oe-git-proxy: support username / password in http proxy
a15541d oe-git-proxy: also check all_proxy and http_proxy env variables
92b2bc5 wic: Update after task ordering changes
d6cb46c image.bbclass: run wicenv task only for wic images
5cb7705 wic: fix type of no-table option
1209eb2 matchbox-desktop: Do not close desktop on alt-F4
0361676 rootfs-postcommands: don't write manifest when IMAGE_MANIFEST empty
abd5b24 bitbake.conf: rename 'gobject-introspection-data' machine feature to 'qemu-usermode'
f81065f selftest/devtool: Update after make PROVIDER changes
25a04ee make, remake: make them properly exclude each other
f3a92ff kernel.bbclass: consider .csp firmware files
0569b69 tzdata: update to 2016c
a7e726a tzcode: update to 2016c
201d9d3 icecc.bbclass: replace icc with icecc
da00f6c icecc.bbclass: expand package arch
3f1702c icecc.bbclass: add icc_is_allarch inherit check
39170fe classes/sanity: use proper multi-line string literals
33a6135 oe-buildenv-internal: simplify derivation of BB_ENV_EXTRAWHITE
c6ab828 u-boot.inc: Add sub-dir support for SPL_BINARY
ddedab4 quilt: run ptest as normal user
afa4d5e site: Cache config vars for ccache
04344eb gdb-cross: use PACKAGECONFIG for python and readline
5005cab add !meta-poky to .gitignore file
1dd9348 scripts/lib/bsp/help.py: Add missing options to yocto-bsp help and usage
54eca75 poky-sanity.bbclass: update conf/templateconf.cfg for existing installations
2b992f3 site.conf.sample: fix reference to oe-git-proxy script
af63b49 conf-notes: remove reference to adt-installer
1d219ce linux-yocto: Update SRCREV for genericx86* for 4.4
8d4f43e linux-yocto: Update SRCREV for genericx86* for 4.1
84d5924 bitbake: fetch2: Handle lockfiles for file:// urls redirected to mirrors
b036afb bitbake: toaster: get all dependents for pkg for removal
9bf98a9 bitbake: toaster: new customise package-remove modal dlg
d5a419d bitbake: toaster: show full list of dependents to remove
fda94f4 bitbake: bitbake: fetch2/gitsm: Fix fetch when the repository contains nested submodules
1341c17 pseudo: backport a patch to fix xattr removal
07f0af3 uninative: don't try to relocate static binaries
c3c0d0a lib/oe/qa: add method to check if static or dynamic linked
10b6037 uninative: ensure patchelf errors are visible
86d7e44 libmad: remove use of obsolete _thumb over-ride
e7395c8 perf: package python modules into perf-python
b47225f perf: fix python scripts QA errors
ea8b914 linux-yocto/4.1: MFD backports
b6563a1 linux-yocto/4.1: device property : Backport device property patches
46baceb linux-yocto: ktypes/standard: Add tmpfs-posix-acl feature
bdf6b20 linux-firmware: Break out some additional firmware
6d8141f linux-firmware: Clean-up and sync license data
cea2a21 linux-firmware: Collapse iwlwifi firmware blobs for 7260 and 7265
3b3fe1d linux-firmware: Update to latest HEAD
d7cf2c3 archiver.bbclass: Fix tar name for git repositories
2cb4cb7 archiver.bbclass: Fix gcc-source corner case
c29eea0 archiver.bbclass: Fix use of ARCHIVER_WORKDIR and ARCHIVER_OUTDIR
8b7ee6e archiver.bbclass: Don't expand python functions in dumpdata
bc100b3 bind: /var/cache/bind
04d883c sysvinit: downgrade ALTERNATIVE_PRIORITY[mountpoint]
688d9a6 util-linux: split out util-linux-mountpoint
85ff75d gconf: fix buildpaths QA issue
7f7c9ab python-pygobject: use Python 2 instead of Python 3
e33124f sanity.bbclass: check host tool dependencies on change in NATIVELSBSTRING
4fe64d7 libunwind: Fix build with fstack-protector on musl
4aa08b8 ltp: Fix build on x86/musl
959b7f2 package.bbclass: Treat .node files same as .so when checking what to strip
e0bc781 bootimg.bbclass: only inherit syslinux when pcbios
1b1de89 grub-efi.bbclass: make it can build vm and live together
4ebaeb2 bootimg.bbclass: fix settings for grub-efi.bbclass
af1f77a pixz: Fix build on big-endian/musl systems
421289c sanity.bbclass cleanup
93e411e matchbox-wm: Update to fix XChangeProperty datatype issue
c843022 matchbox-panel-2: Fix Home-button icon load issue
01f6818 gstreamer1.0: fix introspection support also for git recipes
171adb1 gstreamer1.0-plugins-bad: fix incorrect handling of Cflags in gstreamer-gl.pc file
6462d08 x86-base.inc: suggest the latest kernel
c5c9ed6 at: fix configure option with/without-selinux
9b2b1f0 no-static-libs: just like target and native, nativesk-libcap doesn't like unrecognised options
bf90d0c linux-firmware: package firmware for Marvell 88W8688
cd17ab0 tune-arm926ejs: Handle missing thumb suffix
5b70c7e nativesdk-coreutils: a lot of warnings fixed
b47c53b runqemu-internal: split the code into functions
fae732f runqemu-internal: cleanup unsed code
e469bb7 runqemu: simplify checking for iso and ramfs
3610329 runqemu: add support for qcow2 and vdi
d85ca4a runqemu: remove ISO and RAMFS from help text
58bc854 runqemu: simplify the checking for vm images
6716eb2 runqemu: fix ROOTFS for vmdk
258cfa8 python(3): Disable tkinter
5988b5c selftest/signing.py: RPM_GPG_PASSPHRASE_FILE -> RPM_GPG_PASSPHRASE
3e5c5fe gpg_sign.py: get rid of pexpect
05d7e0d rpm: check _gpg_passphrase before ask for input
13a31b1 oe-publish-sdk: fix remote publishing
9926425 oe-publish-sdk: improve help output slightly
905286c oe-publish-sdk: drop SDK installer file from published output
0523378 devtool: add: create git repository if URL specified as positional argument
11c1d30 devtool: add: delete externalsrc files on npm recipe do_install
552a68a devtool: configure-help: fix error if do_configure not already run
eab3f06 bitbake.conf: whitelist proxy variables in config hash
58d2e56 classes/populate_sdk_ext: parse metadata on minimal SDK install
0684572 devtool: sdk-install: add option to allow building from source
50addfb classes/distutils*: don't hide logs when setup script fails
0ec30c7 classes/packagegroup: drop complementary -ptest if ptest not in DISTRO_FEATURES
d96ea29 classes/packagegroup: fix dbg/dev/ptest complementary packages
b58e5b1 bitbake: bitbake: xmlrpc: set single use mode differently
2df514b sdk-manual: Added note for running remote apps with SSH port forw enabled.
12f5c25 poky.ent: Added code name for 2.1 release to the variable
64241e0 sdk-manual: Applied more review edits to the manual per Eggleton.
b44d9e5 ref-manual: Created distrodata and checkpkg tasks, updated distrodata class
54050ff sdk-manual: Applied 2nd round of review edits.
6db8cbc sdk-manual: Applied review edits to the manual.
922eaeb sdk-manual: Updated the SDK devtool modify flow diagram.
2bbf77a dev-manual: Fixed a grammar error
286b76f sdk-manual, mega-manual: Updated the SDK devtool modify diagram
c3946bc dev-manual, profile-manual, ref-manual: Updates to remove meta-toolchain
7233e35 sdk-manual: Edits to add extensible SDK configuration sections.
b31bf7c ref-manual, sdk-manual: Changed section heading.
670735e ref-manual: Added some SDK manual support to introduction
266742b profile-manual: Updated screen output for oe-init-build-env
0654224 kernel-dev: Changed a link from an example to in-text.
19e3648 dev-manual: Edits from a 2.1 read-through.
a389684 poky.ent: Fixed a typo in one of the variables "ftar" to "tar"
b5d3065 poky.ent, bsp-guide: Removed eMenlow example and updated 2.1 variables
884b528 yocto-project-qs: Performed a read-through edit.
4b42385 poky.ent: Updated copyright year and version variables.
ae48b1f mega-manual: Added two new sections for the sdk manual
815d686 sdk-manual: Added some intro stuff about the SDK
4c5157f ref-manual: Resolving a conflict
4306f7f sdk-manual, mega-manual: Added new figure for Eclipse flow.
0bb6e48 sdk-manual: WIP on the book.
5a64701 sdk-manual, mega-manual, Makefile: Added new figures
32629e0 Makefile: Resolving a conflict
af40e9a sdk-manual: Added a new figure for installed extensible sdk directory.
62477889 sdk-manual: Applied some "red" text formatting to indicate notes
7ab8afa Makefile: Added the ".png" part to a figure I forgot.
fc43555 sdk-manual: Added a red-text "role" to the style sheet.
d07100d sdk-manual: Added new section detailing installed SDK directory.
b750729 sdk-manual-customization: Fixed XSL Appendix numbering parameter
ad7a994 Makefile: Updated the figure list for the mega-manual.
890f721 sdk-manual: WIP - Various small edits as WIP
f15f96c sdk-manual: New content for outline purposes.
4643b04 sdk-manual: Updated with two new appendices for new files.
d05566b sdk-manual: Added sdk-environment.png diagram.
0936eed sdk-manual: Added two appendix files to SDK Manual.
6996a1c Makefile: Added sdk-environment.png to figure list for SDK Manual
6cdb356 toaster-manual: Edits to a previous patch.
77594c0 mega-manual, Makefile: Added support for three new toaster figures.
00fe95d toaster-manual: Explain the local release
d06c7b8 documentation: remove all references to Hob
be8af37 ref-manual: Updated COREBASE_FILES variable.
5c7e5aa bitbake: bitbake-user-manual: include/require checks current directory
7ec8f28 bitbake: bitbake-user-manual: Updated the "inherit Directive" section.
75cba54 bitbake: bitbake-user-manual: Updated the copyright year to 2016
2918b50 bitbake: toasterui: remove ParseStarted from the event list
ab2abd4 bitbake: toasterui: Remove the excessive exception logging
d8137be bitbake: cache: Make BB_DONT_CACHE variable external
1d1aaa2 bitbake: toaster: orm generate CustomImageRecipe contents try secondary path
5c49230 bitbake: toaster: localhostbecontroller put generated layer in the builddir
b60c994 bitbake: toaster: localhostbecontroller Allow file:/// uri type for git repo
3025092 bitbake: toaster: orm Add a constant for the CustomImageRecipe's layer name
3df6551 bitbake: toaster: localhostbecontroller Don't clear out toaster custom layer dir
2f2f784 parselogs: add new whitelist entries to address 4.4.3 issues
8037ba4 bitbake: bb/tests/fetch: Update cups url
dab6d59 oe-buildenv-internal: Correct the sed expression which updates $PATH
068afc5 tzdata: update to 2016b
e140272 tzcode: update to 2016b
c0b3667 ffmpeg: Remove RSUGGEST=mplayer
e528a0a lttng-tools: Remove lttng-ust from PACKAGECONFIG for musl
42b9bdf packagegroup: Disable packages not available on musl
f148a2e world-broken: Add packages broken on musl
624ca6a siteinfo: Move apr configure cache to common-linux
90234f1 parselogs: add new whitelist entries to address 4.4.3 issues
13a2a3f u-boot: Upgrade to 2016.03 release
ecf3396 grub: add -Wno-error=trampolines to native CFLAGS
07515b0 dhcpd: create dhcpd user for dhcp dameon
b9ad80d valgrind: fix buildpath QA issue
7985006 gcc-5.3/gcc-4.9:Reuse -fdebug-prefix-map to replace -ffile-prefix-map
2faa718 gcc-5.3/gcc-4.9:replace build path with target path in __FILE__
76f10fd oe-buildenv-internal: Some clean up
4d1efc3 oe-buildenv-internal: Add variables individually to BB_ENV_EXTRAWHITE
39ac332 oe-buildenv-internal: Add paths to $PATH individually
dd5f2f7 oe-init-build-env*: Make them actually return failures
ea28de6 oe-init-build-env*: Remove unnecessary differences between the scripts
51aa00f oe-init-build-env*: Update/correct comment about specifying arguments
16fb9b8 oe-init-build-env*: Allow $OEROOT to be predefined
3173979 bluez5: allow D-Bus to spawn obexd in systems without systemd
10ef68f oeqa: remove RPM 4 self test
d915965 lib/package_manager: remove RPM4 support code
03fce73 smartpm: remove rpm4 patch
1e9de52 rpm: remove RPM 4
a7dd04d grub: fix documentation rebuilds
ee4f61b oe-selftest: Fixed --list-tests-by tag option
068e898 gcc-runtime.inc: set LICENSE for all gcc-runtime packages
788dfdd ParaTypeFFL-1.3: Add license file
62ddde6 externalsrc: use shared stamp directory if B=S
1969332 rpm: fix error when 'lua' is enabled
a31301e matchbox-keyboard: Update to latest HEAD to fix 64bit issue
40a55f1 oeqa/selftest/buildoptions: test read-only-rootfs
f64fdd2 oeqa/selftest/sstatetests: verify more variables don't impact the hash
ac347da gobject-introspection.bbclass: wrap comments at 80 columns
ae63b88 qemuarm64.conf: don't clear MACHINE_FEATURES
cad415d sanity.bbclass: allow customizing config file update error messages
96a5cb4 sanity.bbclass: fix success message when config file was updated
805aca8 sanity.bbclass: expand error messages for version checks
7d6801c lighttpd: fix /usr/lib/mod_cgi.so: undefined symbol: chunkqueue_written
5f7b9f0 valgrind: Disable nios2 support
aaaccc4 systemtap: Disable nios2 support
5857b20 lttng-modules: Add nios2 support
26248cd kexec: Disable on nios2
3e4d99b packagegroup-core-sdk: Disable sanitizers for nios2
797ffc8 bdgwc: Backport nios2 support
238e2c1 libatomic-ops: Backport nios2 support
7e83af3 selftest/buildoptions: Renamed one test case
0d9f515 python-numpy: Fix build on musl
e1f3f4c socat: Access c_ispeed and c_ospeed via APIs
bb4e6e0 watchdog: Disable nfs on musl targets
f00cca8 bdwgc: Check for getcontext() API during configure
51464e7 devtool: change config symlink name to .config.new
8c0148f systemd: Fix and expand ptests
427e369 oeqa/utils/testexport.py: add functionality for exporting binaries
2191623 init-live : make it easier to add custom boot targets
57a525c useradd_base.bbclass: replace retry logic with flock
5d06f00 image.bbclass: track ROOTFS_POSTUNINSTALL_COMMAND in do_rootfs vardeps
6129d86 eudev: split eudev-hwdb from eudev
9aa27fe openssl: don't move libcrypto to base_libdir
370419e xcb-util-image: Fix build with clang
8727975 musl: Update to get mips64 port
4653fdd dhcp: enable gentle shutdown
e382d96 coreutils: fix reporting 'unknown' by `uname -p' and `uname -i'
3b8cd1d ncurses_6: Improve installation
9cc65ed Revert "selftest: Added MACHINE = "qemux86" to tests that use runqemu"
3c5ee61 busybox: Drop -r passthrough patch
2c666af linux-yocto/4.1: usb: add usb_otg_caps to usb_gadget structure.
8dc9162 linux-yocto/4.1: Intel Broxton and Sunrisepoint-H: pinctrl and drm
99ad4c9 linux-yocto/4.1: powercap/RAPL: Backport powercap/RAPL
c4f544e linux-yocto/4.1: Thermal: Enable Broxton SoC thermal reporting device
123c2c6 linux-yocto/4.1: usb backports for Apollo Lake/Broxton
600b700 recipetool: create: don't create extra files directory unconditionally
8debfea local.conf.sample: Disable prelink by default
efa0881 oeqa/selftest/recipetool: Fix test_recipetool_create_simple
c9d269c Revert "packagegroup-core-x11-sato: add python-pygobject and gtk+3"
d24a39a oeqa/recipetool: Fix syntax error
55a1e52 oeqa/recipetool: Improve debugging output by adding dirlist
637b3c8 uninative: Add a fix for icu-native to use the correct ABI
9dbfbe9 scripts/oe-selftest: Add short names to most common options
681a452 gcc: Fix the license on GNU OpenMP
15c5b2a Revert "gcc: Fix the license on GNU OpenMP"
d5cdb48 perl: fix missing dependency for perl-misc
0eb52b9 classes/buildhistory: record a few more variables for extensible SDK
cbb4c5b package-deb: Ignore circular dependencies
fcc7ff0 package_deb: Fix python runtime error
9155b24 python-numpy: fix buildpaths QA issue
9e69963 python: move ast module into python-core
1a35166 xserver: require sufficiently new libdrm
36bf666 package_manager.py: Fix race condition in OpkgIndexer.write_index()
35be679 scripts/oe-selftest: Add search expression matching to run/list options
4489ef1 glib-2.0: relocate the GIO module directory for native builds
cf3402e image-buildinfo.bbclass: fix performance problems
e2fe28c linux-yocto/4.4: gpio-pca953x: add "drive" property
3d45853 python3: fix do_configure check platform triplet error
03b167d ncurses_6: Fix an install race condition
09eab6b build-appliance: make the inclusion of downloaded sources optional
8ea5cdc builder: remove hob from autostart
ff5d9f7 Revert "gstreamer1.0-plugins-XXX: move inherit gettext into common .inc file"
c99da8d musl: disable building of gobject introspection data
0dea50e machine/include/arch-x86: Make x32 ABI not supporting gobject-introspection-data
8c14c74 bitbake.conf: add 'gobject-introspection-data' to DISTRO/MACHINE_FEATURES_BACKFILL
2e27994 packagegroup-core-x11-sato: add python-pygobject and gtk+3
8b1fa2a webkitgtk: enable gobject introspection
7bd32b9 recipes-gnome: fix introspection support
efd37c5 python-pygobject: update to 3.18.2
ff3500b gnomebase.bbclass: do not disable gobject introspection
ac5cc0c gstreamer: enable gobject introspection
03cd714 libsoup-2.4: enable gobject introspection
c1d67e4 clutter: enable gobject introspection
0ec412b gtk+3: enable gobject-introspection
d6f8028 gtk+: enable gobject introspection
0d1e4b2 avahi: enable gobject-introspection
d2e0dc1 python-pygtk: remove the recipe
0c6d7cb avahi-ui: remove the dependency on python-pygtk by disabling avahi-discover
4fbf761 vala.bbclass: remove pre-packaged vapigen.m4 from tarballs
235455d vala: enable the use of vapigen by packages with vala support
d1b96f1 gobject-introspection.bbclass: add a class that enables gobject introspection
96b5847 gtk-doc-stub: remove introspection stubs
3a1d9fb gobject-introspection: Override GIO_MODULE_DIR when scanning
10e9977 gobject-introspection: add the recipe
3c66619 bitbake: fetch2/npm: fix ud.registry so that alternative registries can be handled
0155472 ref-manual: Updated "Application Development SDK" section.
4438460 ref-manual: Applied review edits to several SDK variables.
3c727ff ref-manual: Updated "Cross-Development Toolchain Development" section.
af1517c ref-manual: Updated "Build History SDK Information" section.
d9fc04b dev-manual, mega-manual: Updated "Application Development SDK" section.
357aa33 ref-manual, mega-manual: Updated "SDK Generation" section.
54490c0 ref-manual: Added several extensible SDK variables to glossary.
6dfd441 ref-manual: Updated IMAGE_PKGTYPE variable.
77f002c ref-manual: Updated "Cross-Development Toolchain Generation"
ee90cc6 ref-manual: Updated the "Build History SDK Information" section.
53dd8a0 dev-manual: Moved "Optionally Using an External Toolchain" to Tasks chapter.
9d76cfe meta: toolchain-shar-relocate.sh: Fix for extracting SDK in the same directory as SDK script.
054abad nettle: The variable named p in the patch file was incorrectly named.
93a5417 valgrind: Make dep on glibc-utils conditional on TCLIBC = glibc
40c9774 make 4.1: fix segfault when ttyname fails
7f27713 gcc: Disable libitm for MicroBlaze
81d58d6 sign_package_feed: add feed signature type
42f612c package_manager: sign IPK package feeds
c637783 signing-keys: create ipk package
14e809e gpg_sign: export_pubkey: add signature type support
0b088e0 gpg_sign: detach_sign: fix gpg > 2.1 STDIN file descriptor
2fccd8a gpg_sign: add local ipk package signing functionality
6bd6a2b systemd: add comment stating that resolved needs gcrypt
a5fd57d selftest/bblayers.py: Remove harcoded recipe files
dce7290 selftest/prservice.py: Sanitize package version when looking for stamp
cbd87f3 lsof: update UPSTREAM_CHECK_URI
57fb05a eudev: provide UPSTREAM_CHECK_URI
3f8d5bf toaster.bbclass: show packages that were setscened into existence too
39e1351 gcc: Fix the license on GNU OpenMP
c6aeef3 linux-yocto/4.4: Galileo updates
37b61b0 siteinfo: Add ppc64le support.
0265fcc nettle: disable static for 2.7.1
8660cd1 nettle: Security fix CVE-2015-8804
dae5715 nettle: Security fix CVE-2015-8803 and CVE-2015-8805
24aea3a glib-2.0: silence warnings when parsing headers for introspection
3331992 qemu: Limit paths searched during user mode emulation
b578a06 image-mklibs: handle position independent binaries
c706b5e libpam: define limits.conf as CONFFILES of package libpam-runtime
82dec46 perl-rdepends: Remove circular dependencies
815c36f rpm: Sync CVS to regular version
775f22e rpm: Fix musl integration with RPM5
001bdef gcc: Disable libitm for nios2
d53413d bitbake: server/process: Try connecting 4 times before giving up
0f01059 bitbake: toaster: models List only have the specified project's imported layers
0dcab02 bitbake: toaster: rework task buildstats storage and display
cc74a8a bitbake: toaster: use force_bytes to display non-ascii project names
aebc22d bitbake: fetch2: Make SRC_URI[md5sum] and SRC_URI[sha256sum] expand their values
d405f97 bitbake: xmlrpc: fix bug in setting XMLRPCServer.single_use
c50bdb3 bitbake: fetch2/npm: add missing URL argument to ParameterError
fbf27c4 bitbake: fetch2/npm: properly handle npm dependencies
ef6a451 bitbake: fetch2/npm: fix errors with some version specifications
ad50ce9 populate_sdk_ext: Correct commit 8b81bb56c69aabdea984352f8e267a9783c0bdbc
bc0e99d recipetool: create: shrinkwrap and lockdown npm modules
309b2e6 recipetool: create: support creation of additional files by plugins
2279eb2 recipetool: create: check if npm available if npm:// URL specified
9145500 recipetool: create: split npm module dependencies into packages
d46827c recipetool: create: add license file crunching
3fd244b recipetool: create: match *LICENSE* as a license file
2b6a352 recipetool: create: improve mapping for autotools program macros
1607fac recipetool: create: be more tolerant of spacing in configure.ac
9dca5c8 lib/sstatesig: skip shared_workdir when checking locked sigs
142bad3 python3: fix patching get_python_lib() in distutils/sysconfig.py
50d07e9 python3-native: use the previous version of python-config script
5dce2e3 qemu.bbclass: add qemu_wrapper_cmdline()
8b5afcd db: remove the NO_UPDATE_REASON and replace it a comment about RPM
5699c67 rpmresolve: It is not necessary to manually specify -lpopt
8ea55ba rpm: A number of the patches have been submitted upstream
6833c5d rpm: Enable specific crypto and digest settings via variables
59a4d99 security_flags.inc: Special flags are needed for RPM
007c284 rpm: Uprev to rpm-5.4.16 (pre) and rpm-5.4+cvs to current CVS head
a27ca6d yocto-bsp: Update templates to 4.4 kernel
2d0933c conf/distro/include: drop old recipes
1fd183e bblayers.conf.sample: remove BBLAYERS_NON_REMOVABLE
477b8fb poky: Enable uninative
1b7cc9c linux-yocto/4.4: explicitly enable ftrace in tracing fragment
aee7482 linux-yocto/4.4: iwlwifi: mvm: don't allow sched scans without matches to be started
2408f49 linux-yocto/kernel-meta: ktype refactoring: move DEBUG_KERNEL, EXPERT and EMBEDDED
9ac029b xmlto: tell xmlto where cp is
6d89b52 toaster.bbclass: improve how we gather buildstats for Toaster
4dd3e40 image-prelink: use STAGING_*_NATIVE variables
2193e9d strace: Backport fixes for compiling with clang
ee8ff42 ghostscript: 9.16 -> 9.18
3f5725c fontconfig: Revert changes made to FcConfigAppFontAddDir() recently
433d866 populate_sdk_ext: Make populate_sdk_ext nostamp
e186d6d systemd: binfmt should be added to SYSTEMD_PACKAGES only if binfmt is enabled
b051a95 license.bbclass: fix host contamination warnings for license files
f8a9774 oeqa/selftest/buildoptions: Test build does not fail without git rev
656aeff busybox.inc: add tail symlink so busybox can commit suicide cleanly
a321f4e avahi-ui: add dbus to PACKAGECONFIG
1bd4b72 avahi: add missing intltool-native build dependency
72f9e39 avahi: make dbus optional but default
424466b oe-setup-builddir: tidy up local.conf and bblayers.conf commentary
07919e9 net-tools: Add SCTP option support
e8254bc tune-corei7.inc: Fix PACKAGE_EXTRA_ARCHS for corei7-32
5346675 eudev: remove redundant udev_run assignment
adad264 xcursor-transparent-theme: use a version glob in the selftest bbappend
946d00c populate_sdk_ext: Update after uninative changes
ba57ba1 image.bbclass: support chaining compression (aka conversion) commands
5ac3dc7 image.bbclass: fix incomplete .rootfs customization
3322fa7 bitbake: toasterui: fix warning 'Unknown event'
621cbc8 bitbake: toasterui: exit on final events
8e138b7 bitbake: toasterui: make toasterui to work in build mode
0a61306 bitbake: toasterui: check if setEventMask succeeded
ac941ac bitbake: command: make setEventMask readonly
dd3da9a bitbake: toasterui: update list of events
f56fa5d bitbake: toasterui: reformat list of events
a71d32a bitbake: toaster: remove sshbecontroller module
3db71b4 bitbake: toaster: don't use sshbecontroller
790b2d1 bitbake: toaster: raise NotImplementedError
96535ba bitbake: toaster: bring back the strict directive
5b8b399 bitbake: toaster: change 'revision' to 'Git revision'
07ead98 bitbake: toaster: views api Package info return both kinds of RDEPENDS
9cda2ab bitbake: toaster: fixup dependency excludes for customimage
a54cebe bitbake: fetch2/npm: ignore unknown headers in tarballs
0cd1be1 bitbake: fetch2/npm: handle alternative dependency syntax
d999927 bitbake: fetch2/npm: fix indentation
26ee4dd image creation: allow overriding .rootfs suffix
e43fcdf scripts/hob: drop
59b4cef classes/packageinfo: remove
bbf2a5d conf/documentation.conf: remove BBLAYERS_NON_REMOVABLE
7054882 yocto-uninative: Add common include for uninative
d2c96ca mtools: Drop GCONV_PATH manipulation
d27644e uninative: Handle relocate of GCONV_PATH in libc
0523499 uninative: Add checksum support
73265d1 uninative: Refactor common code
4feb00d uninative: Use CXX11 ABI for interoperation between gcc4 and gcc5
013dd24 uninative: correctly enable uninative
034618d glibc: Add relocation of GCONV_PATH
8dca343 uninative-tarball: Add glibc-gconv-iso8859-1 for guile
1f50f29 dkpg: Use tar everywhere (not gtar)
b158d6c gtk3+: Add missing DEPENDS on wayland-native
e395e81 tune-cortexa17.inc: apply changes similar to a15
ea53d1e sstate: Allow late expansion of NATIVELSBSTRING
bd3a1d5 linux-yocto: Update SRCREV for genericx86* for 4.4
70c6df2 linux-yocto: Update SRCREV for genericx86* for 4.1
ae85c4b linuxloader/image-prelink/image-mklibs: Fix non-standard path prelinking
0b84897 insane/prelink: Handle nonstandard library paths
6b564ae ext-sdk-prepare: Catch setscene tasks which should have run but didn't
d8efd2e createrepo: Fix stat floating timestamps
ce5a9df xmlto: ensure /bin/bash is used as bash
70b4f36 openssl: add a patch to fix parallel builds
1632742 xdg-utils: remove trailing whitespace in multiline string
816391a btrfs-tools: Add libgcc to RDEPENDS
e467156 bitbake.conf: Add libgcc-native to ASSUME_PROVIDED
a91713f net-tools: Override CFLAGS/LDFLAGS in do_install too
fb0c3c5 nspr: Fix build regression on musl from last upgrade
37f5fb9 gdb: fix builds with internal readline and no static libraries
6518db4 feature-arm-thumb.inc: Fix thumb tune override warning
afb1d09 recipetool: create: fix support for AX_CHECK_LIBRARY
463fd5e formfactor: assume a keyboard is plugged in
e2107f5 acl: Fix re pattern in test cases
82a8064 gcc-runtime.inc: disable libitm for little endian MIPS too
25d9c4e devtool: add build-sdk subcommand
41eb36d devtool: build-image: rename module
82d0c8a oeqa/buildoptions: Improve unsafe references tests
4284fdf insane.bbclass: make the checking stricter for unsafe references in scripts
5cd71fe yocto-project-qs: Updated flow to mention Toaster
cd041b7 dev-manual: Applied review comments to the devshell section.
f54fe56 ref-manual: Updates for nativesdk clarifications.
a882267 dev-manual: Fixed typo in the devshell section.
70c7e36 dev-manual: Created devtool upgrade section.
b2b22d5 dev-manual, mega-manual, Makefile: Added support for new upgrade flow
0b7d8a4 dev-manual, mega-manual: Updated the workspace directory structure image
050e021 dev-manual: Applied review changes to the devtool section.
09ecf38 dev-manual, mega-manual: Updated three figures for devtool
f33ffaa dev-manual: Applied more review comments to the section.
fe70eb2 dev-manual, mega-manual: Updated the devtool modify flow diagram.
eb3b414 dev-manual, mega-manual: Updated the devtool add flow diagram.
4c5bd3f dev-manual, mega-manual: Updated the devtool workspace figure.
9cee16b dev-manual: Applied review comments to the devtool section
c678d1a dev-manual: Updated the devtool add section.
a09238a dev-manual, mega-manual: Updated devtool add flow diagram
7699f0a dev-manual: Added section for devtool modify flow
1eecaea dev-manual, mega-manual: Added new figure for devtool modify flow
9582da6 dev-manual: Edits to the devtool-add section.
740369f dev-manual, mega-manual: Updated the devtool add flow figure
a848e9f dev-manual, mega-manual: Updated the workflow layer content figure.
34e08b3 dev-manual: Added new "writernotes" style.
17a21e6 Makefile, dev-manual, mega-manual: Added new figure support
d346c35 dev-manual: Applied review comments to devshell section.
3b41049 ref-manual, dev-manual: Clarifying "native" and "sdknative"
a1970eb dev-manual: Updated devshell section.
a58cde0 toaster-manual: Updated how manage.py createsuperuser command is run
c5b4f69 ref-manual, dev-manual: Clarification of "native" and "sdknative"
952bcc7 toaster-manual: Removed prompts for json file.
34c75fa ref-manual: Updated the S variable description with feedback
2b2ced0 ref-manual: Updated the staging.bbclass description
b9dddd5 ref-manual: Updated the S variable description.
41e9f7c dev-manual, ref-manual: Updated licensing text information.
5066fbc ref-manual: Added order information for conf file parsing.
ad6b2f2 toaster-manual: Removed typo - double "allow" words.
c8c533e ref-manual: Updated the do_populate_sysroot task.
2a3942b dev-manual: Updated section on adding license text.
77b3d06 ref-manual: Updated the S variable entry in the glossary.
a1a4808 toaster-manual: Applied a patch to weed out build mode (modes).
353b755 bitbake: bitbake-user-manual: Added expand() function to list.
638ad17 bitbake: bitbake-user-manual: Added note for Python variable ref expansion.
da22add bitbake: bitbake-user-manual: Enhance environment variable discussion.
f11de9d e2fsprogs: do not enable non-stable features by default
b04280a sdk_update.py: Enable local sdk-update tests
14dd07c sdk.py: Fix undefined variable
c12e919 eudev: recipe formatting improvements
73a43fc openssl: Security fix Drown via 1.0.2g update
ed14aef layer.conf: Update after replacement of udev with eudev
e72233a bootimg: set default value for LABELS variable
4eaef67 sanity: Do not mistake meta-yocto-bsp for meta-yocto
86759de sanity.bbclass: remove conflict checking for image vm and live
bb1c719 syslinux.bbclass: make vm and live can be built together
5c5c13d recipetool: create: add basic support for new npm fetcher/class
2be37a9 recipetool: create: add basic support for generating linux kernel recipes
5cf15ff recipetool: create: add support for out-of-tree kernel modules
937ecd0 bitbake: toaster: cleanup of bin/toaster startup code
a7d1b95 bitbake: ui: remove the puccho ui
a9dc72f bitbake: hob: removal of hob ui and associated ui files
27468db bitbake: fetch2/npm: Add missing ParameterError import
44e3461 bitbake: npm: in cases where shrinkwrap resolved a git URL, ignore it and grab dist.tarball
2a73181 bitbake: fetch2: Fix unpack for absolute file urls
865d2fe bitbake: fetch2: fixes copying of file://dir; subdir=foo, bug 6128 and bug 6129
fb437d3 meta-yocto-bsp: bump to linux-yocto 4.4 for the non-x86 BSPs
fbedac4 maintainers.inc: Add new eudev package and change maintainership for udev
0138874 gcc: Add support for atomic opertions (libitm) where available
70153b4 classes/externalsrc: fix symlinking if symlink exists pointing to another path
eac4061 populate_sdk_ext: Only write LCONF_VERSION to bblayers if it is set
c366343 automake: don't delete .pyc files
d6e63be cracklib: fix Python packaging
a005d25 populate_sdk_base: handle empty SDK_PACKAGING_FUNC
ec3be9f linux-yocto/4.4: update to 4.4.3
6ed16ff linux-yocto/4.1: iwlwifi: mvm: don't allow sched scans without matches to be started
2497e80 linux-yocto/4.4: update to -stable 4.4.2
aa2c1f7 linux-yocto: braswell: Remove feature and move DRM_I915_PRELIMINARY_HW_SUPPORT option
702701d linux-yocto/4.4: yaffs2 build fixes
c2152b8 linux-yocto/4.1: update to 4.1.18
45d4cd7 linux-yocto/4.1: clkdev updates
79ecef6 linux-yocto/4.1: Galileo updates
5f61693 usbutils: Fix for new eudev implementation
c89b777 libgudev: Fix for new eudev implementation
3e5e540 eudev: Replaces udev with eudev for compatibility when using sysvinit on newer kernels
674e55f populate_sdk_ext: Delete the buildtools tar file after installation
d8acef2 libarchive: Set xattrs after setting times
431c1e1 combo-layer: handle empty commits during "init --history"
695cc45 classes/populate_sdk_ext: prepend to PATH rather than appending
b145480 classes/module: allow substitution of the modules_install target name
b03936c grub2.inc: drop bogus dependency on xz
7328765 grub2.inc: avoid passing -isystem to native builds
576587d grub2.inc: dont export TARGET_CFLAGS etc to grub2 configure
97a3322 harfbuzz: update 1.2.1 -> 1.2.3
edf93a0 gstreamer1.0-plugins-bad.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5
89140b0 dhcp: CVE-2015-8605
6ccd8cd sato/images: Add ptest image
f38debb layer.conf: Whitelist cantarell-fonts fontconfig dependency
b307937 pango: make ${PN}-ptest RDEPENDS on cantarell-fonts
0c80f29 cantarell-fonts: Add recipe
4006a7f sanity: Fix int verses string reference
2e27c4b bitbake: fetch2/npm: Enable fetcher
1c060d7 pseudo: Increase number of retries
030d920 bitbake: providers: Fix PREFERRED_VERSION lookup for '_' in PN
c679a3d bitbake: fetch2: Skip lockfiles and donestamps for local files
d01042e bitbake: fetch2/__init__.py: Error if lockfile path invalid
ab7b7bf bitbake: fetch2/__init__: Fix decodeurl to better handle urls without paths
06b4d8f bitbake: fetch2/wget: Set localfile for directories
8d7e799 genericx86-common: Update PREFERRED_VERSION_linux-yocto to 4.4
65d6a62 gstreamer1.0-plugins-bad.inc: enable webp PACKAGECONFIG by default
cd00748 gettext: Delete libintl.la file from install
b33efa9 systemctl: handle RequiredBy dependencies
8caa592 ffmpeg: add bzlib, lzma and xv PACKAGECONFIGs
0011760 rootfs-postcommands: fix ssh_allow_empty_password checking
96f5f89 musl: Add linux-libc-headers to deps
3354878 mesa: Fix build on musl
7651342 dosfstools_2.11: fix build following removal of -e from EXTRA_OEMAKE
6c8abea uclibc support for rng-tools
c7e5a38 oeqa/sdkext: Add sdk_update.SDKUpdateTest class.
738bd1a classes/testsdk: Pass tcname to SDK and SDKExt contexts
2a410b2 classes/testsdk: Move the removal of bitbake PATH to eSDK context only
eb1f8b9 classes/testsdk: Move code for avoid PATHs to oeqa.utils
55d4849 gstreamer1.0-plugins-XXX: control orc PACKAGECONFIG via GSTREAMER_ORC
083c63d boost.inc: fix BJAM_OPTS --build-dir option
f4e17c6 shared-mime-info: update to 1.6
4ffdfdf vala: update to 0.30.1
f53f374 python-git: update to 1.0.2
ec73437 pax-utils: update to 1.1.5
447ddb9 nettle: update to 3.2
26a3d25 ncurses: update to revision 20160213
dc42d30 libdrm: update to 2.4.67
0296e0a gtk+3: update to 3.18.8
e08ad62 gtk-icon-utils-native: update to 3.18.8
9daf153 git: update to 2.7.2
927dfaf gnupg: update to 2.1.11
2c39358 clutter-gst-3.0: update to 3.0.16
b8a1e59 ccache: update to 3.2.4
4d4aa1f libsolv: update to 0.6.19
8c2e420 ffmpeg: update to 3.0
afce247 nspr: update to 4.12
b19dbe5 pcmanfm: update to 1.2.4
6b41608 libfm: update to 1.2.4
325a9d3 epiphany: update to 3.18.4
d4da534 wic: don't throw away our created swap partition
5f82d17 automake: set test-driver path relative to top_builddir
b41862d uninative-tarball: respect SDKMACHINE when building
4d1c14f boost.inc: enable more verbose build logs
7f84ad0 gstreamer1.0-plugins-XXX: move inherit gettext into common .inc file
2ce48e6 gstreamer1.0.inc: add explicit PACKAGECONFIG init
935d88a gstreamer1.0-libav: move LIBAV_EXTRA_CONFIGURE_COMMON_ARG into .inc
3a8ff19 gstreamer1.0-libav_git: add --ranlib option to LIBAV_EXTRA_CONFIGURE_COMMON_ARG
b8bdb99 boost.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5
9ca8f30 populate_sdk_ext: Add images to SDK_INSTALL_TARGETS
07dc765 boot-directdisk.bbclass: drop IS_VM chechking
a87574c image-live/boot-directdisk.bbclass: remove AUTO_SYSLINUXCFG
76eb815 testimage.bbclass: reuse generic test suites
6571a84 testimage.bbclass: add generic, image test suites
8c45747 gconf: remove redundant dependencies
a74c389 gtk-doc-stub: don't inherit autotools
2269f90 os-release: sanitise VERSION_ID field
9d86b26 apr-util: add ldap crypto and sqlite3 to PACKAGECONFIG
d8d2f57 apr-util: fix loadable module packaging
77cfa2b glibc.inc: improve optimisation level sanity checking
04c4719 rsync: add native variant
2c20fe4 core-tools-profile: add lttng tools for aarch64
8a0b997 lttng-ust: add support for aarch64_be
6081c35 liburcu: add support for aarch64_be
07a3c71 harfbuzz: add explicit dependency on fontconfig
73cc8b8 harfbuzz: update 1.2.0 -> 1.2.1
bb151b8 fontconfig: Don't add font directories from host
e9f5134 musl: Upgrade to 1.1.14
bf4d380 oe-selftest: devtool: add an additional test for devtool upgrade
4bae2f2 oe-selftest: devtool: rework devtool upgrade test
10290f2 devtool: upgrade: print new recipe name
5cd3be3 devtool: upgrade: drop PR on upgrade
e6f684b devtool: upgrade: eliminate unnecessary datastore copy
860574e devtool: upgrade: fix several issues with extraction of new source
66a781c devtool: upgrade: fix constructing new branch from tarball releases
d30cc76 devtool: upgrade: fix renaming of recipe if PV is not in name
75eeeab devtool: upgrade: fix moving version-specific files directory
81ebb0b devtool: upgrade: fix version argument checking
e953b57 devtool: upgrade: drop superfluous call to validate_pn
492b1eb devtool: upgrade: make source tree path optional
942ae25 devtool: modify: fix source tree default name when mapping virtuals
e2334e1 devtool: add: tweak auto-determining name failure message
55ae566 uninative.bbclass: if the loader can't be found disable instead of failing
50b8740 uninative: use check_output instead of Popen directly
4495e8b lib/oe/qa: add explicit exception for 'file isn't an ELF'
4553bb1 libdrm: fix build with uclibc
4e5a871 strace: fix ptest execution
e8e0489 clutter-1.0: Fix confgure test errors found by clang
b748f40 oeqa/parselogs: Updated whitelist
4b32351 buildstats.bbclass: Don't assume /proc/<pid>/io present
07e1f10 sysvinit-inittab: Move start_getty scrip to base_bindir.
8d07e14 oeqa/selftest/prservice: Added new TC: check pr-server starts and stop correctly on localhost.
d2a563c oe-selftest: Add support for lib/oeqa/selftest subdirectories
7f58b92 musl: Upgrade to 1.1.14
73bf792 devtool: update-recipe: create config fragment
2fbd1d7 devtool: sync: update kernel config
26f951b git: fix installed-vs-shipped QA Issue
033db24 btrfs-tools: fix symlink creation multiple times
9af773f bison/gettext: add --with-bisonlocaledir to assign BISON_LOCALEDIR
b14e2ae gcc: use relative path for configure script
1f00fb2 depmodwrapper-cross: nopackages to avoid QA [buildpaths] issue
00a6f5a oeqa/utils: added new network module
3f7aa6f scripts/oe-selftest: Use site.USER_SITE to run coverage configuration code for sub-process
1c6c76e scripts/oe-selftest: Add filtering to the coverage data gathered by oe-selftest
4a21827 oeqa/selftest/signing: Added test for locked signatures
604dc1c package: check inherit instead of PN to decide if a recipe is a packagegroup
b4df005 tune-cortexa9.inc: add vfpv3 tunes
889a5cc mirrors/own-mirrors/sanity: Updates after npm fetcher addition
28d17cf npm.bbclass: Add npm class to match fetcher
bc5a1d1 base: Add nodejs-native dependency for npm:// urls
9d5483c meta-yocto: Rename to meta-poky to better match its purpose
ab3a718 adt-installer: Drop since its replaced by the extensible SDK
c1c6a9d sanity: Improve configuration upgrade capabilities (support meta-yocto -> poky transition)
2587101 image: Run do_rootfs_wicenv after do_image
e0fd964 bitbake: toaster: change 'delete layer' to 'remove layer'
6e82820 bitbake: toaster: rename 'run again' button
c8dd72c bitbake: toaster: fix banner after customimage package add
149f574 bitbake: toaster: custom breadcrumb for the default project
4a12865 bitbake: prserv: Add dump_db()
bdb51ab bitbake: toaster: remove custom images from Image Recipes
98d462c bitbake: toaster: show suffix for image files and basename for artifact files
88b5660 bitbake: toaster: add missing link to image recipe details
25b179d bitbake: toaster: adjust the search field width
a97081b bitbake: toaster: make 'configuration' the first tab
e1fc319 bitbake: toaster: link to configuration in all breadcrumbs
df2808f bitbake: toaster: reduce max height of modal dialogs
6c51f08 bitbake: toaster: disable add layer button on click
d4a663a bitbake: toaster: apply error class to name field
48f0ae2 bitbake: toaster: fix custom image name form
07eb4f2 bitbake: toaster: comment out project release change
12ade9b bitbake: fetch2/npm: Add mirroring support for npm fetcher
ca5b6d6 bitbake: fetch2/npm: Add npm fetcher
813bd1f bitbake: utils.py: Add sha1_file call
7bb9e8d signing-keys: Make signing keys the only publisher of keys
64ab17b systemd: Upgrade to 229
44248af harfbuzz: update to version 1.2.0
f4f5573 perf: add sysroot handling to subcmd
7a95c2c oeqa/selftest/buildoptions: build -minimal instead of -sato images
2980ac0 bitbake.conf: add findutils-native to ASSUME_PROVIDED
2e152ff findutils: upgrade to 4.6.0
951ce18 mesa: add missing space to RRECOMMENDS append
2305610 uclibc: Do not use immediate expansion operator
aab3900 security_flags: Disable ssp when compiling uclibc
afb954e rpm: fix building rpm 5 with internal beecrypt
069cdbe alsa-lib: topology: Add missing include sys/stat.h
b879aed libsdl2: Fix patch after upgrade
3d4f71d gstreamer1.0-libav_git: update 1.7.1 -> 1.7.2
9d83a3e gstreamer1.0-plugins-ugly_git: update 1.7.1 -> 1.7.2
6456a6f gstreamer1.0-plugins-bad_git: update 1.7.1 -> 1.7.2
821498f gstreamer1.0-plugins-good_git: update 1.7.1 -> 1.7.2
04e77c1 gstreamer1.0-plugins-base_git: update 1.7.1 -> 1.7.2
e67c91d gstreamer1.0_git: update 1.7.1 -> 1.7.2
ea8c34e libnewt: Fix build with PIE flags
66a833a pseudo: Fix build when security flags are enabled
91a1baa glibc: Upgrade to 2.23
c1f9507 no-static-libs: remove eglinfo
0ab67d6 freetype: use autotools instead of a manual do_configure
4883ccc classes/populate_sdk_ext: add a better config extension mechanism
524ee08 recipetool: create: improve CMake package mapping
7b6e5b0 recipetool: create: add additional extension mechanisms
b2d4472 devtool: modify: tweak help description for behaviour change
a8e0e5e devtool: deploy-target: preserve existing files
2059a34 devtool: undeploy-target: support undeploying all recipes
b95c72c devtool: deploy-target: write deployed files list to target
62989ef devtool: sdk-update: tweak command-line handling of updateserver
cada5a8 devtool: (un)deploy-target: add help descriptions
6bd88e6 scripts/lib/argparse_oe: tweak title above options
32ef523 devtool: categorise and order subcommands in help output
9f7df76 devtool: update-recipe: don't show workspace recipe warning if no update
51972ed devtool: reset: fix preserving patches/other files next to recipes
e54f9c1 devtool / recipetool: use common code for launching editor
dd35f69 devtool: minor fix for error message
41242a2 staging.bbclass: remove trail slash from SYSROOT_DESTDIR
aeb8964 terminal.bbclass: import oe.terminal for oe.terminal.prioritized()
bee556a recipe_sanity.bbclass: skip DataSmart in recipe_sanity_eh()
2d293bd image.bbclass: fix circular dependency when IMAGE_FSTYPES append hddimg
a332360 toolchain-scripts.bbclass: add three other path to PATH in env.sh
4d2910f libsoup-2.4: disable libsoup-gnome by default
619f6c6 libsoup-2.4: prevent PACKAGECONFIG dependant package renaming
13e726f libsoup-2.4: minor formatting improvements
dd0ef3c populate_sdk_ext.bbclass: Add SDK_RECRDEP_TASKS variable
4c5c40d devtool: Don't recursively look for .devtoolbase in --basepath
0220180 populate_sdk_ext: Don't ignore SDK_TARGETS value
8c0ba8d bitbake: toaster: toastergui Fix invalid char test and implementation
913e9b1 bitbake: toaster: PackagesTable show only installed packages
94bca58 bitbake: toaster: toastergui unit tests convert to use fixtures
8796ac8 bitbake: toaster: SoftwareRecipesTable apply default order_by
8469e58 bitbake: toaster: orm migrations Sort out migrations mess
78b6109 cml1/sstate: Fix missing getVar parameter
7e19f88 linux-yocto/4.1: capabilities backports
54bfbcc waf.bbclass: Remove --disable-static from EXTRA_OECONF
51fc304 gcc-5.3: backport fix for PR-target-65358
ed20c6c epiphany: Add libxml2-native to DEPENDS
2021f63 libsdl2: update to 2.0.4
947b3bf cmake: Update to 3.4.3.
4699483 sstate.bbclass: use oe.gpg_sign for gpg signing
db7c7c2 oe/gpg_sign: add 'passphrase' argument to detach_sign method
e845b75 sign_rpm.bbclass: do not store key details in signer instance
d5be866 oe/gpg_sign: add 'armor' argument to detach_sign()
03554b7 oe/gpg_sign: add verify() method
af7e516 ruby: break out ri-docs and rdoc into separate packages
8bcf139 insane.bbclass: print more info for build-deps and file-rdeps
5f3dfea curl: re-enable proxy support by default
1f61888 libtool: Don't hardcode grep paths
a3b996a cml1.bbclass: fix do_menuconfig
91bfe50 cups: upgrade to 2.1.3
eeac0a9 coreutils: upgrade to 8.25
01dc859 findutils: upgrade to 4.5.19
bf7d5f6 diffstat: upgrade to 1.61
247f3b4 grep: upgrade to 2.23
4e5e501 bitbake: data_smart: Drop default expand=False to getVarFlag [API change]
c7610aa bitbake: data_smart: Drop default expand=False to getVar [API change]
4f0ab27 bitbake: SignatureGeneratorBasic: make checksum cache file configurable
0cdf193 bitbake: MultiProcessCache: make cache filename configurable
ca552bb bitbake: FileChecksumCache: add get_checksums() method
8f61f2d bitbake: bb/runqueue: save task file dependency cache onto disk
5177b1e bitbake: SignatureGenerator: add method for saving the file checksum cache
97617fd bitbake: bb/cache: drop some unused arguments
5a87d8c bitbake: Allow Hob to run images on a custom simulator, other than qemu
7fc38ea gma500-gfx-check: Fixes infinite calling to modprobe gma500_gfx
be7b52a pulseaudio: 6.0 -> 8.0
c52b8f6 alsa-plugins: 1.0.29 -> 1.1.0
a231a4e alsa-utils: 1.0.29 -> 1.1.0
1adbb73 alsa-tools: 1.0.29 -> 1.1.0
3a82e2e avahi: update to version 0.6.32
14daeb5 no-static-libs.inc: Add libcap-native
c001863 libsdl2: Fix build with static libraries disabled
a46dc87 uboot-inc: Backport patch to fix Beaglebone Black bootloader
c7355b9 busybox: drop patches that are not valid anymore
47d0119 pcmciautils: Update SRC_URI
f37ac5b debianutils: Upgrade 4.5.1 -> 4.7
adfcaf2 busybox: Add musl config for _git recipe
46824dc debianutils: Fix SRC_URI to use debian snapshot
3df8701 nfs-utils: bugfix: adjust name of statd service unit
c15bf55 musl: Upgrade to 1.1.13+
07e7879 dpkg: Update to 1.18.4
5794b56 glew: upgrade to 1.13.0.
aea0746 glew: rewrite to use upstream build system
0b1c324 socat: Fix build with musl
04c6a48 binutils: Fix useless rpaths QA warning
eb6d14e image/populate_sdk: seprate variables to fix dependency
c9e5e34 gcc: Backport nios2 r31 fix
012460d sqlite3: update 3.10.2 -> 3.11.0
f770a6e insane: wrap autotools checks in inherits_class(autotools) checks
35011d9 cmake: don't inherit autotools
9cd64ed oeqa/selftest/bbtests: Test bitbake --setscene-only option
7e5b451 glew: don't put our CFLAGS into the pkgconfig file
b1145cc dbus: update large file patch
fad63e3 coreutils: fix problem with acl for 6.9 version
351039f gcc-4.9/5.3: Ignore -fdebug-prefix-map in producer string
7a11650 bitbake.conf: use target path as compile dir in debugging info
ef30119 glibc: Security fix CVE-2015-7547
c834ebc glibc: CVE-2015-8776
842177a glibc: CVE-2015-9761
efa1ae5 glibc: CVE-2015-8779
aefe1fa glibc: CVE-2015-8777.patch
152914f oeqa/parselogs: Whitelist dmi firmware failure message in 4.4 kernels
683ea31 rng-tools: Fix underquoted m4 and libgcrypt floating dependency
7a700f5 lib/qa.py: raise ValueError if file isn't an ELF
334e1b5 lib/oe/qa: ELFFile: check that a path is a file before opening it
11359e9 rng-tools: fix the build with musl
a258589 bitbake: bb.ui.knotty: prefix task messages with recipe/task
4bf8b21 bitbake: Move bb.{debug,note,..} into their own logging domain
3b35de3 layer.conf: Add gstreamer1.0-meta-base to SIGGEN_EXCLUDERECIPES_ABISAFE
14e9385 sstate: Add ca-certificates-native to postinst recipes list
73e53e4 nss: define RPATH variable for nss-native
6e4e9f7 Revert "lsbinitscripts: fix the path for mountpoint"
6db39e1 libunwind: Fix build on ppc
47896a7 dbus-glib: 0.104 -> 0.106
93d8fc1 conf/no-static-libs: add explicit rule for libical
637b44c runtime/systemd: Fix for boot time string parse error
ef5b8b4 security_flags: Add SECURITY_CFLAGS to TARGET_CC_ARCH for binutils
1387785 binutils: Use tip of 2.26 branch
da13f0b buildhistory.bbclass: remove out-dated information on request
a56da4a Remove obsolete references to exmap
8b21720 bitbake: knotty: Set exit failure code on runQueueTaskFailed events
a9223e2 bitbake: taskdata: Fix traceback issue with missing provider
7593756 bitbake: cooker: Improve cache handling
9cb38c1 poky: Disable static libs by default
f852014 bitbake.conf: Remove unhelpful default value for EXTRA_OEMAKE
b050c50 apmd: fix build with static libraries disabled
d585a71 oeqa: Update to handle domain specific references in build logs
9300749 libpng12: Handle no static libs
67ea65e ed_0.5: Handle --disable-static option
438d6d6 conf/distro/include: Add no-static-libs.inc
2eb19cc classes/buildhistory: fix for python function parsing change
1a3204c valgrind: Fix build with musl
e8b0da1 rpm: Fix build with musl
48144e0 gstreamer1.0-meta-base: Mark as machine specific due to COMBINED_FEATURES
ff8ca89 gdb-cross-canadian: Add missing virtual/* DEPENDS
120a160 e2fsprogs: Update to upstream version of a patch
5394ada gdb: Rationalise PACKAGECONFIG
ce0f8ab insane: Add --disable-static to UNKNOWN_CONFIGURE_WHITELIST
94abdb2 linux-yocto: Work around PAT issue on qemux86
6fb493a libgcrypt: update 1.6.4 -> 1.6.5
bf9ad22 musl: Upgrade to tip of tree
5d156bc oe-selftest: don't use specific tasks
80e8928 oe-selftest: pylinted wic tests
9b6dc9b wic-image-minimal: use uuid for root partition
ab7cb65 wic: fix processing of --use-uuid
51e0a8a oe-selftest: add new wic testcase
2100f82 wic-image-minimal: update .wks to boot by qemu
4b26601 wic-image-minimal: change IMAGE_FSTYPES
f799e21 oeqa/targetcontrol: support wic image type
7066f16 oeqa/targetcontrol: make ssh control optional
0ade658 qemurunner: add parameter to method 'start'
d083fec oe-selftest: remove unused parameter
c26a9c3 runqemu: support path/to/<image>-<machine>.wic
c7f0578 runqemu: don't set KERNEL for wic images
2c3a009 runqemu: add support for wic images
64d2f13 scripts/sstate-cache-management.sh: Change wording
6740dd5 qemu.inc: Add rng-tools to qemu images
ce3df21 rng-tools: Import recipe from meta-openembedded
36b43b2 lib/oe/terminal: set workdir for konsole terminal
03e1950 mmc-utils: upgrade to latest git version
b5b8003 ltp: Upgrade to 20160126 and fix build on musl
f6b3957 initscripts: start urandom after populate-volatiles
85ac8eb initscripts: populate-volatiles.sh: add mount-bind feature
be5b72c libdrm: don't detect components that have been disabled
5fc5996 buildhistory: Fix regex to handle versions without spaces
7c3d4c0 debian: Fix superfluous setting for RPROVIDES
2eba066 autotools: Fix interaction with bitbake -b
9c8fee9 autotools: Correct dependency search logic error
971fafb maintainers.inc: include libjpeg-turbo and mmc-utils
4e0b334 scripts/runqemu-internal: Work around qemux86 PAT bugs in linux 4.4.1
283a302 sanity: Bump minimum version to 1.29.0
1c2d632 bitbake: Bump version post release to 1.29.0
a12dcc4 base.bbclass: fix support for gitsm://
bc72f64 linux-yocto: Update SRCREV for genericx86* for 4.4
be89a1d linux-yocto: Update SRCREV for genericx86* for 4.1
4a8d20a poky: update qemu* to prefer 4.4 kernel
d255f4f linux-yocto/4.1: galileo backports and support
fdcb373 linux-yocto/4.1: update to v4.1.17
5688cab linux-yocto/4.4: update to v4.4.1
f9f93ae bitbake: cooker: gracefully shutdown parsers
1f7f077 bitbake: buildinfohelper: unset brbe variable when build finishes
9a6cb10 nativesdk-buildtools-perl-dummy.bb: Fix variable expansion in python code
5e978d7 classes/testsdk: do_testsdkext avoid STAGING_DIR/BASE_WORKDIR in PATH
f56e9aa freetype: update 2.6.2 -> 2.6.3
1ba1aa3 freetype: minor formatting improvements
0d5e611 piglit: upgrade SRCREV
72c6b62 libbsd: Security fix and update 0.8.2
78be954 gstreamer1.0-plugins-bad_git: fix gst_structure_get() etc compiler warnings
fdd8979 gstreamer1.0-plugins-good_git: fix gst_structure_get() compiler warning
a23a50e python-setuptools: Add python-compile on RDEPENDS
914ff14 qemu: Security fix CVE-2016-2198
0938353 qemu: Security fix CVE-2016-2197
1f3e1d1 curl: add PACKAGECONFIG options for less common / legacy protocols
19045ba toaster: tests Remove symlinks from toasteruitest folder
738a9b7 classes/sanity: check_perl_modules provide output when fail
e64ce73 oe-selftest: devtool: add another devtool add test
a5095d1 recipetool: create: set S when we set SRC_URI from local git repo
ca5a36c recipetool: create: convert http git URLs that don't end in .git but contain /git/
4c71afb recipetool: create: ensure URL parameters don't make it into the name
86f3464 devtool: add: fix adding from a local source directory
fa50153 devtool: modify: make -x the default behaviour
f767757 recipetool: create: determine name/version from github/bitbucket URLs
d94c7e3 recipetool: create: support cmake find_library directive
ddfe744 devtool: commit for extra tasks that modify source when extracting
e36cb6c classes/externalsrc: create symlinks for workdir and logs
20034c3 classes/externalsrc: disable rm_work when active
c38f253 uninative.bbclass: capture stdout/err from patchelf-uninative
9065222 db: update HOMEPAGE
f0d5478 mdadm: update to version 3.4
79d5041 iproute2: update to version 4.4.0
21e3b2a image_types_uboot: add cpio.gz.uboot to supported IMAGE_TYPES
6fab5fc recipetool.newappend: add -e/--edit argument
252f97e liburcu: Add nios2 support
e72ab70 strace: Fix build for arc, metag, nios2, or1k, tile
691277f udhcpc: specify full path for ip command calls
f141f0b alsa-lib: avoid including <sys/poll.h> directly
a1ad3d0 oprofile: Add nios2 support
fd7dd07 nspr: Add nios2 support
954dc45 guile: Fix nios2 support
611e3d8 binutils: Repair nios2 PLT and GP handling
027eac5 gstreamer1.0-meta-base: make gstreamer1.0-plugins-base-alsa conditional
056d82c curl: drop obsolete pkgconfig_fix.patch
0e62f01 iproute2: update to version 4.4.0
216e618 quota: update to version 4.03
25d2956 oeqa/selftest/sstatetests.py: check that PARALLEL_MAKE doesn't change signatures
2966016 bitbake.conf: remove unused ALLOWED_FLAGS
3bdeda5 libproxy: remove GPLv3 logic and spurious exports
86994fd libproxy: add PACKAGECONFIG control for gnome3
033d754 libproxy: replace PACKAGECONFIG equivalent with the real thing
e65a29e openssh: Properly skip ptrace test if tools are missing
e1a1e0b openssh: Fix regex that sets sftp-server path for tests
d7faf67 insane.bbclass: Support MicroBlaze with musl
9937c93 hdparm: Explicitly set EXTRA_OEMAKE as required
7475c4c qemu: Security fix CVE-2016-1568
4857511 xserver-xorg: Add PACKAGECONFIG for crypto libraries
34798fa mesa: upgrade 10.6.3 -> 11.1.1
7edea7c initrdscripts: fix mmc device as install target
c3ef2bb libsoup-2.4: Remove unnecessary gnutls dependency
04454b2 wpa-supplicant: Only depend on libgcrypt when needed
4de0ee6 systemd: Don't depend on gcrypt unnecessarily
0da96bf buildstats.bbclass: remove dead URL from comment
326592d Remove obsolete references to exmap
a0cc1c3 curl: update 7.47.0 -> 7.47.1
a0d3eb9 sign_package_feed.bbclass: fix task dependencies
8cb1e83 oe/gpg_sign: fix incorrect variable name
902a68f meta/conf/layer.conf: adapt to more flexible initramfs-framework RDEPENDS
5b2b343 tune-corei7.inc: tell qemu to emulate a matching processor
5b70ee4 pixz: fix upstream version check
62a6f97 webkitgtk: update to 2.10.7
1cd6912 libwnck3: update to 3.14.1
e53eef9 iso-codes: update to 3.65
30cf8aa bash-completion: fix upstream version check
8098256 gstreamer1.0: fix upstream check for unstable versions from git
c24b0ab ffmpeg: update to 2.8.6
9237097 python: merge python-elementtree into python-xml
5ac4172 piglit: add missing dependency on python-xml
4d3ca42 systemd: tighten timesyncd and journal-gateway user accounts
6be3031 systemd: extend PACKAGECONFIG flags
85728ec systemd: rename systemd-zsh to systemd-zsh-completion
22a2866 systemd: move some tools into systemd-extra-utils package
9909104 classes/useradd: handle whitespace only USERADD/GROUPADD/GROUPMEMS
e485686 systemd: realign packages list
41d0f83 systemd: move bash completion into separate package
9a80afd nettle.inc: drop duplicate LIC_FILES_CHKSUM and SRC_URI hashes
72ec267 gdb: drop unnecessary CC_FOR_BUILD etc exports
00d6b67 gdb: build fix for MIPS + musl libc
40e4e8c strace: build fix for MIPS + musl libc
299b426 uclibc: fetch from master branch not 1.0
4ac4d28 uclibc-ng: Bump up to 1.0.12 release
70bfd4c musl: Upgrade to tip of tree
d1496b4 e2fsprogs: Fix multiple xattr handling
9d4b526 cdrtools-native: Explicitly set EXTRA_OEMAKE as required
864797a oeqa/prservice: Fix whitespace problem
7cd8351 pseudo: uprev to 1.7.5
246b02e ptest-runner: Explicitly set EXTRA_OEMAKE as required
7932525 unzip: Explicitly set EXTRA_OEMAKE as required
4ef055c sysklogd: Explicitly set EXTRA_OEMAKE as required
625066b stat: Explicitly set EXTRA_OEMAKE as required
07e81c8 pigz: Explicitly set EXTRA_OEMAKE as required
936223b iputils: Explicitly set EXTRA_OEMAKE as required
1e3fdbb ed: Explicitly set EXTRA_OEMAKE as required
ef36b6f gptfdisk: Explicitly set EXTRA_OEMAKE as required
59ee206 dmidecode: Explicitly set EXTRA_OEMAKE as required
d17758a libacpi: Explicitly set EXTRA_OEMAKE as required
44e8d0f apmd: Explicitly set EXTRA_OEMAKE as required
961d898 perl: Explicitly set EXTRA_OEMAKE as required
ecb9c34 oeqa: Improve test failure messages
ae2f3a3 sstate: Ensure populate_lic sstate objects are cleaned
26f26e5 package_deb: Ensure allarch deb packages aren't target specific
b3a2065 base: Make do_cleansstate nostamp
37357ab classes/testimage: Fix exportTests function.
f895a61 classes/testsdk: Add help information on how to run tests.
e22fbce oeqa/sdkext/devtool.py: Add location test to ensure that devtool is the eSDK one.
92d0cc5 oeqa/sdkext: Add devtool basic tests for eSDK.
a619ea2 oeqa/oetest: Fix compatibility SDK tests using eSDK.
062dbd6 classes/populate_sdk_ext: Add SDK_EXT_TARGET_MANIFEST and SDK_EXT_HOST_MANIFEST
4cfdf17 testsdkext: Add skeleton for support Extensible SDK tests.
5580d7b classes/testsdk: Add compatibility SDK testsuite to eSDK
7181da7 oeqa/oetest: oeSDKTest when run a command redirect env output to null
f3c2ce2 classes/testsdk: Add function run_test_context
3577c35 oetest.py/TestContext: Move loadTests and runTests inside it.
8009418 testimage/testsdk: Move get test suites routine inside TestContext.
b588b80 testimage/testsdk: Modularize TestContext.
59791d1 toolchain-shar-extract.sh: Add proxy variable to new env.
abd8158 classes/testsdk: Add call to export_proxies on testsdkext.
42f2ac4 classes/testsdk: Add testsdkext task only install.
90590ab get_test_suites: Add sdkext type for load test suites.
2ecc319 populate_sdk_ext: Set TOOLCHAINEXT_OUTPUTNAME.
7b459be classes/testimage: Add defeault inherit for testsdk.
24326a9 classes/testsdk: Add new class testsdk.
3d1d30b testimage: Modularize helper functions for get test lists.
8b5ee36 bitbake.conf/base: Improve handling of SRCPV
947e526 oeqa: setup bitbake logger after tinfoil.shutdown
400f530 bitbake: build: Improve python execution tracebacks
aece748 bitbake: build/data: Don't expand python functions before execution [API change]
e39cfb1 bitbake: cooker: Don't expand python functions in variable dumps
f652b6b bitbake: data: Don't expand python functions for variable dependencies
d3e0c44 bitbake: data_smart: Avoid expanding anonymous python functions
e0eb2ea bitbake: toaster: models Remove manual transaction control from lsupdates
48622e1 bitbake: toaster: build section Improve display of builds when > 1 targets
4d0ba0f bitbake: toaster: templates make build data breadcrumb consistent
99184d7 bitbake: BBHandler/ast: Merge handMethod and handleMethodFlags
6ba69b4 bitbake: utils: Drop datastore function inspection during exception
f8a44b1 bitbake: cooker: extended dot styling
30c132b bitbake: toaster: Enable Image Customisation feature
5e14a8f bitbake: toaster: xhr_customrecipe_packages Add dependencies to included packages
749f5a6 bitbake: toaster: orm generate_recipe_content only exclude locale packages
6269411 bitbake: toaster: customrecipe page Add last successful build link and conditionals
8d5b61e bitbake: toaster: models Add update_package_list for CustomImageRecipe
86db0bd bitbake: toaster: orm Add last_updated field to CustomImageRecipe
18d8b17 bitbake: toaster: models add get_last_successful_built_target method
8885b7b bitbake: toaster: pkg_dependencies_popover just show direct dependencies
40f6eff bitbake: toaster: models add all_depends method for Package_DependencyManager
a8ab1c6 bitbake: toaster: buildinfohelper CustomImagePackage update dependency info
0fee829 bitbake: toaster: newcustomimage_modal add frontend name validation
cb6d290 bitbake: toaster: API CustomImageRecipe check the recipe name supplied is valid
5634a25 bitbake: toaster: views CustomRecipe API add size information to the package lists
6fbceb0 bitbake: toaster: models Invalidate ToasterTables cache when a m2m field changes
998f9af bitbake: toaster: customrecipe Add dependency tracking to package selection
9976e4f bitbake: toaster: tables move template logic into the pkg_add_rm_btn
d77c247 bitbake: toaster: CustomImageRecipe generate overwrite IMAGE_FEATURES
481dc11 bitbake: toaster: make locale packages uneditable in custom image page
a757d39 bitbake: toaster: include locale and packagegroup packages in custom image
baac458 bitbake: toaster: update custom image package table filters
efbffe3 bitbake: toaster: move recent builds query to model
b514785 bitbake: toaster: update customimagerecipe migration
df58f5b bitbake: toaster: add merge migration to resolve conflict
38f4913 bitbake: toaster: orm generate_recipe_file_contents Handler for require recipe
769017e bitbake: toaster: project builds Poll the server to get latest progress for build
971d65c bitbake: toaster: localhostbectrl Update the dirpath of customrecipe's base layer
6d9f342 bitbake: toaster: tables Check layer presence in project for customise_btn
76c0008 bitbake: toaster: toastergui tests Add addtional data to the setUp for new tables
70a078e bitbake: toaster: tables SelectPackagesTable rename recipe_id to custrecipeid
7e4c231 bitbake: toaster: toastergui tests Update package test to use CustomImagePackage
4b3c9d6 bitbake: toaster: customrecipe Add further front end features using new API
b213907 bitbake: toaster: xhr_customrecipe_packages add GET info for package response
a9668ee bitbake: toaster: xhr_customrecipe_id change to use CustomImagePackage
439314c bitbake: toaster: API allow CustomImageRecipe to be updated after creation
9ea4de6 bitbake: toaster: tables Change SelectPackagesTable to use ProjectPackage
20f400b bitbake: toaster: tables add recipe download link to CustomImagesTable
1c9ce1c bitbake: toaster: newcustomimage_modal use libtoaster method for new CustomRecipe
8b1d043 bitbake: toaster: libtoaster Add createCustomRecipe method
32048fa bitbake: toaster: orm Add convenience method to get all pkgs in a CustomImageRecipe
c80b7df bitbake: toaster: orm get_project_layer_versions to return layer_version objects
796e348 bitbake: toaster: toastergui tests Add unit test for download custom recipe
04d8c94 bitbake: toaster: toastergui tests Update to reflect changes to CustomImageRecipe
4e8a0aa bitbake: toaster: views xhr_customrecipe_packages clean up API
66b5608 bitbake: toaster: toastertable remove title from Show all in table
ce72896 bitbake: toaster: Add recipe details page
5f52614 bitbake: toaster: newcustomimage Move modal dialog out of newcustomimage template
2a3dd32 bitbake: toaster: Continue front end features to custom image recipe page.
d6e7e4a bitbake: toaster: tables Add table for Packages and update SelectPackagesTable
43f0a05 bitbake: toaster: views Add view to download custom recipe
2cf55af bitbake: toaster: move CustomImageRecipe generation to API entry point
c402ac2 bitbake: toaster: orm add CustomImageRecipe generate contents function
a6e4f94 bitbake: toaster: buildinfohelper Add the concept of CustomImagePackage
e1bfe1c bitbake: toaster: orm: Add db migration for new CustomImagePackage table
f760a78 bitbake: toaster: orm Add CustomImagePackage table
4117af2 bitbake: toaster: orm: Add db migration for new CustomImageRecipe inheritance change
1f10289 bitbake: toaster: orm make CustomImageRecipe inherit from Recipe
648753b bitbake: toaster: orm Add sum of dependencies size function to PackageDependencyManager
a92fc30 bitbake: toaster: tablejs Add an event handler to manually trigger a data reload
4c82878 bitbake: toaster: ToasterTables simplify filter function move common part to widget
3e1e8e6 bitbake: toaster: models fall back to a sensible string for no vcs reference
14d09c8 bitbake: toaster: localhostbecontroller CustomRecipe now base_recipe is Recipe
7d5d8d0 scripts/lib/bsp/engine: trailing whitespace cleanup
dfeda17 scripts/lib/bsp/engine: fix path separator
d482d84 maintainers: remove gtk-theme-torturer and gnome-mime-data
d0d85a4 bitbake: bb/fetch2: Move export_proxies function from wget to utils.
7226ce2 glibc-locale: fix QA warning
4a2f42f formfactor: add machconfig for Beaglebone
eb53c54 sstatetests: Fix after change to sstate populate_lic SWSPEC
a43b9ef gstreamer1.0-plugins-base: move freetype dependency into 1.6.3 recipe
fb4f05b gstreamer1.0-plugins-base_git: update to git master 1.7.1-79-g6414289
fc81c80 gstreamer1.0-plugins-bad_git: avoid including <sys/poll.h> directly
3f02474 gstreamer1.0-plugins-good_git: avoid including <sys/poll.h> directly
9b0a74a gstreamer1.0: avoid including <sys/poll.h> directly
f9e565e gmp_4.2.1: fix build for MIPS
6d570c8 gmp.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5
3aecdd9 gmp: move BBCLASSEXTEND = "native nativesdk" from gmp.inc into 6.1.0 recipe
263a65d gmp: move SRC_URI out of gmp.inc + minor reformatting
aacae25 image_types.bbclass: Embed IMAGE_NAME in ubinize config file
9c0d4ec toolchain-scripts: drop PYTHONHOME
6560f80 python: set PYTHONHOME for nativesdk
92ae4e2 gcc: musl related fixes for ppc/secure-plt and gthr
9e5222c gcc: Assume libssp and dl_iterate_phdr on musl
281bd41 security_flags: wipe security flags for gcc/glibc and related libraries
61a5875 security_flags: use -fstack-protector-strong
a07f2fd security_flags: ensure security flags only apply to target builds
8d57d1d gcc: Fix build on musl with -fstack-protector
eb134c6 isoimage-isohybrid.py: fix cpio working directory
8bedf76 glib-2.0: use the system libpcre
1ae132e libpcre: enable unicode properties by default
3adb8d5 python3: remove optimize by default patch
1df1ac9 security_flags.inc: don't do -pie for syslinux
562c75c neon: convert to PACKAGECONFIG
6228cf8 bitbake: toaster: reinstate ID on edit columns button
916c73d bitbake: cooker: shutdown cooker parser on shutdown
8857498 bitbake: fetch2/osc: Clean up old variable syntax
54da829 bitbake: fetch2/osc: Remove hardcoded url
c57ba52 cross-localedef-native: add ABI breaking glibc patch
0cc825f uninative: Improve error handling
576a248 patchelf: Add patch to handle large files
bbdbe00 package_manager.py: fix python indentation bug (opkg)
ea40a0b populate_sdk_ext: Make populate_sdk_ext depend on sdk_extra_conf
4f7656a populate_sdk_ext: Add support for a "minimal" type
71bb332 populate_sdk_ext: Don't set sdk_update_targets in the config
5b7a43e toolchain-scripts.bbclass: Use PYTHONPATH instead of PYTHONHOME
f1f8447 copy_buildsystem.py: Pass the nativelsb argument to gen-lockedsig-cache
b130805 gnome-mime-data: remove
12d5fa8 gtk-theme-torturer: remove from oe-core
659d755 openssl.inc: drop obsolete mtx-1 and mtx-2 over-rides
32b498c scripts/devtool: Add getVarFlag expand argument
ed5daa1 bitbake.conf/native/nativesdk: Set PKG_CONFIG_SYSTEM_ at top level
8fa2d52 pango: unset LDFLAGS when building gen_all_unicode
edfaa04 pango: merge bb and inc
00ccf51 e2fsprogs: Ensure we use the right mke2fs.conf when restoring from sstate
66a6ec2 nativesdk: Set PKG_CONFIG_SYSTEM_ variables
34e95b0 local.conf.sample.extended: Document HOW-TO enable systemd or busbox for init system
077d32e local.conf.sample: Remove trailing whitespaces
6ae662a bitbake: parse/ast: Mark anonymous functions as python functions
9913fd8 bitbake: codeparser: Improve handling of data.expand() dependencies
4628fe1 bitbake: lib/bb: Add expansion parameter to getVarFlag
b98866d bitbake: fetch2/gitsm: Fix when repository change submodules
390c2c1 bitbake: data_smart: Add missing expand parameter to getVar call
56454f6 bitbake: bitbake: prserv: do not clear umask when daemonizing
abf8a8f bitbake: bitbake: prserv: SIGTERM handling hung process
be032fc bitbake: bitbake: prserv: -wal and -shm sqlite lost when daemonizing
1e95ebd poky-tiny: Use musl for default system C library
6594bd5 maintainers.inc: Set me as Maintainer of QEMU.
86851d5 insane: Fix populate_sysroot sanity test path
d09a25e socat: upgrade to 1.7.3.1
fad264b libffi: move from recipes-gnome to recipes-support
d3753dd libffi: ensure sysroot paths are not in libffi.pc
c72614b syslinux: remove LDFLAGS manipulation
8ad11fc lttng-tools: Fix ptest installed la files
66ed16b gnutls: update 3.4.8 -> 3.4.9
149cb17 python-distutils: add missing dependency on python-email
3473962 nss-myhostname: Fix build on musl
42e37d7 linux-firmware: update to latest revision 52442afee
ce1bed7 license.bbclass: add LICENSE_CREATE_PACKAGE to perform_packagecopy vardeps
e43504b i2c-tools: point SRC_URI at Yocto source mirrors
2d7622c gnutls.inc: allow libidn support to be controlled via PACKAGECONFIG
60ebe1c gnutls.inc: add gmp to DEPENDS
935aa96 gnutls.inc: minor formatting improvements
3fa1c54 Revert "kernel/kernel-arch: Explicitly mapping between i386/x86_64 and x86 for kernel ARCH"
0b82af2 wic: isoimage-isohybrid: check for syslinux-native
9699441 formfactor: add machconfig for qemumips64
4701dc9 ncurses: use closing curly brackets in FILES_${PN}-tools variable
9d9f233 util-linux: Change ALTERNATIVE_PRIORITY above busybox
8f2306c mktemp: lower the priority of standalone mktemp package
6251846 libxsettings-client: drop obsolete disable_Os_option.patch
7894633 wic: default to empty bootloader config
090fb51 copy_buildsystem: add ability to exclude layers
8dc600f toaster.bbclass: reinstate scan for artifacts in the sdk directory
eee675b toaster.bbclass: attach image file scan postfunc to do_image_complete
0c0b072 meta: add ASSUME_PROVIDED dependency on wget-native for http fetches
f926610 gtk+3: Tweak getVar to use True, not 1
7fa6eeb classes/lib: Add expand parameter to getVarFlag
252e645 python-pycurl: remove unnecessary exports
9fd214d sstate: Fix SSTATE_SWSPEC only used by populate_lic tasks
4ea6a64 package.bbclass: Add data expansion to do_split_packages()
6ab5001 busybox/gtk/perl/base-passwd: Ensure data is correctly expanded
e8860f7 ref-manual: Fixed typo in FAQ 14.15 section.
9d2925e ref-manual: Updated FAQ entry regarding Proxy for SOCKS
29a44da ref-manual: Fixed type in LICENSE_CREATE_PACKAGE variable description
4181e58 ref-manual: Updated warning regarding libexecdir
0d8bd7d ref-manual: Added description for LICENSE_CREATE_PACKAGE variable.
6aca5b8 ref-manual: Added remove-libtool class
5e2201e toaster-manual: Updated the "Installation" to have TOASTER_DIR information
3aa162a p11-kit: fix packaging warnings
60c9759 piglit: don't use /tmp to write generated sources to
b33e440 libical: Work around hardcoded paths in pkgconfig file
a131b6e documentation.conf: align the documentation for DEBUG_OPTIMIZATION and FULL_OPTIMIZATION with bitbake.conf
974a8c0 pciutils: Explicitly set EXTRA_OEMAKE as required
2d3e6f3 openssl: Explicitly set EXTRA_OEMAKE as required
b07e161 dbus: add user sessions support
877eae1 dbus: use ${systemd_system_unitdir}
6010088 populate_sdk_ext: Add SSTATE_MIRRORS to config blacklist
70ec867 insane: add test for -dev packaging containing real libraries
38d6f1f python3: set INSANE_SKIP as libpython3.so is a trampoline library
4ac4023 p11-kit: fix module packaging
9a27010 libnl: package the libnl-cli modules in libnl-cli
111af1d remove-libtool: add new class
333dce4 gtk-immodules-cache.bbclass: fix immodules-cache path
b1e41f4 Revert "matchbox-keyboard: export GTK_IM_MODULE_FILE location"
ac1f311 directfb: use Yocto source mirrors for SRC_URI
4d80f7a gcc-configure-common.inc: drop --enable-target-optspace from configure
654eddc machine/include: drop tune-cortexm*.inc and tune-cortexr4.inc
322015a liboil: drop recipe from oe-core
41d50f9 boost: Fix build on soft-float ABI arm systems
07a91a6 libnss-mdns: Check for nss.h before using
1b34f55 db: Use cross libtool
64089c6 libtool-cross: Unset pre|post dep objects
457f417 docbook-xsl-stylesheets: create a link for easy refer
1ba62f9 pth: Remove dead code
a4a5d1f3 bitbake: cooker, bitbake-worker: Fix spelling of "received"
8f6b9c7 bitbake: cooker: Only start as many parse threads as we need
602da7c bitbake: knotty: Don't show errors for universe provider issues
1dd2d76 linux-yocto: Adds new genericx86 and genericx86-64 SRCREVs for kernel 4.4
b8fa9d3 poky: Add poky-world-exclude.inc and add qwt-as
5503a22 sstate: Revert using -m option to tar in sstate
6023798 libarchive-native: Disable libxml2 support
b09b054 pcmciautils: Fix makefile race
89df5f1 binutils: Use target provided zlib
c85c54f binutils: Upgrade to 2.26
ba2fdcd native.bbclass: Set CXXFLAGS from BUILD_CXXFLAGS not BUILD_CFLAGS
2394b15 gstreamer1.0-plugins-base: Add video crop supporting when convert frame
2724908 gstreamer1.0-plugins-bad: Fix memory leak of navigation thread
db81fc9 lib/oe/package_manager: remove package feed lists
c43da12 externalsrc: use shared CONFIGURESTAMPFILE if B=S
c6b8227 Make sure that the directory for CONFIGURESTAMPFILE exists
ca06179 autotools.bbclass: use oe_runmake instead of ${MAKE}
f4f9f2f gcc, qemuppc: Explicitly disable forcing SPE flags
691f7e4 pango.inc: misc dependency fixes
70efb8d pango.inc: limit ptest specific do_compile_prepend to target builds
c1273d4 systemtap_git.inc: do not immediate expand SELECTED_OPTIMIZATION
e631be2 glibc.inc: do not immediate expand SELECTED_OPTIMIZATION
770d9ff mkelfimage: fix target cflags leaks to host
c936bf0 base: Move COMPATIBLE_MACHINE out the scope of SOURCE_MIRROR_FETCH
3072361 bitbake: bitbake: BBUIHelper: Remove function findServerDetails
28c041c bitbake: fetch2: Simplify logic in verify_checksum()
5375e64 bitbake: bitbake: Set process names to be meaninful
5b234d1 bitbake: utils: Add ability to change the process name
0b06924 bitbake: data.py: avoid double newlines at the end of functions in emit_var()
68600ae bitbake: build.py: minor shell_trap_code() formatting tweaks
423a264 conf/distro/poky.conf: use example.com for connectivity check
6c058ce curl: update 7.46.0 -> 7.47.0 ( CVE-2016-0754 CVE-2016-0755 )
adbe63d openssl: update 1.0.2e -> 1.0.2f ( CVE-2016-0701 CVE-2015-3197 )
85b6679 autotools.bbclass: don't create subshell to delete configure scripts
2f1bcc1 sstate: Add back packagedata on packagedata dependencies
346b225 libical: update to 2.0.0
b696bb3 kexec: package kdump init script/configuration file correctly
51cebbf connman: fix crash with iptables 1.6
7f54fab autotools_stage.bbclass: remove it
07c4bc1 gdb-common.inc: add PACKAGECONFIG for readline
5869e35 tzdata: update to 2016a
c9cc707 tzcode: update to 2016a
aff2f58 glibc-testing.inc: drop pruning of PATCH_GET from the testglibc script
dfb9d41 gcc-cross.inc: drop pruning of PATCH_GET from the testgcc script
9e7d929 bitbake.conf: stop exporting PATCH_GET = "0"
5410aff sstate: Improve handling of useradd dependencies
9823802 gtk-icon-utils-native: Drop problematic dependency
6c04e0d glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5
83476b5 glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch
fab76ae glib-2.0: refresh configure-libtool.patch
593dcd4 systemd: fix systemctl enable script for template units
3c90507 glib: use bash-completion.bbclass
d88ed5d kmod: use bash-completion.bbclass
0f3780c git: use bash-completion.bbclass
9d20661 util-linux: use bash-completion.bbclass
0e5b0bf dbus-glib: use bash-completion.bbclass
9cddc0a bash-completion.bbclass: add class
ddb786c bash-completion: move in recipe from meta-oe
74e2f68 ffmpeg: add a recipe, and remove the libav recipe
eb7e554 lib/oe/patch: Make GitApplyTree._applypatch() support read-only .git/hooks
3ed566e gcc: fix hidden weak symbols by removing buggy gcc patch
51d9ba6 dpkg: fix CVE-2015-0860
f80d16e qemu.bbclass: clarify QEMU_EXTRAOPTIONS
3dca294 pango.inc: drop obsolete dependency on qemu-native
a16e9a2f dbus: upgrade to 1.10.6
7081458 buildhistory: fix the check for existence of a git repo
d74325e connman: tidy up connman-conf usage
79f4495 connman-conf: convert to systemd oneshot
5c35883 bitbake-whatchanged: avoid double do_ task name prefix
7881c02 netbase: add ipv6 host to /etc/hosts
93fcee6 linux-yocto/4.4: CVEs and preempt-rt update
07c182f linux-yocto/4.1: update to 4.1.16
7003698 gstreamer1.0-plugins-bad: fix compiler warnings with -Os in 1.7.1
6e90145 gstreamer1.0-plugins-good: fix compiler warnings with -Os in 1.7.1
3cd70c8 libsoup-2.4: add glib-2.0-native dependency
d5b3b97 libtirpc: remove stray .orig file from Use-netbsd-queue.h.patch
209066c ptest-runner: Add ptest-runner_2.0 recipe.
4953e26 musl: Upgrade to tip of tree
52413d0 libdrm: Refresh patch to match upstream submission
66e215f fts: Correct LIC_FILES_CHKSUM
be4c446 pth: Delete
df95988 elfutils: Fix build with uclibc/musl
047ad2c grub: Backport fix for largefile detection/use
956be0c oeqa/runtime/rpm: be more verbose if test_rpm_query_nonroot fails
3b5288f libc-package.bbclass: add LOCALE_UTF8_IS_DEFAULT
4f3ef90 ref-manual: Updated the BBMASK variable description.
b2b7214 dev-manual: Restored ptest-runner2 to ptest-runner
d484e58 ref-manual: Removed obsolete do_deploy statement from "Shared State"
7705b87 toaster-manual: Updated instructions for production setup.
4b4a8a6 ref-manual: Updated the SDK figure.
d7481ce ref-manual: Added do_image and do_image_complete tasks
d39e9d1 ref-manual: Rewrite of "Image Generation" and devtool text.
1e7735e ref-manual, mega-manual: Updated the Image Creation figure
fded4fa ref-manual: Updated configuration of auto.conf in closer look
9f192c8 dev-manual: Updated the devtool help examples.
4bbd39d dev-manual: Grammar fix to kickstart section.
75078dd dev-manual: Updated wic reference section
9ed7881 poky-ent: Grouped Fedora perl packages for niceness
3ac0416 local.conf.sample.extended: Update the info about BBMASK
d61d290 bitbake: bitbake-user-manual-ref-variables: Update the help for BBMASK
a948f52 bitbake: cooker: Allow BBMASK to contain multiple regular expressions
e82101a bitbake: bitbake-user-manual-metadata: Updated 'dir' flag
100d6c2 bitbake: bitbake-user-manual: Updated the example BitBake directory
11be341 documentation.conf: Update the help for BBMASK
3d2c0f5 cmake: update to 3.4.2
4364850 at-spi2-core: update to 2.18.3
c763940 webkitgtk: update to 2.10.5
1e95815 libsecret: update to 0.18.4
9259a43 freetype: update to 2.6.2
5ec6dbb gdk-pixbuf: update to 2.32.3
9c84fbc glib-2.0: update to 2.46.2
bd7278c gtk+3: update to 3.18.6
d609cd5 gtk+: update to 2.24.29
6197313 gtk-icon-utils-native: update to 3.18.6
1556f0e libsoup-2.4: update to 2.52.2
dff038a waffle: update to 1.5.2
89bd19f vala: update to 0.30.0
6c02099 rxvt-unicode: update to 9.22
245af2b btrfs-tools: Disable backtrace on musl
fa01d37 bsd-headers: Fix LICENCE and dev package RDEPENDS
05e11a5 gdb: Fix build failures on musl
72c1aa2 ltp: Add rdep on ldd
1d0332d argp-standalone: Fix build when S != B
9f22898 bitbake: fetch2/wget: fallback to GET if HEAD is rejected in checkstatus()
d11cc29 busybox: fix stop -vs- start typo in rcS script
9f4b088 mtools: keep v3.9.9 recipe in sync with the v4.0.18 version
2c14be3 gen-lockedsig-cache: fix bad destination path joining
9dea876 distutils-common-base: do not set PACKAGES - use defaults from bitbake.conf
4ead707 insane: remove unused variable assignment
44e9c3b meta: fix capitalisation in Upstream-Status
06b4572 pixman: only check even upstream versions
0f74387 gcr: check only even upstream versions
a2848ee avahi: Add patch to fix Win10 mDNS issues
04ef34f xf86-input-libinput: initial add 0.16.0
8a2dfa1 image.bbclass: check INITRAMFS_MAXSIZE
962cc37 systemd: make TEST_DIR configurable
9967746 bind: update to 9.10.3-P3
cac47db uninative: handle UNINATIVE_URL being file:///
9995814 uninative: fix path to patchelf-uninative
2495dfa scripts/wipe-sysroot: also delete uninative sysroot
bb97157 meta/lib: new module for handling GPG signing
aadb879 devtool: extract: use the correct datastore for builddir
fa801e7 busybox: backport upstream truncate open mode fix
6996b26 gstreamer1.0-plugins-base.inc: drop obsolete dependency on liboil
1c4a8cc e2fsprogs: disable blkid
0de8766 pango.inc: drop obsolete FULL_OPTIMIZATION over-ride
89a7ed5 devtool: add configure-help subcommand
84720c8 devtool: properly handle bb.build.FuncFailed when extracting source
c3f0f7b devtool: add: warn if modified recipe found in attic directory
e559b66 devtool: build-image: allow specifying packages to add to image
e00eac8 devtool: move edit-recipe to a separate module
6720bda image: Don't create tasks with '.' in the name
88ca227 rootfs-postcommands: fix allow-empty-password on read-only rootfs
fdac363 kernel: Clean DEPLOYDIR before do_deploy runs
c2231de gcc-cross-canadian: Add missing DEPENDS on virtual/${HOST_PREFIX}gcc-crosssdk
5fdedb6 libtirpc: Drop unneeded xz-native dependency
7a98fb7 libuser: Drop unneeded xz-native dependency
72f98ba bitbake: toaster: Update UI test runner
c192bd6 Revert "xz: Allow to work with ASSUME_PROVIDED xz-native"
6df607b acpid: upgrade to 2.0.26
7a52f67 build-perf-test.sh: add eSDK testing
5c367ec build-perf-test.sh: more generic timing function
44fee2b python3-pip: Upgrade to 8.0.0
9d95a9d orc: update HOMEPAGE
0c1c93e gstreamer1.0-plugins.inc: drop obsolete ${S}/po/Makefile.in.in workaround
be145ad busybox: Add support for busybox-init
716fa93 pulseaudio.inc: drop obsolete dependency on liboil
55bfaa2 sqlite3: update 3.10.0 -> 3.10.2
6bb1dd1 sqlite3.inc: add PACKAGECONFIG to support building against libedit
39f6a9e sqlite3.inc: dynamically link the sqlite3 command-line utility
9b2835e sqlite: formatting improvements, move more stuff into sqlite3.inc
89ed462 sqlite3.inc: drop obsolete config_BUILD_CC, etc exports
6188419 sqlite3.inc: fix readline PACKAGECONFIG
939de8d sqlite3: fix the parallel build fix patch
a304b82 weston: Add missing DEPENDS on wayland-native
4a5458f bitbake: fetch2: Don't show checksum warnings if a single checksum was supplied
e66599f uninative: Fix conflicts with normal sysroot
4833bee insane: Drop do_stage test
861c916 populate_sdk: Use pixz instead of xz
a1c35f3 lib/oe/sdk: Partially revert "sdk.py: fix conflicts of packages"
29c5eda uninative: Add fetch capability
b54fa25 pixz: Add 1.0.6
d47572d xz: Allow to work with ASSUME_PROVIDED xz-native
0aeb33f lib/oe/package_manager: prevent testing an undefined variable
c1f4e92 recipetool: create: better fix for fetch error handling
10c8d14 recipetool: create: fix extraction of name from URLs ending in /
b307e0a recipetool: create: extract SRC_URI from local git repositories
50e40fc devtool / recipetool: support specifying a subdirectory within the fetched source
7e1691d recipetool: create: strip quotes from values extracted from CMakeLists.txt
477fa84 gen-lockedsig-cache: copy correct native sstate into ext SDK
204e4ab toolchain-shar-extract.sh: improve behaviour when xz is not installed
979c8fb classes/populate_sdk*: add dependencies on script files
f220abc classes/populate_sdk_ext: drop ext-sdk-prepare.py when installing
b435225 devtool: add sdk-install subcommand
44d1a2a devtool: sdk-update: improve SDK update process robustness
3360baa devtool: sdk-update: improve temp directory handling
d193531 devtool: build: ensure pkgdata is written out
d3a4f72 classes/populate_sdk_ext: add option to bring in pkgdata for world
a9dfced linux-libc-headers: Port patches for linux-headers for musl
3cffa6d libsolv: Update to 0.6.17+
d9134cf glib-2.0: Fix locale location on musl
527cd95 syslinux: Set LD to avoid using build host ld
136db70 binutils: Fix gold linking errors due to unresolved R_ARM_MOVW_ABS_NC
704e342 puzzles: Silence warning on arm with clang
bee65f9 eglinfo: Fix build on raspberrypi
6296c0f mdadm: Fix build with musl
67eef11 gpgme: Define __error_t_defined on musl
368e838 console-tools: Fix header inclusion when not using glibc
5a8c935 uclibc: Update to 1.0.11
1113d58 unfs3: Depend on libtirpc when building on musl
2ecfc02 guile: Fix build with musl
2df08b8 bsd-headers: Package cdefs.h
29deaf0 musl: Create ld.so as a relative symlink
2d028b3 fts: Fix linker hash-style option
8dd1aa8 dosfstools: Correct cross-compile CFLAGS and fix build with musl
21550d1 nss: Undefine HAVE_SYS_CDEFS_H
92e6a7a apmd: Fix build with musl
5d661c5 pcmciautils: Fix parallel build and include sys/types.h
86795ff kexec-tools: Define _GNU_SOURCE for getting loff_t definition
ff8006f systemd: Skip parsing on musl based targets
f2856a1 oprofile: fix build with musl
226c450 portmap: Point to tirpc headers and libraries on musl
5512c2f nfs-utils: Disable tcp-wrappers for musl
06d0204 bsd-headers,musl: Add recipe for bsd missing features
c2c9202 tcf-agent: Implement canonicalize_file_name() for musl as well
f294813 chkconfig: Avoid using caddr_t
b2aca09 nspr: Drop older glibc code
c0976fc irda-utils: Fix header inclusions
a3f9721 iproute2: Fix build with musl
22333f0 libuser: Fix build when secure getenv is not there
ea9dc99 iputils: Use member based initialization for mrghdr struct
b207868 pax: Fix build with musl
1076499 tar: Fix build for musl based targets
e451023 rt-tests: Fix build with non-gcc compilers
68da390 webkitgtk: Fix build with clang/musl
da81635 console-tools: Include sys/types.h for u_char and u_short defs
205a07a sysklogd: untangle header inclusion maze
9f40dba babeltrace: Add missing header for MAXNAMLEN define
2458850 libunwind: backtrace APIs are glibc specific
abdfacb apt: Add support for building for musl targets
ec187d3 puzzles: Zero'ise structs before use
3cd0a8c dpkg: Add musleabi to known architectures
aaa8516 xinetd: Fix build with musl
93fb408 watchdog: Fix build with musl
7509ffd gzip: Fix build with musl
1d28cbc directfb: Fix build with musl
7b6b312 net-tools: Link with libintl on uclibc
ee1bfdb parted: Fix build with uclibc
ed5da2a mtools: Fix build with uclibc
5384f08 gnutls: Link with libuargp on uclibc
493e557 guile: Fix build with uclibc
1636f6f packagegroup-self-hosted.bb: Move glibc-gconv-ibm850 to glibc only case
3e7d7ab util-linux: Fix ptest builds on musl
77825f8 gnutls: Link with libargp on musl and depend on argp-standalone
1a6fe71 argp-standalone: Add recipe
a7d780c gdk-pixbuf: Fix latent build issue exposed by musl
f2cf5d3 xserver-xorg: Fix build with musl
b8de631 libcgroup: Add dependency on fts when building on musl
87c3e98 connman: include config.h for HAVE_STRUCT_IN6_PKTINFO_IPI6_ADDR
cc55fc7 fts: Add recipe
6e3950b tcp-wrappers: Fix build with musl
68f88a5 ppp: Fix build with musl
4972edd blktrace: Include <sys/types.h for dev_t
d629fa1 powertop: Include right headers for timval struct
063dc38 update-alternatives: when warning about alt_link==alt_target, say what PN
6baafa1 python-setuptools: Unify and upgrade python-setuptools and python3-setuptools to 19.4
f0e500e gstreamer1.0-libav: update git recipe to 1.7.1
90cbdfb gstreamer1.0-plugins-ugly: update git recipe to 1.7.1
6752484 gstreamer1.0-plugins-bad: update git recipe to 1.7.1
ad8f201 gstreamer1.0-plugins-good: update git recipe to 1.7.1
2ca9f20 gstreamer1.0-plugins-base: update git recipe to 1.7.1
3c7f2b8 gstreamer1.0: update git recipe to 1.7.1
7c810d0 gstreamer1.0-libav: update 1.6.2 -> 1.6.3
a4b8e9a gstreamer1.0-plugins-ugly: update 1.6.2 -> 1.6.3
8170e06 gstreamer1.0-plugins-bad: update 1.6.2 -> 1.6.3
497ebc9 gstreamer1.0-plugins-good: update 1.6.2 -> 1.6.3
3d87902 gstreamer1.0-plugins-base: update 1.6.2 -> 1.6.3
1e256ee gstreamer1.0: update 1.6.2 -> 1.6.3
dacf2aa gst-plugins-package.inc: drop perl RDEPEND for XXX-apps packages
676275f gstreamer1.0-plugins.inc: don't set base SRC_URI via python
852f098 gstreamer1.0-plugins.inc: drop obsolete lib-link.m4 workaround
a32ac26 gstreamer1.0-plugins-bad.inc: update hls dependency gnutls -> nettle
97e0752 gstreamer1.0-plugins-bad.inc: don't set ${S} or apply version specific patch
78e9361 gstreamer1.0-plugins-good.inc: remove duplicate --disable-examples
0edabfd gstreamer1.0-plugins.inc: convert GSTREAMER_1_0_DEBUG to a PACKAGECONFIG
81cd227 gstreamer1.0-plugins.inc: add missing glib-2.0-native dependency
a0b1e66 gstreamer1.0.inc: add missing glib-2.0-native dependency
e5fb79d gstreamer1.0-rtsp-server.inc: minor formatting improvements
434aa8e gstreamer1.0-omx: minor formatting improvements + update HOMEPAGE
69bcd33 gstreamer1.0-libav: minor formatting improvements + update HOMEPAGE
1d6e61a gstreamer1.0-plugins-ugly: minor formatting improvements
c45ce26 gstreamer1.0-plugins-bad: minor formatting improvements
c1ea981 gstreamer1.0-plugins-good: minor formatting improvements
beb8091 gstreamer1.0-plugins-base: minor formatting improvements
61f30b4 gstreamer1.0-plugins.inc: minor formatting improvements
981145a gstreamer1.0: minor formatting improvements
9f1a943 gst-plugins-package.inc: minor formatting improvements
9e08b69 gst-player: minor formatting improvements
a8ed2c8 valgrind: remove unused valgrind-remove-rpath.patch
e24123d emptytest: exclude from world builds
6808035 build-appliance-image: bump version to 14.0.0
eb418c3 insane.bbclass: fix package_qa_walk()
e185004 insane.bbclass: print all the QA messages
95fa36e weston: upgrade 1.8.0 -> 1.9.0
1bc0c89 wayland: upgrade 1.8.1 -> 1.9.0
03dae8e glib-2.0: fix the ptest
68c5e6d insane.bbclass:buildpaths: ignore ipkg/dpkg's CONTROL dir
258676b sstate: display the sysroot name when cleaning for clarity
f35b2e2 bitbake: set default libexecdir to $prefix/libexec
40f0c2d gawk: fix libexecdir/libdir/BPN confusion
2458f41 mesa: update SRC_URI
fdb12f9 e2fsprogs: set PV to 1.42.99+1.43+git${SRCPV}
9cf1ec0 valgrind: avoid neon for targets which don't support it
b191f58 valgrind: re-enable ARM intdiv and vcvt_fixed_float_VFP tests
b0b3412 valgrind: let valgrind determine its own optimisation flags
92abb5f meta/files/toolchain-shar-relocate.sh: Detect different python binaries and select one that exists.
924e2c3 python-nose: upgrade to 1.3.7
02440b5 python-native: Make python-native also RPROVIDE python-unittest-native
b7ca05d linux-libc-headers: update to 4.4
f73ee59 libpng12: upgrade to 1.2.56
3a59486 libpng: upgrade to 1.6.21
63a49f8 libtirpc: remove redundant va_list patch
55a8df2 perl: Upgrade to 5.22.1
a840588 oeqa/selftest/signing: use temporary rpmdb
65c1de9 kexec-tools: inherit update-rc.d
ba837f1 autotools: don't output the full config.log on configure failure
3e3cb62 bitbake.conf: Remove horrible variable expansion hacks
b963efb mesa: add missing wayland-native build dependency
9dd6c81 maintainers.inc: Correct maintainership for several packages
bd1a534 bitbake: toaster: run bitbake server with --read option
76a281c bitbake: taskdata: add the ability to access world targets list
11a1f49 bitbake: cache.py: check existence before add to cachedata.rproviders
05c1775 bitbake: taskdata.py: add RuntimeProviders to close matches
cf9cb65 bitbake: data_smart: Don't show exceptions for EOL literals
b80219e udev: Add 2 patches to support 4.4 kernel
1013385 gcc-runtime.inc: provide libquadmath
60b237f kexec: update supported architecture list
92a0032 strace: update 4.10 -> 4.11
0aa8169 strace: fix ARCH definition in tests/Makefile
2408149 strace: remove need for git-version-gen script
9ca6a5f strace: fix --disable-aio configure option
dd90f32 strace: drop unnecessary dependency on acl
aadae7b libnewt: Fix linking error due missing symbols
571289d lib/oe/package_manager.py: Remove list() from PkgsList class
6ebda8e lib/oe/rootfs: Use list_pkgs() instead of list()
03075f6 lib/oe/utils: Add function format_pkg_list()
c708411 lib/oe/package_manager: Add list_pkgs() to PkgsList class
113e136 python3: Minor upgrade 3.5.0 -> 3.5.1
918149d python-numpy: upgrade to 1.10.4
eae7584 swig: upgrade to 3.0.8
21f7677 python-scons: upgrade to 2.4.1
7721652 python-pycurl: upgrade to 7.21.5
2ef401f python-mako: upgrade to 1.0.3
2a608cc python-setuptools: Upgrade to 19.2
6395bc8 python3-setuptools: upgrade to 19.2
40738af python: Upgrade 2.7.9 > 2.7.11
35855a0 wic: pylinted ksparser module
e3b3bcf wic: add help for 'include' command
bfaabe5 wic: move parts of canned .wks into common.wks.inc
50a3dc5 wic: implement search of includes
15ea180 wic: refactor get_boot_config
d304162 wic: ksparser: add support for include
3fc6aaa wic: do not remove build dir in source plugins
8d34eea wic: use unique partition number
43b4058 wic: move wks parsing code to KickStart._parse
3860640 nss: update to 3.21
ea39ad0 libjpeg-turbo: fix upstream version check (sort of)
48a8a89 libical: fix upstream version check
c6f71c5 gnutls: update to 3.4.8
7a80f84 sysstat: fix upstream version check
2aabf9a pbzip2: update to 1.1.13
77aee28 ncurses: fix upstream version check
56e4ff6 libsolv: fix upstream version check
d46bc77 e2fsprogs: fix upstream version check
0436e3f build-appliance-image: bump version to 14.0
a206a19 btrfs-tools: update to 4.4
a1790bc bootchart2: update to 0.14.8
68c7113 poky.conf: Delete BB_SIGNATURE_HANDLER settings
0916235 rpm: remove bashisms: [ x == x ] -> [ x = x ]
2dbd61f uclibc: remove a use of immediate expansion and oe_filter_out ()
32eeb00 gcc-runtime: switch to removal override syntax to modify CXXFLAGS
c886a78 bitbake: tests/codeparser.py: Add filename/lineno flags to test variable
f130033 bitbake: toaster: write variables to toaster.conf
1835768 sstate: replace verbose manifest removal with a single count
d4c721a libdrm: Upgrade 2.4.65 -> 2.4.66
b5508a8 slang: Add dependency on ncurses
27b2df2 valgrind: make it explicit that valgrind supports armv7a and above
5dc38a3 sign_rpm.bbclass: fix task dependencies
27c39c4 opkg-utils: store alternatives in nonarch_libdir
77fde15 security_flags.inc: remove obsolete workarounds for curl
31ce027 cups: update systemd support
a4b48c2 coreutils: Add xattr PACKAGECONFIG
7a0b1c1 oeqa/runtime/parselogs: use -F to search fixed strings for grep
b8e11e2 libinput: Upgrade 0.21.0 -> 1.1.4
a9f2e87 postinst-intercepts: always use set -e
de0848f maintainers: mark Khem as nominal owner for uclibc
3235f5e formfactor: remove unused beagleboard configuration
6c64700 alsa-state: remove beagleboard configuration
f0d47a6 bitbake: Revert "runqueue.py: Ensure one setscene function doesn't mask out another which needs to run"
9e867ef sstate: Add packagedata to list of tasks not to recurse
5e881c1 classes/populate_sdk_ext: fix task dependency regression
2e9f092 image: Handle image types containing '-' correctly
0612ca4 oe-selftest: devtool: fix test_devtool_add_library if python was built first
c1492c4 recipetool: create: add a couple more license checksums
2c8c9fe recipetool: create: add basic support for extracting dependencies from cmake
3eb397f recipetool: create: force GL libraries to virtual/*
726dbda recipetool: create: move dependency mapping code to RecipeHandler
788e4bb recipetool: create: fix overzealous mapping of git URLs
ece0a2e recipetool: create: support additional autoconf macros from autoconf-archive
903d471 recipetool: create: detect flex/bison dependency
a66f4ac recipetool: create: pick up boost macros in configure.ac
dbe91a3 recipetool: create: improve extraction of pkg-config / lib deps
e7bedb9 wic: rename kickstarter.py -> ksparser.py
3bb6ea6 wic: override ArgumentParser.error
d652203 wic: removed unused imports
d2090a6 wic: improve processing of parseing errors
1ed97cc wic: catch KickStartError
bda77fd wic: add custom exception KickStartError
ef211a5 bootimg/image-vm/image-live: Improve image dependencies
0910bc6 image: Always run do_rootfs_wicenv
12e37e7 selftest/buildhistory: Improve test to remove sources of error
05716dd bootimg/image: Enhance bootimg to respect RM_OLD_IMAGE
1c869a9 rootfs-postcommands: Ensure license manifests respect RM_OLD_IMAGE
d27491b image: Ensure we don't expand TMPDIR in image commands
ce8a206 image: Fix instability of do_image_* checksums
fb1654f image: Fix wic environment issues
1da8f52 insane: Start to clean up do_configure_qa code
dd28695 insane: Clean up horrible return value processing code
839fb18 e2fsprogs: fix PV
b1236dc e2fsprogs: add PACKAGECONFIG for fuse
f98e11c bitbake: toastergui: make artifact download more robust
68f3e1e bitbake: toasterui: log OSErrorException metadata events
fb94754 bitbake: toasterui: listen for bb.event.MetadataEvent
a2f23fa openssh: CVE-2016-1907
320a319 license.bbclass: fix license manifest
4339a82 wic/help.py: document requirements for valid fstab generation
d688df8 glib-2.0: add dependency glib-2.0-native back
76e35f1 kernel-yocto.bbclass: move do_kernel_link_vmlinux() into kernel.bbclass
d453fa1 kernel-yocto.bbclass: remove do_kernel_link_vmlinux from SRCTREECOVEREDTASKS
2b92f88 libarchive: Add bsdtar and bsdcpio packages
e246905 toaster.bbclass: Separate artifact dump from image file dump
4f481bc pax-utils: 1.0.5 -> 1.1.4
f9974f2 sqlite3: upgrade to version 3.10.0
cd7910d connman: upgrade to 1.31
b9169b7 python3: add missing dependency on PN-misc to PN-modules
4b4dea7 useradd-staticids.bbclass: Remove unnecessary spaces
4f2c352 useradd-staticids.bbclass: Read passwd/group files before parsing
4cbdb15 useradd-staticids.bbclass: Simplify the logic for when to add groups
b18e40c useradd-staticids.bbclass: Simplify some logic
b689aa0 useradd-staticids.bbclass: Make --no-user-group have effect
c03ea8d useradd-staticids.bbclass: Treat mutually exclusive options as such
af8b005 wic: get rid of 2 getters
2573e28 wic: get rid of set_size and set_source_file setters
5cd222b wic: get rid of get_rootfs and set_rootfs
4d5d5dd wic: get rid of get_timeout getter
26fb2a1 wic: adjust code for new data structure
c827238 wic: remove pykickstart code
c15ea82 wic: use new kickstart parser
f572f44 wic: add kickstart parser module
e5e1905 wic: add partition module
180f170 alsa-lib: 1.0.29 -> 1.1.0
a8c25af matchbox-keyboard: export GTK_IM_MODULE_FILE location
d75cb1f xf86-input-evdev: upgrade to 2.10.1
2283732 menu-cache: upgrade to 1.0.1
ec7e406 libxi: upgrade to 1.7.6
86f3f25 librsvg: upgrade to 2.40.13
72dd806 libgpg-error: upgrade to 1.21
3c02fe0 libevdev: upgrade to 1.4.6
33e9930 libcroco: upgrade to 0.6.11
5b63c44 gsettings-desktop-schemas: upgrade to 3.19.3
dfff167 gpgme: upgrade to 1.6.0
5abb691 u-boot: Update to 2016.01 release
e9280d1 linux-yocto: introduce v4.4 standard/preempt-rt/standard kernel
8c3276e e2fsprogs: 1.42.9 -> 1.43 (master)
b248e55 bitbake.conf: rename python-native-runtime
65d0bfc net-tools_1.60-26.bb: Fix do_patch dependency error
99923fc ncurses: 5.9 0 -> 6.0
44d283a autotools.bbclass: use relative path to run configure script
b2f1de3 glibc-initial.inc: use relative path to run configure
0fe6e2d bitbake: toaster: increase timeout
a5f34bc poky.ent: Added "perl-bignum" package for Fedora
afc6cba dev-manual: Updated "Running ptset" section
ec047ad yocto-project-qs: Updated the "Next Steps" section
57ddbe8 ref-manual: Removed all variables related to "QMAKE"
7814b33 ref-manual: Updates to cull out qt4 stuff.
bf81969 toaster-manual: Updates on how to start Toaster.
798e8b8 bitbake: toastergui: code formatting and clean-up
c4b5011 bitbake: toaster tests: fix Django tests for new ToasterTable pages
88a262c bitbake: toastergui: remove unused views and template code
059a274 bitbake: toastergui: fix error and warning counts for builds
4103e0c bitbake: toastergui: make "Apply" button state depend on filter range
6c2d88f bitbake: toastergui: mute label for filter actions with no records
f08730a bitbake: toastergui: set default visible and hideable columns
112f374 bitbake: toastergui: serialise decimals correctly
e024aab bitbake: toastergui: streamline construction of filter objects
fcb20f9 bitbake: toastergui: ensure filter_value updates
f9c46f5 bitbake: toastergui: don't hide all elements with .col class
eaae82a bitbake: toastergui: convert project builds page to ToasterTable
33b011c bitbake: toastergui: implement "today" and "yesterday" filters
f8d383d bitbake: toastergui: implement date range filters for builds
b929889 bitbake: toastergui: show recent builds on all builds page
1a4b203 bitbake: toastergui: switch off filter highlights when inactive
809046c bitbake: toastergui: refactor ToasterTable filtering
294579b bitbake: toastergui: convert all builds page to ToasterTable
6c12ca7 bitbake: toastergui: use event delegates for hover help elements
ef93dce bitbake: toastergui: switch projects/ view to ToasterTable
417f1d3 bitbake: toaster: check inferred file suffixes against list of known types
c02ee05 bitbake: toaster: move image file suffix list to model
d29e4cd bitbake: toastergui: use ToasterTable for projects page
b1256db openssh: update to 7.1p2
c0e9f2d kernel/kernel-arch: Explicitly mapping between i386/x86_64 and x86 for kernel ARCH
f8508de bitbake: Revert "fetch/git: Change to use clearer ssh url syntax for broken servers"
b567235 image/image-live: Add back IMAGE_TYPES_MASKED support
e914e2a image.bbclass: Handle image base type dependency properly
ad32f65 autoconf: add missing perl-module-file-find to RDEPENDS
d83dfe6 ca-certificates: update to 20160104
4440560 epiphany: upgrade to 3.18.3
dcf54b4 iso-codes: upgrade to 3.64
d7bee35 lighttpd: upgrade to 1.4.39
08c8923 libwebp: upgrade to 0.5.0
cf0aea7 classes/populate_sdk_ext: avoid unnecessary sstate being brought in
ea29bec insane/package: Fix cases where QA errors aren't fatal
2e620a4 classes/populate_sdk_ext: check that extensible SDK prepared correctly
4685c33 classes/buildhistory: save auto.conf and bblayers.conf for extensible SDK
39f6472 classes/populate_sdk_ext: support auto.conf
91877aa classes/populate_sdk_ext.bbclass: handle if local.conf doesn't end with a newline
764c927 util-linux: create util-linux-runuser iff pam in DISTRO_FEATURES
95dce70 rsync: 3.1.1 -> 3.1.2
38aa0fc less: 479 -> 481
4cb2269 iputils: s20121221 -> s20151218
fe47dd7 wget: 1.17 -> 1.17.1
79886e9 git: 2.5.0 -> 2.7.0
d3e16b8 file: 5.24 -> 5.25
3549abc autogen-native: 5.18.5 -> 5.18.6
fb14627 curl: upgrade to 7.46
eaf88d7 xz: upgrade to 5.2.2
8516ff7 sysstat: upgrade to 11.2.0
ae73be1 at: upgrade to 3.18
21efab7 kmod: upgrade to 22
c88efae resolvconf: upgrade to 1.78
6729889 pciutils: upgrade to 3.4.1
edd319c gnupg: 2.1.7 -> 2.1.10
78b58b8 help2man-native: 1.47.1 -> 1.47.3
ac0e0d5 man-pages: 4.02 -> 4.04
1e0cbb9 libgcrypt: 1.6.3 -> 1.6.4
372c23d xmlto: 0.0.26 -> 0.0.28
aaafe33 elfutils: 0.163 -> 0.164
38901a7 dhcp: 4.3.2 -> 4.3.3
ea05e05 image.bbclass: Unconditional includes of populate_sdk_ext fails
c08f272 tcmode-default.inc: Fix preferred provider nativesdk-sdk_prefix-libc-initial
5d2f783 dhcp: search libxml2 for bind
b69652d tzdata: remove bashism
7c7c249 harfbuzz: update 1.1.2 -> 1.1.3
84623dc libpostproc: duplicate armv7a over-rides for armv7ve
1744198 libav.inc: duplicate armv7a over-rides for armv7ve
102dfa1 gcc-configure-common.inc: duplicate armv7a over-ride for armv7ve
b08dfb5 subversion: Upgrade 1.9.2 -> 1.9.3
d6fae0c lttng-ust: Upgrade to 2.7.1
a9cc9b5 lttng-tools: Upgrade to 2.7.1
6b02575 lttng-modules: Upgrade to 2.7.1
a378430 gdb: upgrade to 7.10.1
92cc02f linux-yocto: Update Genericx86* BSPs to 4.1.15
da43a56 bitbake: Revert "fetch2/local.py: avoid using PREMIRROR"
96a34e7 conf/distro/poky-tiny: correctly disable python in opkg-utils
1724ffd bitbake: fetch2/git.py: Add missing "errno" module import.
74fa824 bitbake: bitbake: clean up stamp-base related codes
f3f769a local.conf.sample: add qemumips64
43328fe bitbake: runqueue: Fix setscene task dependencies
7b905ca bitbake: toaster: settings Add uid to the toaster cache dir
dff7a27 bitbake: toaster: show 'satisfied via' text for reverse deps
89f4932 bitbake: toaster: show 'satisfied via' text for build deps
febb898 bitbake: toaster: show list of provides for the recipe
2ff4ccb bitbake: buildinfohelper: add provides info to the db
16a81fb bitbake: toaster: add Provider model
6a28ed3 bitbake: buildinfohelper: use providermap
f2b7252 bitbake: cooker: add providermap to dep_tree
7e380d4 bitbake: taskdata: refactor get_providermap
46731da bitbake: main/runqueue: Add --setscene-only option to bitbake
34f8db9 update_font_cache: only scan system font directories
e5c011b Add "CVE:" tag to current patches in OE-core
f04fb88 scripts/create-pull-request: fix git request-pull syntax
928ceb6 qt4: fix-for-mips-n32.patch: remove it
c4a3258 util-linux: create util-linux-runuser package
554ca68 valgrind: include aarch64 in COMPATIBLE_HOST
0ce775a valgrind: update to 3.11.0
21a94f6 valgrind: don't restrict to armv7a
b8ebac9 DpkgRootfs: Fix logcheck_error false-positive when use multilib
e265fbb package_deb.bbclass: add 'Multi-Arch: foreign' tag to allarch packages
4aeb69d package_manager.py: fixes for multilib deb packaging builds
9ea7428 package_deb.bbclass, cross-canadian.bbclass: DPKG_ARCH mapping function
72e6932 connman.inc: add missing RDEPENDS
675ff42 meta: rename perl-native-runtime
3f4fb39 dbus: support large-file for stat64
0d5e41f freetype: enable out-of-tree builds, and use host zlib
8f2ab19 bluez5: upgrade to 5.37
11f5a42 cogl-1.0: fix may be used uninitialized error
235606f oeqa/runtime/logrotate: fix hardcoded root directory
cce6c3e oeqa/runtime/smart: fix hardcoded root directory
cd2cf1f boost: update to 1.60.0
afc0255 bitbake.conf: remove 'stamp-base'
c8fef7f gcc5: Fix build on NIOS2
eda3947 rpmresolve.c: Fix unfreed pointers that keep DB opened
3c8a451 tzdata: Make /etc/timezone optional
b80da02 systemd: arrange for volatile /etc/resolv.conf
5548a76 systemd: add myhostname to nsswitch.conf
d6bc841 opkg-utils: add update-alternatives PACKAGECONFIG
c3b96ff linux-dtb.inc: use absolute upd-alt paths
3ad08c0 uclibc: Upgrade to 1.0.10
74c3667 populate_sdk_ext: Pass excluded_targets as a list to prune_lockedsigs
e306d54 populate_sdk_ext: Change to include siginfo and non sstate task sigs
e1a558a populate_sdk: Switch from bzip2 to xz
3341f3f classes: Fix do_rootfs references
0a4e1f9 image: Create separate tasks for rootfs construction
fdced52 image: Move pre/post process commands to bbclass
cdc0aee image.bbclass: Separate out image generation into a new task, do_image
0269219 populate_sdk_ext: Use new --setscene-only option to bitbake instead of workarounds
1ee0842 sstatesig: Handle special case of gcc-source shared-workdir for printdiff
d93c212 bitbake.conf: add virtual/libiconv-native to ASSUME_PROVIDED
b2fe2a8 devtool: build: support using BBCLASSEXTENDed names
38ed039 devtool: reset: support recipes with BBCLASSEXTEND
532f429 devtool: refactor code for getting local recipe file
ec90168 devtool: add: support adding a native variant
99e3872 devtool: reset: do clean for multiple recipes at once with -a
5ef716c recipetool: create: support creating standalone native/nativesdk recipes
1e503c0 recipetool: create: lower case name when determining from filename
4deed25 devtool: sdk-update: add option to skip preparation step
d586a11 devtool: sdk-update: fix error checking
c1b7d83 devtool: sdk-update: fix metadata update step
efead10 devtool: sdk-update: fix not using updateserver config file option
9348c91 classes/populate_sdk_ext: disable signature warnings
d44dcd7 classes/populate_sdk_ext: fix cascading from preparation failure
d11051c scripts/oe-publish-sdk: add missing call to git update-server-info
fbc2147 libbsd: upgrade to 0.8.1
221d864 bitbake: fetch/git: Change to use clearer ssh url syntax for broken servers
46d62d0 bitbake: knotty: Use non-interactive mode as fallback for dumb terminals
bfa7859 bitbake: cooker: fix findFilesMatchingInDir documentation
3d42737 bitbake: cooker: use in instead of count
0e83229 maintainers.inc: remove x11vnc
d914c7f meta-yocto: drop qt4 references
0f3ad7c scripts/yocto-layer: Avoids duplication of "meta-" prefix
220ef32 poky-lsb/poky-tiny: update preferred kernel to 4.1
b82e228 yocto-bsp: remove 3.14 and 3.19 bbappends
685daeb conf/local.conf.sample: comment out ASSUME_PROVIDED=libsdl-native
2c5e7e0 image: Really remove lockfiles flag
a500e3a boost: ensure boost to remain an empty metapackage
b151506 image_types.bbclass: Rebuild when WICVARS change
eb4159c gccmakedep: fix buildpaths qa check
f54e53c bash: fix buildpaths qa check error
6d111c8 testimage: remove VNC test, x11vnc isn't in oe-core anymore
8bec5c5 x11vnc: remove all references to moved package
8f865e2 x11vnc: move recipe to meta-oe
ae1fc96 classes/buildhistory: actually use KiB in extensible SDK sizes files
84f66b5 x11vnc: move recipe to meta-oe
c44599d readline: move inputrc into readline
f29d642 tune-*: use mcpu instead of mtune for ARM tunes
c6a1991 arch-armv7ve: add tune include for armv7ve and use it from cortexa7 and cortexa15
21d61fa cortexa{7,15,17}: add VFPv4 tunes
7f2cb68 feature-arm-vfp.inc: Further simplify with TUNE_CCARGS_MFLOAT
e9b2ffc feature-arm-{neon,vfp}.inc: refactor and fix issues
45f726c arch-armv7a.inc: add vfpv4 support also to softfp and big endiand tunes
ebe8358 arch-armv7a.inc: Fix PACKAGE_EXTRA_ARCHS for tune-armv7atb-vfpv3, tune-armv7atb-vfpv3d16, cortexa7thf-neon-vfpv4
9280a8e arch-armv5.inc: drop duplicate ARMPKGSFX_DSP and PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp
46d6b0e arch-armv[456]*.inc: improve indentation like armv7a
860663a arm/arch-arm*, tune-cortexa*, tune-thunderx.inc, powerpac/arch-powerpc64.inc: Use normal assignment
8c483a1 arch-armv7a, tune-cortexa*: improve indentation
7498b91 arch-armv7a, tune-cortexa*: improve comment VFP -> HF
bb9b581 arch-armv7a: add missing space before ?=
15f8344 tune-cortexr4.inc: fix PACKAGE_EXTRA_ARCHS
e2736f7 sanity.bbclass: add more information to error message about TUNE_PKGARCH missing in PACKAGE_ARCHS
b68d947 mkefidisk.sh: add boot log on console
62d7c97 mkefidisk.sh: add startup script for automated boot
5aa3b93 oeqa/selftest/recipetool: update for libjpeg-turbo migration
ffa7469 libjpeg: Replace libjpeg with libjpeg-turbo
29d273f python3: fix installed-vs-shipped when 64bit + multilib
db7cee6 pulseaudio: add PACKAGECONFIG for lirc
b900ec8 sstate-sysroot-cruft.sh: Extend the whitelist
20843fa iptables: upgrade to 1.6.0
c2bda6c scripts/oe-selftest: Allow to run tests on random/all MACHINEs
8e1435e selftest: Added testcase decorators for 2 tests
32f332c oe-selftest: New option --list-tests
17d886b oe-selftest: Improved --list-classes when determining test names
4ec2da7 selftest: moved tc test_buildhistory_does_not_change_signatures
02d259c scripts/oe-selftest: Remove extra coverage data added to unittests
30c06a4 expat: CVE-2015-1283
315bdc8 packagegroup-core-x11-sato: enable pcmanfm on mips
a3e26f9 wic: rawcopy: Copy source file to build folder
d6e0da4 grub2: Fix CVE-2015-8370
bb663b0 systemd: enable compatibility libraries by default
3fea163 systemd: add more compression and importd PACKAGECONFIGs
d462b70 gcc-sanitizers: link directly against sysroot libstc++
3eb6135 openjade: Fix build if not installing libtool .la files
6308c47 valgrind: Define __UCLIBC__ for uclibc based systems
3d19a1e security_flags.inc: disable -fstack-protector-XXX for valgrind
807ed8a meta/conf/layer.conf: bump layer version due to Qt4 removal
4fb3e05 packagegroup-core-lsb: treat qt4 packages same as qt3 packages
8b11ed8 qt4: remove recipes and classes
0baadc8 toaster-manual: Updates to toaster use chapter.
908bbff ref-manual: Updated the list of supported image types.
5d27451 dev-manual: Added the --configfile bootloader option.
7b3b1f9 dev-manual: Added three new wic option descriptions.
eeffa64 dev-manual: Added the --overhead-factor wic option description.
2beb19b dev-manual: Added the --extra-space wic option description.
95851df dev-manual: Added wic --notable option description.
88a2794 dev-manual:
8bdc707 sdk-manual: Initial Manual framework
f1f7625 bsp-guide: Updated the license statement.
6686a31 dev-manual: Correction to the KVM stuff in the runqemu commands.
ccc830d documentation: Prepare for 2.1 builds
7af9314 mega-manual: Added four new figures for GUI example.
f8185ff bitbake: ast: Add filename/lineno to mapped functions
a178c5a bitbake: main: kill server without queue setup
773700d bitbake: xmplrpc: split connect method
05b4fbc bitbake: uievent: refactor retry loop
ebc169c bitbake: uievent: get rid of EventHandler attribute
4e0de6e bitbake: uievent: add error to registerEventHandler return
01419d5 bitbake: cooker: add state.get_name method
763506d bitbake: fetch2/__init__.py: Add support for 7-Zip
f5bfc1c bitbake: utils: Remove double compile from better_compile
b4141f6 bitbake: fetch2/local.py: avoid using PREMIRROR
1ad3595 bitbake: siggen: Change exception note into a warning
4ba49ac bitbake: data: Drop misleading ExpansionError exception
2c94311 bitbake: cooker: Drop useless parsing exception
a16b543 bitbake: data: Pass lineno/filename data from build_dependencies
958f0ff bitbake: codeparser: Add support for correct linenumbers
db4376e udev-extraconf: introduce multiple blacklist files for more complex setups
a8fb429 uclibc: disable parallel builds
401c632 image: Condense do_rootfs function/flags
0051510 image/rootfs-postcommands: Separate out post rootfs commands to separate class
3428edd image: Remove pointless rootfs lock
eb5bb0e packagegroup-core-boot:replace busybox to variable
cc7bb6c initramfs-framework_1.0:replace busybox for variable.
d9ffa59 core-image-minimal-initramfs: replace base-utils
9349f42 base-utils:flexible dependency for command utilities
c44b76a orc: Add missing PACKAGES_DYNAMIC
2cd061a bluez5: include the patch only for 5.36
4c35473 meta-yocto-bsp: remove 3.14 and 3.19 bbappends
6af8981 meta-yocto-bsp: Remove uvesafb (v86d) from generic x86 features
614e9ec qemu: add PACKAGECONFIG for Nettle crypto support
09705a4 oeqa/selftest: support sets in devtool comparisons
4b543f7 packagegroup-core-x11-sato: include pulseaudio-misc
23302ee devtool: use cp instead of shutil.copytree
d6e7b5b xorg-lib: allow native building without x11 DISTRO_FEATURES
4cba706 busybox: generalize recipe to work with arbitrary install directories
9d001ae cairo: update 1.14.4 -> 1.14.6
6d561fb libdrm: Upgrade to 2.4.65
0f516f0 image-vm.bbclass: uses IMAGE_LINK_NAME
c851096 image-live.bbclass: uses IMAGE_LINK_NAME
907b87d rpm: Generate per distribution and multilib macro files
c910789 package_manager.py: add debugging support for rpm scriptlet execution
8dd27ef xinput-calibrator: get screen geometry when calibrating
e8d36f4 scripts: hand the TEMPLATECONF local over to setup-builddir
0f4fb26 util-linux: Fix floating dependency upon 'readline'
2cb434a linux-firmware: package Broadcom BCM43340 firmware
f70d46f rpcbind: Fix build with libtirpc 1.0.1
866c693 libtirpc: upgrade to 1.0.1
5754b83 gstreamer1.0-libav: upgrade to version 1.6.2
6ac601f gstreamer1.0-rtsp-server: upgrade to version 1.6.2
3ac3d33 gstreamer1.0-plugins-ugly: upgrade to version 1.6.2
823b623 gstreamer1.0-plugins-bad: upgrade to version 1.6.2
6d13f30 gstreamer1.0-plugins-good: upgrade to version 1.6.2
05896a5 gstreamer1.0-plugins-base: upgrade to version 1.6.2
a8eb77b gstreamer1.0: upgrade to version 1.6.2
dd5756b mirrors: add archive.apache.org to Apache mirrors
cfbd804 guile: remove redundant replacement of .pc file
c2e8079 bind: 9.10.2-P4 -> 9.10.3-P2
7204a0f libsndfile1: enable FLAC/Ogg/Vorbis support
35bd254 buildhistory: improve support for extensible SDK
ea0abcd buildhistory: fix not recording SDK information
b6d191d scripts/oe-selftest: Add support for selftest log with timestamp
ab79287 selftest: Added MACHINE = "qemux86" to tests that use runqemu
b09080d ncurses: fixes wrong paths in BINCONFIG
8df88fb xcb: don't build-depend on python-native
d7759a5 tcmode-default: Use glibc for nativesdk version even on uclibc and musl
a7eadc3 qemu: upgrade to 2.5.0
9988ab3 webkitgtk: update to 2.10.4
cedb027 epiphany: update to 3.18.2
6e27dd8 libwebp: update to 0.4.4
efcf4b4 libsecret: update to 0.18.3
0112274 gnome-desktop3: update to 3.18.2
88a656e gcr: update to 3.18.0
883193a linux-yocto: remove 3.14 and 3.19 recipes
4487e3a kernel-yocto: fix checkout bare-cloned kernel repositories
5161944 linux-yocto/4.1: update to v4.1.15
a462d16 linux-yocto-dev: bump to 4.4-rcX
862b3b3 lttng-modules: fix build issue against kernel 4.4
9563aa8 yaffs2: fix checkpoint functionality
cefc24d mobile-broadband-provider-info: update to tagged release 20151214
04aa27c icu: fix upstream version check
2865e5f btrfs-tools: update to 4.3.1
5beb3bc iso-codes: update to 3.63
503c08d kexec-tools: update to 2.0.11
4fa2e4b lighttpd: update to 1.4.38
f7a7796 tiff: update to 4.0.6
2498065 libassuan: update to 2.4.2
f2192fa msmtp: update to 1.6.3
7fc3066 liburcu: update to 0.9.1
10d14bc trace-cmd: update to 2.6
fc774e9 python3-pip: update to 7.1.2
c3330aa pytnon-pexpect: update to 4.0.1
aa90b5d ifupdown: update to 0.8.2
4c98105 gptfdisk: update to 1.0.1
edde9af cryptodev: update to 1.8
9da9308 oe-selftest: devtool: add more explicit check for ls output
c2435b1 oe-selftest: add tests for simple devtool add / recipetool create URL case
8916731 recipetool: create: fix error when extracting source to a specified directory
fe28c25 recipetool: create: improve autotools support
498e483 devtool: sync: tweak help / messages
b272c51 devtool: reset: print message about leaving source tree behind
95a234e devtool: status: list recipe file within workspace if one exists
e116739 devtool: modify: default source tree path
110f433 devtool: add: allow specifying URL as positional argument
ceaa4bf devtool: add: figure out recipe name from recipetool
ee0d5a1 devtool: add: allow source tree to be omitted
0d8751f scripts/lib/argparse_oe: handle intermixing of optional positional arguments
1bd7793 devtool: update-recipe: use correct method to get bbappend filename
2074654 devtool: split out function for naming bbappend
6acbdc9 devtool: add: tweak help text
316b57b devtool: edit-recipe: add new subcommand
ebe5f0b recipetool: create: basic extraction of name/version from filename
db5f964 recipetool: create: support extracting name and version from build scripts
6a7661b recipetool: create: set up priority system for recipe handlers
38803e3 recipetool: create: detect when specified URL returns a web page
e78a039 recipetool: create: prevent attempting to unpack entire DL_DIR
e61645b recipetool: create: minor fix for potential issue in python handling
ae2141b recipetool: create: fix do_install handling for makefile-only software
c2f1742 recipetool: create: avoid traceback on fetch error
470f20b recipetool: create: handle https://....git URLs
8e0a84c scripts: print usage in argparse-using scripts when a command-line error occurs
548d433 directfb.inc: enable bfd linker workaround for all arm targets
2381f4a devtool: sdk-update: fix traceback without update server set
7540550 classes/populate_sdk_ext: error out of install if buildtools install fails
ecce3d3 classes/populate_sdk_ext: hide build configuration in devtool build* output
fd84d0f classes/base: don't print header if BUILDCFG_HEADER not set
a4f496a classes/populate_sdk_ext: use uninative to set NATIVELSBSTRING
a6f8a3f toaster.bbclass: fix TypeError when parsing build stats
937b7fd libxcb: Add a workaround for gcc5 bug on mips
86c8b8b flex: update to 2.6.0
dad130b opkg: upgrade to v0.3.1
d2b770c systemd: remove merge conflicts accidently left in
ca69643 wic/help.py: document that mountpoint is optional for part command
5628dde pixman: check neon support via TUNE_FEATURES, not the _armv7a over-ride
9a74388 xdg-utils: Do not build the in-script documentation
520b37d gettext: Upgrade 0.19.4 -> 0.19.6
cae0e0f gcc-configure-common.inc: add gcc-runtime ABI fixes for armv7m and armv7r
cba8fb3 tune-cortexr4.inc: provide an _armv7r over-ride via MACHINEOVERRIDES
fd10723 tune-cortexm3.inc: provide an _armv7m over-ride via MACHINEOVERRIDES
b6fe440 feature-arm-thumb.inc: drop 'no-thumb-interwork' tuning feature
1d5a4cf feature-arm-thumb.inc: drop legacy _thumb and _thumb-interwork over-rides
ca64c16 feature-arm-thumb.inc: drop ARM -vs- thumb comments
95a79a5 rpm: Fix support for db5 and db6
75cec07 oe-buildenv-internal: fix return code
606c9e7 staging.bbclass: make already-stripped can be skipped
647e0e4 buildhistory-collect-srcrevs: hide empty sections
d4b5a1f selftest/buildhistory.py: Test buildhistory does not change sigs
4b83f1f gcc5: Upgrade gcc-5.2 -> gcc-5.3
0381b78 bitbake: event/utils/methodpool: Add a cache of compiled code objects
c61c1eb bitbake: BBHandler: Improve IN_PYTHON_EOF handling
2a94194 bitbake.conf: Add filename and lineno to BB_SIGNATURE_EXCLUDE_FLAGS
5f40691 bitbake: toaster: remove 2 confusing parameters
3960b6e bitbake: toaster: move setting of default values
b194c0c bitbake: toaster: move startup checks to a better place
064d2c7 bitbake: toaster: remove 2 unused functions
c505f24 bitbake: toaster: remove addtoConfiguration function
c7e4404 bitbake: toaster: updated header of the toaster script
af34920 bitbake: toaster: add MANAGE variable
563b786 bitbake: toaster: remove unused variable
aa3cc12 bitbake: toaster: split long lines, add/remove whitespace
8e4acac bitbake: toaster: check if address:port is in use
847b935 bitbake: toaster: implement checksocket command
9f3681d buildstats-summary/toaster: Cope with removal of get_bn()
522dcaa bitbake: knotty: Improve exception error message
01d67bf bitbake: knotty: Fix row/column function return value issue
6c12efa bitbake: buildinfohelper: Update for buildstats layout change
28ea1a1 bitbake: fetch: use orig localpath when calling orig method
5cb6d83 bitbake: utils: Improve traceback from better_exec internal errors
0019edc bitbake: ast/event/utils: Improve tracebacks to include file and line numbers more correctly
b14ccb2 bitbake: runqueue: Add support for <task>- syntax
5069ab6 m4: Drop unused/unreferenced patch
d7e766b toaster: Update for buildstats changes
adfdca4 buildstats: Improve to add getrusage data and corrected IO stats
3187647 buildstats: Separate out the build and task data to allow improvements
38a2553 buildstats: Clean up e.data and bb.data references
7b1e48f buildstats: Drop get_bn/set_pn and just use BUILDNAME
7837162 buildstats: Drop disk data from buildstats
030c033 nativesdk-buildtools-perl-dummy: Bump PR
e6f2761 combo-layer: Stop using filterdiff
f1f3716 meta: more removals of redunant FILES_${PN}-dbg
5fb8fea clutter-gst-3.0: add dependency on libgudev
54f01ca systemd: Upgrade to 228
63bdadc uclibc: Switch to using uclibc-ng
0b5cddd cdrtools-native: update to 3.01 final
c4dfb92 grep: update to 2.22
d8608bc procps: update to 3.3.11
52f6a01 babeltrace: update to 1.3.1
0c705d6 powertop: update to 2.8
516d8c9 nfs-utils: update to 1.3.3
9c39a4f systemtap: update to 2.9
fef0ec6 kbd: update to 2.0.3
8668e17 gmp: update to 6.1.0
86e02d0 docbook-xsl-stylesheets: fix UPSTREAM_CHECK_REGEX
f065766 mtd-utils: update to 1.5.2
5d32aeb unfs3: update to r497
4e653b5 python-numpy: update to 1.10.1
90b7212 libxml-simple-perl: update to 2.22
689db13 dmidecode: update to 3.0
d301451 cpio: update to 2.12
2bea006 puzzles: update to current commit
2d04c83 gnutls: update to 3.4.7
cf1eb2b libidn: add native and nativesdk support
dd58b3b libpng: Update SRC_URI to use GENTOO_MIRROR
b763668 libpng12: Upgrade 1.2.54 -> 1.2.55
91c92fc libical: Upgrade 1.0.0 -> 1.0.1
5c6ff26 libxslt: use proper SRC_URI
a444eb5 kexec-tools: added the script kdump
be9f7f9 ltp: Upgrade 20150420 -> 20150903
81f1e41 musl: Update to latest 1.1.12 release
c529e66 util-linux: Upgrade to 2.27.1
bdbc5ee packagegroup-core-sdk: Disable sanitizers for uclibc
692853d libsolv: add new recipe
8bba7de curl: upgrade to 7.45
2e3a172 libsndfile1: 1.0.25 -> 1.0.26
df18352 wget: Upgrade 1.16.3 -> 1.17
81eb101 unifdef: upgrade to 2.11
19c76ad sstate-sysroot-cruft: Add php, python, lua, fontcache generated files to whitelist
f80f8ba oeqa/selftest: Added testcase decorators for 2 testcases
a5dd1dd uninative.bbclass: Choose the correct loader based on BUILD_ARCH
388e580 license: Fix BB_TASKDEPDATA references
f19e8de coreutils/procps: Revert priority change since coreutils > busybox
455ff32 meta: more removals of redunant FILES_${PN}-dbg
e0890b6 meta: Drop now pointless manual -dbg packaging
b7766e4 package: Add auto package splitting of .debug files
89f13c7 meta/conf/toasterconf.json: remove SDKMACHINE variable as it no longer used
03d715e bitbake: toaster: tables Set a default order for the software recipes table
4ff0d60 bitbake: toaster: rework checking of Django version
4a78416 bitbake: toaster: monkey patch Queryset
c1c8eff bitbake: toaster: removed extra calls of migrate
507aafb bitbake: toaster: work around 'database is locked' error
322b470 bitbake: toaster: fixed format strings
84daa40 bitbake: toaster: use OneToOneField instead of ForeignKey
c464f34 bitbake: toaster: Amend regex for MySQL database URLs
f001a4a bitbake: toaster: Remove compatible_layerversions() method
0adffdf bitbake: toaster: Check Django version against toaster-requirements.txt
8d058cf bitbake: toaster: Update deprecated manage.py command
717c636 bitbake: toaster: Prevent deprecation warnings for RedirectView
0f602c1 bitbake: toaster: Update API used to make runbuilds methods run in transactions
93f5738 bitbake: toaster: rename get_query_set -> get_queryset
23c4806 bitbake: toaster: Start Django machinery for database access
7a0c45e bitbake: toaster: Create default project with get_or_create* method
9de8dfa bitbake: toaster: Fix references to app paths
535fc9b bitbake: toaster: Remove South migrations
8ca4664 bitbake: toaster: Upgrade to Django 1.8.6 and remove South
b322dec bitbake: toasterui: process SetBRBE event
0274b68 bitbake: toaster: trigger SetBRBE event
fdb8e74 bitbake: toaster: implement BitbakeController.triggerEvent
5de3800 bitbake: event: Fix subprocess event error traceback failures
0da1d71 nopackages: Add class for recipes which don't generate packages
5003d14 sstate: Ensure populate_lic dependencies are not followed
48aad51 populate_sdk_ext/sign_rpm/sign_package_feed: Add missing getVar parameter
98dcdcb autoconf: Disable macro which causes excessive delays when using dash as sh
28fa304 automake: Remove delays in configure scripts using automake
f5e681d site/common-linux: Add some macros to avoid sleeps during configure
93adf46 meta-yocto/conf/toasterconf.json: remove SDKMACHINE variable as it no longer used
b3d6872 lttng-tools: Revert wrong enforcement of Python 3.0 use
2c11bdd attr: Add patch to account for use of internal glibc header
f1c034b libpam: Fix build with musl
33bab59 openssl: Add musl configuration support
c4207ee busybox: Add config for musl
083d9d1 gettext: Delete libintl.h and charset.alias
3a0797f sysvinit: Fix build with musl
fd21402 musl: Add recipe
781d34f mtools: Use proper glibc override to add glibc packages to recommendations
1b90d67 squashfs-tools: Define FNM_EXTMATCH if not defined
36a709a mtd-utils: Backport and create patches to support musl
41fd73f gdb: Fix build with musl
1ee97d8 autoconf: Add musl support
a2ea58b gcc: Add support for building musl configuration
37c74e2 gstreamer1.0: Split bash completion information into separate package
fc32a3b attr: add attr dependency to attr-ptest
9205f0a valgrind: import Debian link_tool patch for MIPS
c27bbb4 slang: update upstream URI to (official) jedsoft.org
21e35df subversion: update to 1.9.2
39260c3 json-c: add manual upstream version check
4ff0017 mirrors: replace references to archive.apache.org
1672a18 mobile-broadband-provider-info: update to current commit
b699b15 nspr: update to 4.11
dec8d20 python-setuptools: update to 18.7.1
b3535e2 openssl: update to 1.0.2e
fce2ee7 dropbear.inc: drop legacy CFLAGS and LD tweaks
f87063b dropbear: update 2015.70 -> 2015.71
a520495 texinfo: don't create dependency on INHERIT variable
2b2774b sudo: upgrade to 1.8.15
5eb0e90 linux-firmware: update to latest revision bbe4917
c147782 bluez5: upgrade to 5.36
64c3a09 sudo: remove libdir INSANE_SKIP
b407a80 libsdl: expand PACKAGECONFIG and enable native builds
39facf9 buildtools-tarball.bb: 32bit tools need pseudo 32bit library
bc26a7d rpm: fix file conflicts for MIPS64 N32
01c0285 rpm: Enable MIPS64 N32 transactions
a742586 bash: fix testcase run-coproc/run-execscript/run-test/run-heredoc failed
a6bb872 cpio: fix test case of symlink-bad-length
787d82b linux-libc-headers: update default KORG_ARCHIVE_COMPRESSION bz2 -> xz
94c0332 linux-libc-headers.inc: remove '-e MAKEFLAGS=' from EXTRA_OEMAKE
c7ad779 gcc-4.9: import patch fixing compilation in thumb mode
1260ded gcc-5.2: import patch fixing compilation in thumb mode
b4db53a dropbear: Upgrade 2015.68 -> 2015.70
e0162c1 gcc-cross-initial: make dependency on gnu-config-native and autoconf-native explicit
fccb128 weston-init: add a native systemd unit file
a1fa8d9 python: Fix cross compiling issue
c9fdc1b icu: Upgrade 55.1 -> 56.1
95909bc kernel.bbclass: drop unnecessary 'eval' from kernel_do_configure()
ec79a19 insane: in libdir test allow libraries in libexecdir
9c0186f rootfs.py: Change logic to unistall packages
23083e7 oeqa/systemd: get runtest target boot time and log
c6330a2 oeqa/systemd: journalctl helper function
220a78b scripts: oe-selftest Added new features.
98d2485 oe-buildenv-internal: preserve existing BB_ENV_EXTRAWHITE
9cab798 toolchain-shar-extract.sh: fix ~ not working in path
f27401d nativesdk-buildtools-perl-dummy: properly set PACKAGE_ARCH
5e3e2e0 poky.conf: Bump for 2.1 development
7e8ff7b bitbake: toaster: toasterui Add ParseStarted/ParseProgress events to mask
f823601 build-appliance-image: Update to master head revision
992e577 linux-yocto: Update genericx86* BSPs to v4.1.13
b4f6950 cmake: Add nios2 support
27b9f04 boost: adjust hard-coded path after python3 upgrade
639cadd sdk.py / OpkgSdk: remove_packaging_data() after install
fd4894f devtool: extract: update SRCTREECOVEREDTASKS for kernel
34f1d81 devtool: extract: copy kernel config to srctree
6650357 lib/oe/package_manager: Introducing PACKAGE_FEED_BASE_PATHS/PACKAGE_FEED_ARCHS
d7baeb5 selftest/wic.py: Add test for custom bootloader config
8612f26 directdisk-bootloader-config.wks: Add example for custom bootloader config
c59dc3b wic/help.py: Document the new option "configfile"
7033873 wic: Allow to use a custom config for bootloaders
f95f729 wic/utils/misc.py: Added function to search for files in canned-wks
9773faa wic: Prepare wicboot to allow custom bootloader config
4515186 package_ipk: allow to specify OPKG_ARGS in local.conf
7cf7156 systemd.bbclass: Allow enabling of parameterised services
551cda0 base: check for existing prefix when expanding names in PACKAGECONFIG
c093fd8 linux-yocto/4.1: Fix kernel oops on qemuarm boot
cda3905 toolchain-shar-extract.sh: ensure cleaned environment will work for ext SDK
f9384b0 bitbake: knotty: Enforce terminal line limit to stop crazy scrolling
7a775a1 initramfs-framework: create directory /var/run
2861399 libpcre: drop UPSTREAM_CHECK_ variables
35c28e3 libpcre: upgrade to 8.38
d50ef65 libpng: update 1.6.19 -> 1.6.20 (CVE-2015-8126)
2b736f2 ghostscript: add dependency for pnglibconf.h
976f0e3 package_regex.inc: split the rest of the entries to their recipes
74bfa62 package_regex.inc: split entries which blacklist specific versions to their recipes
75c6929 package_regex.inc: split sourceforge related entries to their own recipes
cefeac2 package_regex.inc: split PyPi related entries to their own recipes
aa5df2a package_regex.inc: split Debian-related entries into their own recipes
12ba5cc package_regex.inc: split GITTAGREGEX entries into recipe files
642e92f package_regex.inc: split entries with odd-even versioning into their own recipes
96eac69 package_regex.inc: deprecate the file
b0bbea5 gstreamer: really fix the helper install race
b822216 neard: fix libdir/libexecdir confusion
cbfccc6 glibc: fix libdir/libexecdir path confusion
d0577f9 sudo: handle libexecdir != libdir/PN.
6f837cc util-linux: Add ptest
dbd02bd libav: Correctly handle prefix=""
fda9859 libav: Add PACKAGECONFIG options: avdevice, avfilter, avplay, gpl
7ba85f1 libav: Remove deprecated --disable-avserver
2739ed0 busybox: backport upstream fixes for unzip
6decbbb qt4-4.8.7: fix build for mips n32
f1e8938 gstreamer1.0: Convert tests and valgrind config opts to PACKAGECONFIGs
11b9524 cracklib: fix for base_libdir == libdir
d9f73ca libbsd: Upgrade to 0.8.0
10d6dc4 libcroco: Upgrade 0.6.8 -> 0.6.9
79b823a shared-mime-info: Upgrade 1.4 -> 1.5
f6ec8a4 xdg-utils: Upgrade to 1.1.1
a3f63f9 gsettings-desktop-schemas: Upgrade 2.16.1 -> 3.18.1
754f6b6 gnome-common: Upgrade 3.14.0 -> 3.18.0
75aba18 clutter-gtk-1.0: Upgrade 1.6.2 -> 1.6.6
c6a6212 clutter-gst-3.0: Upgrade 3.0.8 -> 3.0.14
2da6cd5 clutter-1.0: Upgrade 1.24.2
148c953 cogl-1.0: Upgrade 1.20.0 -> 1.22.0
f54d4e4 ghostscript: Add NIOS2 support
21ba42b harfbuzz: update 1.1.0 -> 1.1.2
058b91e xvideo-tests: move to the latest release
70d459c scripts/oe-pkgdata-util: sort the packages in list-pkg-files
80e3919 wic: insert local Python paths at front
9d788d7 toolchain-scripts.bbclass: unset command_not_found_handle
82ab99f waf.bbclass: remove unused parameter from get_waf_parallel_make()
68d3dfe toolchain-shar-extract.sh: proper fix for additional env setup scripts
0c5d239 base: Improve handling of switching virtual/x providers
3745479 bitbake: bitbake: rename REGEX, REGEX_URI, and GITTAGREGEX.
dd282d4 bitbake: toaster: return back 'New project' button
2a8e970 bitbake: toaster: tests Update UI tests to work with 2.0 changes
fe8a0a3 bitbake: toaster: tests Automated build-mode backend tests
0497b57 bitbake: toaster: unset environment variables
8b7a548 bitbake: toaster: get rid of complicated heuristics
556b8b6 bitbake: toaster: remove SDKMACHINE from project variables
4186f5b bitbake: toaster: stop using toaster-pre.conf
361faa3 bitbake: toaster: remove writeConfFile API
fcbba5a bitbake: toaster: set varibales on bitbake server
993bc7e bitbake: toaster: implement BitbakeController.getVariable
53e981e bitbake: toaster: buildinfohelper Broaden the toaster created recipe data case
57e5f24 bitbake: toaster: do not create duplicate HelpText objects
4c1e5ec bitbake: toaster: remove usage of BUILD_MODE variable
9902895 bitbake: toaster: do not terminate bb server
58765a8 bitbake: toaster: remove stopBBServer API
95a3cf7 bitbake: toaster: reimplemented startBBServer method
76d53b5 bitbake: toaster: remove _setupBE function
87b2f95 bitbake: toaster: implement 'toaster restart-bitbake'
891484a bitbake: toaster: implement start_bitbake function
bf25471 bitbake: toaster: implement stop_bitbake function
7c2b225 bitbake: toaster: update brbe and project attributes
de812d0 bitbake: toaster: start 'manage.py runbuilds' in the script
28e8ccf bitbake: toaster: make runbuilds to loop
a3871a3 bitbake: toaster: use parent of the build dir
2a96d35 bitbake: toaster: check for toaster configuration later
d87a534 bitbake: toaster: remove unused variable
dc6a489 bitbake: toaster: change toasterconf.json logic to use TEMPLATECONF, like oe-setup-builddir
5a42c2d bitbake: toaster: run bitbake the same way
cac91db bitbake: toaster: set DATABASE_URL in toaster script
a464bf2 bitbake: toaster: implement get-dburl command
e473151 bitbake: toaster: don't allow to run toaster as a script
4de214f bitbake: lib/bb/utils: improve edit_bblayers_conf() handling of bblayers.conf formatting
0debb11 bitbake: lib/bb/utils: fix error in edit_metadata() when deleting first line
9d19dd9 bitbake: wget.py: parse only <a> tags
71ede7b bitbake: toaster: toastergui tests Add generic test for ToasterTables widget
34b22cf bitbake: toaster: tables Fix invalid field name on NewCustomImagesTable
1c59846 bitbake: toaster: tables Add default_orderby field where it was missing or unset
d82c541 bitbake: toaster: CustomImageRecipe add search_allowed_fields to this model
bdf6241 bitbake: toaster: machines table Fix missing layers information needed for filter
b90a8dc bitbake: toaster: tablejs Make sure click handlers consume click event
c075bcf bitbake: toaster: projectpage Make sure build targets are space separated
698c74c libsdl: remove redundant configure_tweak patch
35945fd iw: upgrade to version 4.3
15969ae gstreamer1.0-plugins-good: fix PACKAGECONFIG for gudev and add one for v4l2 and libv4l2
e601b38 gstreamer1.0-plugins-bad: fix dependencies for uvch264 PACKAGECONFIG
ddf2501 gudev: Add from meta-oe
e406fa8 lsb: fix installed-vs-shipped for mips
39ecdce rpm: fix for N32 MIPS64
09b4da6 glibc/0029-fix-getmnt-empty-lines.patch: fix getmntent()
1781a9a init-install-efi: fix script for eMMC installation
f808747 init-install-efi: fix script for gummiboot loader
2a55036 linux-firmware: rtl8192cx: Add latest available firmware
b60af3b libsdl2: add missing dependency on libxkbcommon for PACKAGECONFIG[wayland]
ed31874 libxml2: upgrade to 2.9.3
ecb1c71 libxml2: merge pointless bb/inc split
19a626d openssh: redesign ssh-agent.sh regression test case
81b59e7 gcr: Require x11 DISTRO_FEATURE
934e486 psplash: update to latest git version
ccb2a57 sysvinit-inittab: Add wrapper script to verify console exists
b7f610d linux-yocto/4.1: Bluetooth:Fix the connection fail of 6lowpan over BT LE
d08e761 linux-yocto-rt/4.1: update to -rt15
6aa464c linux-yocto/4.1: fsl-mpc8315e-rdb: Enable EEPROM
bd29006 linux-yocto/4.1: update to v4.1.13
5561407 uClibc: enable utmp for shadow compatibility
533fc01 glibc: Backported a patch to fix glibc's bug(18589)
598e372 ncurses: update SRC_URI
51b64ee openssl: enable parallel make
88e45cd busybox: enable resize applet
87de4a1 busybox: disable support for mounting NFS file systems on Linux < 2.6.23
73cc839 busybox: update 1.23.2 -> 1.24.1
f8ac408 busybox: re-order defconfig to align with busybox 1.24.1
3648a37 busybox.inc: remove '-e MAKEFLAGS=' from EXTRA_OEMAKE
bf28ea9 busybox.inc: set CC=${CC} via make command line
f21dce1 busybox.inc: fix CONFIG_EXTRA_CFLAGS configmangle
6167669 busybox.inc: don't set .config CROSS_COMPILER_PREFIX
e1ecccd busybox: move EXTRA_OEMAKE etc into busybox.inc
0e63300 busybox.inc: don't export EXTRA_OEMAKE
3735776 busybox_git: Enable getopt applet
b1774f4 harfbuzz: update 1.0.6 -> 1.1.0
31f803a sqlite3: update 3.9.0 -> 3.9.2
7e3474c readline: apply missing upstream patches
99b9d52 readline: prepare for readline6.3 upstream patches
e0b6d0c dbus: merge .bb and .inc
d99958a pulseaudio: Fix HDMI profile selection
2ba954f initscripts: hide the error in case system is not writeable
4ed84ff nativesdk-buildtools-perl-dummy: fix rebuilding when SDKMACHINE changes
b8fdd09 xf86-video-vmware: Add vmwgfx PACKAGECONFIG option
dfd5c4d pkgconfig: merge .bb and .inc
61c6887 pkgconfig: upgrade to version 0.29
744e89f ofono: upgrade to version 1.17
996f843 libxml2: remove legacy LDFLAGS += "-ldl" workaround
dedabc1 apr: fix LTFLAGS to make it work with ccache
9470956 iproute2: install bridge tool by default
1b8f6a2 lttng-tools: add libgcc to RDEPENDS
22dd6e7 lttng-tools: Upgrade to 2.7 release
ef73f21 lttng-tools: Drop unused patch
c375976 lttng-ust: Upgrade to 2.7 release
f5c1b57 lttng-modules: Upgrade to 2.7 release
8d708a5 libunistring: upgrade to version 0.9.6
f840e59 libtasn1: upgrade to 4.7
012ca02 wpa-supplicant: upgrade to 2.5
872e153 mesa: Make gl libraries RRECOMMEND mesa-megadriver
a62fa23 directfb.inc: force bfd linker for armv7a
9b075ca libpng12: update to 1.2.54
6d1eb34 libpng: update to 1.6.19
92a881f orc: update to 0.4.24
2f479b1 libpcap: update to 1.7.4
bd4058f apr-util: add missing RDEPENDS for ptest
1408642 iproute2: update to 4.3.0
e677c25 ruby-native: Depend on openssl-native
9e37812 db: fix race issue for libdb-6.0.la
c19036a pango: use ptest-gnome
43b29d9 gst-plugins-bad: improve FILES variables
9fc877f gstreamer1.0-plugins-base: add PACKAGECONFIG for libvisual
7a2bb0d python3: fix building nativesdk-python3
2268a70 python3: Upgrade from 3.4.3 to 3.5
ed8d1be python-git: Add missing dependency
dee2a8c guile, mailx, gcc, opensp, gstreamer1.0-libav, libunwind: disable thumb where it fails for qemuarm
c0b822f icu: force arm mode
f42ef3f rpcbind: Security Advisory - rpcbind - CVE-2015-7236
04034e7 subversion: fix CVE-2015-3187
f91aedf subversion: fix CVE-2015-3184
40cd228 oeqa/sshcontrol: don't source profile
d39192a oeqa/runtime/multilib: refactor ELF class extraction
cc34104 oe-selftest: Enable code coverage on unit tests
06859de meta/conf/machine: use ' inside quoted values
6be94ec runqemu-internal: Replace wacom-tablet with tablet for usbdevice
0cc3810 recipetool: make plugin registration function name consistent with devtool
b381f80 recipetool: add setvar subcommand
1fbd760 lib/oe/recipeutils: refactor patch_recipe_file() to use edit_metadata()
0b850cb devtool: clarify help text
5001f23 devtool: build: enable showing default task in help
f79022d devtool: build: use bbappend to set PARALLEL_MAKE
21481bc lib/oe/recipeutils: check in validate_pn() for names instead of filenames
671f41e devtool: ensure we change back to the original dir on error
74505b4 devtool: search: print SUMMARY value
3f46af2 devtool: drop unused plugin_init() functions
176211a devtool: package: use DEPLOY_DIR_<pkgtype> to get deploy directory
0fe7426 devtool: disable creating workspace for extract and search subcommands
a360fa7 lib/oe/patch: improve extraction of patch header
f79cc4d devtool: upgrade: provide a means to update the source branch
b4d4d21 devtool: upgrade: fetch remote repository before checking out new revision
9b7d45c devtool: upgrade: remove erroneous error when not renaming recipe
9a70444 devtool: upgrade: fix updating PV and SRCREV
6a52c73 devtool: upgrade: fix removing other recipes from workspace on reset
44ef78a devtool: include do_patch in SRCTREECOVEREDTASKS
804f5b8 image.py: avoid mkdir race when building multiple images
312862f package_manager.py: define info_dir and status_file when OPKGLIBDIR isn't the default
b00f734 image.py: Avoid creating empty .env file in _write_wic_env
a88505b lib/oe/terminal: use C locale when determining version
8d784ba toolchain-shar-extract.sh: Ensure it's ran in clean environment
7f3c20f toolchain-shar-extract.sh: do not allow $ in paths for ext SDK
2d21e5d create-pull-request: handle empty ODIR
c63b36f scripts/gen-lockedsig-cache: improve output
67af6d6 wic: exec_native_cmd: implement support for pseudo
8ffba25 toolchain-shar-relocate: don't assume last state of env_setup_script is good
b8ee7ae sanity: don't enforce DISPLAY for testimage
b364183 oeqa/qemurunner: pass nographic to runqemu if DISPLAY isn't set
46755cc base: add automatic dependency on lzip-native for .lz SRC_URI
6ea39c2 base: decode SRC_URI before adding implicit fetch dependencies
eded9c2 buildhistory.bbclass: support extending the content of the build history
d95df11 license.bbclass: Create image license manifest
efdab52 license.bbclass: Add function get_deployed_files
cc0d044 license.bbclass: Added function get_deployed_dependencies
d45e10e license.bbclass: Added get_boot_dependencies function
8b1e7bc license.bbclass: Split license create manifest
1a210e6 license.bbclass: Write recipeinfo file in license folder
74c7cd5 populate_sdk_ext.bbclass: Be more permissive on the name of the buildtools
5ba6382 populate_sdk_base: Add sysroot symlink check
7fed655 classes/populate_sdk_ext: fail if SDK_ARCH != BUILD_ARCH
2948169 classes/populate_sdk_ext: tweak reporting of workspace exclusion
28a2ea7 classes/populate_sdk_ext: make it clear when SDK installation has failed
124c6aa classes/populate_sdk_ext: tidy up preparation log file writing
d348624 boot-directdisk.bbclass: remove HDDIMG before create
03f15e5 sstate: Ensure siginfo and sig files are also touched
615ccae weston: Add PACKAGECONFIG option for colord CMS
cdad67c opkg: add cache filename length fixes
2ec77de openjade-native: statically link local libs
29747d4 sysklogd: inhibit updatercd for non-sysvinit
add3451 connman: depend on readline
7a557a2 latencytop: obey LDFLAGS
8aeec87 tcf-agent: obey LDFLAGS
9025d2e blkspace: fix ldflags for iowatcher
1732a8a bluez5: enable sysvinit support
160fdd8 sysprof: use packageconfig for the gui
425d020 mc: upgrade to 4.8.15
7386647 packagegroup-core-directfb: Don't depend on pango-modules
ac5ed8e xkeyboard-config: Upgrade 2.15 -> 2.16
3a71fab xkbcomp: Upgrade 1.3.0 -> 1.3.1
b7cb308 xinput: Upgrade 1.6.1 -> 1.6.2
05eca73 xf86-video-omap: Upgrade 0.4.3 -> 0.4.4
cfcc5e5 xf86-input-synaptics: Upgrade 1.8.2 -> 1.8.3
4c9256f xf86-input-evdev: Upgrade 2.9.2 -> 2.10.0
96ddcc5 xorg-driver-input: add xorg configuration to FILES
a1003f5 xserver-xorg: Upgrade 1.17.2 -> 1.18.0
a336b8a libxcb: Remove unused git-version of the recipe
05ba0db libxcb: Upgrade 1.11 -> 1.11.1
44233d3 pixman: Upgrade 0.32.6 -> 0.32.8
7ab0466 libxi: Upgrade 1.7.4 -> 1.7.5
63feef0 gtk-icon-utils-native: Upgrade 3.16.6 -> 3.18.2
38924d9 package_regex.inc: Add gtk-icon-utils-native
060b482 gtk+3: Upgrade 3.16.6 -> 3.18.2
4f3d2b3 adwaita-icon-theme: Upgrade 3.16.2.1 -> 3.18.0
c8849ac librsvg: Upgrade 2.40.10 -> 2.40.11
81769ca pango: add RPROVIDES for removed packages
c9b06f5 pango: Upgrade 1.36.8 -> 1.38.1
ced8d49 gdk-pixbuf: Upgrade 2.30.8 -> 2.32.1
918c773 libsoup-2.4: Upgrade 2.50.0 -> 2.52.1
5bd9305 at-spi2-atk: Upgrade 2.16.0 -> 2.18.1
8eb0c8f atk-spi2-core: Upgrade 2.16.0 -> 2.18.1
78130eb atk: Upgrade 2.16.0 -> 2.18.0
e7141ab glib-networking: Upgrade 2.44.0 -> 2.46.1
fcd7494 glib-2.0: build dependency cleanup
5357764 glib-2.0: Enable more tests while cross-compiling
1e271af glib-2.0: Upgrade 2.44.1 -> 2.46.1
bc1be07 qemu: Backport malloc-trace disabling
bca5a7a logrotate: do not move binary logrotate to /usr/bin
0069c0d systemd: drop unneeded $D check in prerm
cd1f2b4 systemd: chown hwdb.bin to root:root for do_rootfs
7ca8cd9 systemd: for valgrind, define VALGRIND=1
46fa8ab systemd: make coredump a PACKAGECONFIG
ac34784 systemd: add machine-id to conffiles
04937cc systemd: ignore .so filenames in systemd-doc
6821854 systemd: fix Upstream-Status tag
82107b1 mdadm: fix CFLAGS and ptest issues
d8adfd2 gcc-4.9: Fix various _FOR_BUILD and related variables
8ae27fa devtool: add sync command
6bfa1dc boost.inc: remove unused parameter from get_boost_parallel_make()
16d7bfd wireless-tools: remove unused files
ee923bf gstreamer1.0: fix install race
0ae52c8 gcc-multilib-config: make aarch64 support multilib
8514d21 libxml2: fix CVE-2015-7942 and CVE-2015-8035
e864f71 terminal: Open a new window instead of split on older tmux versions (<1.9)
5056581 flex: fix test-bison-yylval and test-bison-yylloc failed
c54540e gdbm 1.8.3: install libgdbm_compat
b9f87ed harfbuzz: update to 1.0.6
3f75537 ethtool: bump version to 4.2
9a4da3c openssl: fix ptest issues
9163a5d base-files: stage /etc/skel
d60c5ff mktemp: raise the priority to avoid conflicting with coreutils
b06eacd libunwind: fix build for qemuarm
c4acace gma500_gfx: Avoid inserting gma500_gfx module for certain devices
6c3f680 libsndfile: fix CVE-2014-9756
aa07eb1 python-pycurl: update version to 7.19.5.2
696aa7e rt-tests: upgrade to version 0.96
6ec7dc2 rpcbind: don't use '-w' for starting rpcbind
eddd88f libsecret: add dependency on intltool-native
2e8efb1 openssl: use subdir= instead of moving files in do_configure_prepend()
036d2dc openssl: sanity check that the bignum module is present
cf366d8 libsdl2: require GLES when building Wayland support
4b38be6 meta: add some missing Upstream-Status tags to patches
42c75cd weston: delete unused patch
521fac6 glibc: fix Upstream-Status tag
44a7bbc linux-firmware: package Broadcom BCM4339 firmware
f9d51cd libusb1: fix make install race
cb01f6d libusb1: upgrade from 1.0.19 to 1.0.20
b4e6f63 perl: fix spaces in brackets while using CC version
a59d019 u-boot: Update to 2015.10 release
e67c5b0 bitbake-prserv-tool: check file name
4e2c5e1 recipetool.append: don't choke on a trailing ; in a url
a35f79d yocto-bsp: Set SRCREV meta/machine revisions to AUTOREV
9d585b5 yocto-bsp: Set KTYPE to user selected base branch
1542c2a yocto-bsp: Typo on the file extension
f674ffa yocto-bsp: Avoid duplication of user patches ({{=machine}}-user-patches.scc)
49a465c package_manager.py: Delete installed_pkgs.txt file
ace895d rootfs.py: Stop using installed_pkgs.txt
ccb1616 lib/oe/distro_check: don't set empty proxy keys
8137a84 lib/oe/copy_buildsystem: Don't expand BB_TASKDEPDATA
a6c68d8 oeqa/selftest/sstatetests: prettier output for allarch test
92328b4 oeqa/selftest/signing: Added new test for signing sstate.
fbb03a8 oeqa/selftest/signing: New test for Signing packages in the package feeds.
13a4c38 qemu.bbclass: fix vardeps of QEMU_OPTIONS
51bd011 qemu.bbclass: correct the fsl ppc QEMU_EXTRAOPTIONS
753f31e autotools: Allow recipe-individual configure scripts
e281791 allarch: Force TARGET_*FLAGS variable values
e28e17e distro/maintainers.inc: include stress package details
76d2e46 image_types: improve wks path specification
70ae7a6 insane.bbclass: Avoid libdir QA check if PACKAGE_DEBUG_SPLIT_STYLE='debug-file-directory'
cf0dfdb classes/cpan-base: fix libdir for nativesdk
a205c4c bbclass: fix spelling mistakes
cf218e5 rootfs_*.bbclass: don't add BUILDNAME to do_rootfs vardepsexclude
7d8616c insane: Don't depend on BB_TASKDEPDATA
a9cc27e kernel: fix race condition between compile_kernelmodules and shared_workdir
fecb077 classes: Ensure pass setVar/setVarFlag strings, not integers
9167f20 classes/license: fix intermittent license collection warning
43c8867 classes/metadata_scm: fix git errors showing up on non-git repositories
59b27d5 sstate: respect GPG_BIN and GPG_HOME
4415dc5 archiver.bbclass: add bbappend when do_ar_recipe kernel and gcc packages
2f0ff3a archiver.bbclass: fix previous issue regarding work-shared for linux-yocto
0cc4eef waf.bbclass: filter out non -j from PARALLEL_MAKE
95719b0 ptest-gnome: extend EXTRA_OECONF in all builds, not just target
1b25a70 yocto-project-qs, ref-manual, poky.ent: CentOS Package updates
2e649d7 dev-manual: Updated runqemu command options list
bd62289 toaster-manual: Removed SDKMACHINE from the json file example.
c674cd7 ref-manual: Updated list of supported distros.
33d8cff ref-manual: Updated the GCC 5 migration section for 2.0
d9aabf9 gcc: Drop 4.8
2cb1aee layer.conf: Correct gcc-cross dependency
88f9310 bitbake: toaster: builds pages Fix the download cooker log link
d04af8b bitbake: toaster: project pages Link to image recipes table in notifications
70465c7 bitbake: toaster: tests: Re-write some cases to make them more maintainable
536b73f bitbake: data_smart: Only support lowercase OVERRIDES
fb01a66 bitbake: fetch2: Remove crazy code in unpack
7db88aa bitbake: parse: Don't try to expand __base_depends/__depends
4c04ce0 bitbake: cache: Don't try to expand __inherit_data
9d8e36a bitbake: toaster: localhostbectrl Pass DATABASE_URL in via the process environment
4677d8b bitbake: toaster: Remove the new-build-input button widget
55f4494 bitbake: toaster: projecttopbar Use the project in context to get num builds
e9d4962 bitbake: toaster: projectpage Disable/Enable build input if we have 0 layers
5fa4c73 bitbake: toaster: orm Fix get_number_of_builds to count all apart from IN_PROGRESS
c4032f4 bitbake: codeparser: Only load the codeparser cache once
e3b66c1 maintainers: mass reassign and cleanup
37ddd3e Revert "local.conf.sample: Disable image-prelink by default"
9cc221d yocto-bsp: Default kernel version to 4.1 on x86_64
7100c42 scripts: runqemu: remove QEMUARCH from help message
f47e4ad cairo: update 1.14.2 -> 1.14.4
603b4de cairo.inc: drop obsolete CFLAGS += "-ffat-lto-objects" workaround
e8833a6 cmake: update 3.3.1 -> 3.3.2
8b2b068 oe-selftest: add test for bitbake-layers show-recipes
480bbae oeqa/selftest/layerappend: fix test if build directory is not inside COREBASE
a301f6e oeqa/selftest/devtool: fix test if build directory is not inside COREBASE
fd6bf77 classes/distrodata: split SRC_URI properly before determining type
7cebff6 classes/buildhistory: split package history values only once
10fc534 conf/distro/include: drop old recipes from include files
37cfd80 gitignore: fix overzealous exclusion
1f6599b meta: Fix typos in Upstream-Status labels
7cace4c meta/conf/layer.conf: fix typo
ca8e1e5 texinfo-dummy-native: set SUMMARY instead of DESCRIPTION
64cd113 gstreamer1.0-meta-base: set SUMMARY instead of DESCRIPTION
1d42d59 mmc-utils: set SUMMARY instead of DESCRIPTION
6692540 swig: set SUMMARY instead of DESCRIPTION
47ae8eb alsa-plugins: set SUMMARY instead of DESCRIPTION
eac5fa9 tzcode-native: set SUMMARY instead of DESCRIPTION
0a30a1f linux-yocto.inc: set SUMMARY instead of DESCRIPTION
19e1a73 python-nose: add SUMMARY
b5f58c1 stress: add SUMMARY
5f9392a libunwind: add SUMMARY
1460e01 gptfdisk: add SUMMARY
0821c36 verify-homepage: fix recipe file selection
0c48921 verify-homepage: tidy up output and comments
0e348e7 verify-homepage: get expanded HOMEPAGE value
caaca00 verify-homepage: use scriptpath to find bitbake path
649b6bc libaio: don't disable linking to the system libraries
11a9c24 runqemu: don't specify IP when starting a VNC server
3b95964 qemurunner: Remove the timeout in run_serial
bbd6d07 libxslt: CVE-2015-7995
a0d2ea9 gstreamer1.0-rtsp-server: upgrade to version 1.6.1
2459ec2 gstreamer1.0-libav: upgrade to version 1.6.1
bce06e7 gstreamer1.0-plugins-ugly: upgrade to version 1.6.1
0ec3c62 gstreamer1.0-plugins-bad: upgrade to version 1.6.1
ba1bc63 gstreamer1.0-plugins-good: upgrade to version 1.6.1
4a55d12 gstreamer1.0-plugins-base: upgrade to version 1.6.1
8360f23 gstreamer1.0: upgrade to version 1.6.1
8800033 prelink: Fix various prelink issues on IA32, ARM, and MIPS.
920fb96 gcc: Update default Power GCC settings to use secure-plt
7b1763a glibc: Fix ld.so / prelink interface for ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
e63e191 qemurunner: Enable timestamps on kernel boot-up
a1ca788 openssl: fix mips64 configure support
5a10a6f at: modify sources in do_patch
78e0598 unzip: rename patch to reflect CVE fix
b80935a readline: rename patch to contain CVE reference
86d84ff qemu: upgrade to 2.4.0.1
4f0d756 gnome-desktop-testing: fix ptest output format
834de84 default-distrovars: remove less from WHITELIST_GPL-3.0
29bba95 lsof: don't export EXTRA_OEMAKE
3d37768 cmake.bbclass: don't duplicate CMAKE_C_FLAGS in CMAKE_C_FLAGS_RELEASE
efc07c2 rm_work.bbclass: Exclude do_rootfs stamp removal
5f9d16b cairo: fix license for cairo-script-interpreter
7328479 openssh: enable X11Forwarding if distro feature x11 is set
adeb820 acpid: Upgrade to 2.0.25
781dfd8 libidn: 1.30 -> 1.32
351c69a sqlite: 3.8.10.2 -> 3.9.0
c0fe43c rt-tests: bump to v0.94
cf972f9 gbm: Fix "configure: error: gbm requires --enable-dri"
17733cc xinetd: install xinetd supported services configuration
aa1844e combo-layer: introduce ability to exclude component from mass update
dcc446f linux-dtb.inc: refactor common code to function get_real_dtb_path_in_kernel
af9c7a4 linux-dtb.inc: refactor common code to function normalize_dtb
7eecb81 linux-dtb.inc: explicit test for empty string not needed
54df911 ptest-runner: Allow running of specific tests
54325b2 oeqa/testimage: Add support for test folder export.
ecbe135 oeqa/runtime/multilib: run the arch tests on connmand not connman-applet
2d1071e oeqa/runtime: remove dmesg test
42a5378 nfs-utils/statd: fix a segfault
77e3246 qemu: enable user mode for mips64 and mips64el
70600fb gnupg: fix find-version for beta checking
ab123ef rpm: define EM_AARCH64 for debugedit
af8c136 xserver-xorg: drop empty ${PN}-security-policy package
b667067 xserver-xorg: add Xwayland RRECOMMENDS
80f4d71 weston: add a PACKAGECONFIG option for xwayland support
883ab0f systemd: make dbus an optional build time dependency
2c5047f weston: add PACKAGECONFIG to build with systemd-login support
65ffeb5 systemd: add PACKAGECONFIG to build with compatibility libraries
4b29c80 os-release: put double-quotes around variable contents
0f516a5 cpio: fix testcase symlink-bad-lengths [ LIN8-947 ]
bceb9cb cpio: Fix symlink-bad-length test for 64-bit [ LIN8-947 ] architectures.
0ff3fc7 gtk+3: fix ALTERNATIVE_PRIORITY conflict with gtk+
eca12a6 coreutils: fix ALTERNATIVE_PRIORITY conflict with procps and mktemp
8de5315 util-linux: fix ALTERNATIVE_PRIORITY conflict with ncurses procps and e2fsprogs
3befb43 console-tools: fix ALTERNATIVE_PRIORITY conflict with kbd
5385ea8 debianutils: fix ALTERNATIVE_PRIORITY conflict with which
3a0bd40 linux-dtb.inc: use same variable name DTB for all elements of KERNEL_DEVICETREE
a879312 linux-dtb.inc: remove unneeded 'cd'
a23d1ca webkitgtk: Add upstream patch to fix build problem
69836e8 python: don't append -D__SOFTFP__ to TARGET_CC_ARCH for armv6/armv7a
38d1d63 prexport.bbclass: avoid export for native and crosssdk
d3da006 recipes: add distro_features_check for some packages
63690f0 scons.bbclass: SCons packages don't require do_configure
bffdc65 busybox: Schedule mdev after mountall
13ce7c2 busybox: Fix mdev block device automounting
b09f0f2 libarchive: rename patch to reflect CVE
116360f binutils: Fix XLP / Octeon 3 instruction clash
fd4f4d2 binutils: Fix octeon3 disassembly patch
REVERT: b1f23d1 build-appliance-image: Update to jethro head revision
REVERT: 7fe17a2 qemu: Security fix CVE-2016-2198
REVERT: 50700a7 qemu: Security fix CVE-2016-2197
REVERT: 1f0e615 libgcrypt: Security fix CVE-2015-7511
REVERT: dc5f155 uclibc: Security fix CVE-2016-2225
REVERT: ef13511 uclibc: Security fix CVE-2016-2224
REVERT: ae57ea0 libbsd: Security fix CVE-2016-2090
REVERT: eb9666a glibc: Security fix CVE-2015-7547
REVERT: 5b12268 build-appliance-image: Update to jethro head revision
REVERT: a3a374a curl: Secuirty fix CVE-2016-0755
REVERT: f4341a9 curl: Security fix CVE-2016-0754
REVERT: 35f4306 nettle: Security fix CVE-2015-8804
REVERT: 3e8a07b nettle: Security fix CVE-2015-8803 and CVE-2015-8805
REVERT: 5ffc326 socat: Security fix CVE-2016-2217
REVERT: 5cc5f99 libpng: Security fix CVE-2015-8472
REVERT: 21a816c libpng: Security fix CVE-2015-8126
REVERT: 6a0fbfa foomatic-filters: Security fixes CVE-2015-8327
REVERT: d57aaf7 foomatic-filters: Security fix CVE-2015-8560
REVERT: 941874a build-appliance-image: Update to jethro head revision
REVERT: d74a3cb cross-localedef-native: add ABI breaking glibc patch
REVERT: 12fae23 build-appliance-image: Update to jethro head revision
REVERT: 67ac9d6 e2fsprogs: Ensure we use the right mke2fs.conf when restoring from sstate
REVERT: 5812fc9 build-appliance-image: Update to jethro head revision
REVERT: 3de2492 ref-manual: Updated host package install requirements CentOS
REVERT: 79de8cf toaster-manual: Updated the "Installation" to have TOASTER_DIR information
REVERT: a23d262 toaster-manual: Updated instructions for production setup.
REVERT: b6def81 linux-yocto: Update SRCREV for genericx86* for 4.1, fixes CVE-2016-0728
REVERT: db0f8ac linux-yocto: Update SRCREV for genericx86* for 3.19, fixes CVE-2016-0728
REVERT: c8122a0 linux-yocto: Update SRCREV for genericx86* for 3.14, fixes CVE-2016-0728
REVERT: cdeb241 meta-yocto-bsp: Remove uvesafb (v86d) from generic x86 features
REVERT: 52cd219 yocto-bsp: Set SRCREV meta/machine revisions to AUTOREV
REVERT: a88d6cb yocto-bsp: Set KTYPE to user selected base branch
REVERT: 4e74b36 yocto-bsp: Avoid duplication of user patches ({{=machine}}-user-patches.scc)
REVERT: 6680773 yocto-bsp: Default kernel version to 4.1 on x86_64
REVERT: 4c075e7 piglit: don't use /tmp to write generated sources to
REVERT: ee52ac6 gen-lockedsig-cache: fix bad destination path joining
REVERT: e9f95df linux-yocto: Update SRCREV for qemux86* for 4.1, fixes CVE-2016-0728
REVERT: e63bab1 linux-yocto: Update SRCREV for qemux86* for 3.19, fixes CVE-2016-0728
REVERT: 64a4920 linux-yocto: Update SRCREV for qemux86* for 3.14, fixes CVE-2016-0728
REVERT: 5b043da libpng12: update URL that no longer exists
REVERT: 655c8a5 libpng: update URL that no longer exists
REVERT: 96fda8c busybox: fix build of last applet
REVERT: ae037d9 ghostscript: add dependency for pnglibconf.h
REVERT: 26eb877 gcr: Require x11 DISTRO_FEATURE
REVERT: e632cdb uClibc: enable utmp for shadow compatibility
REVERT: e8c9613 git: Security fix CVE-2015-7545
REVERT: 108ea6d glibc-locale: fix QA warning
REVERT: 9a88c1d grub: Security fix CVE-2015-8370
REVERT: 443b09a gdk-pixbuf: Security fix CVE-2015-7674
REVERT: 6c91068 librsvg: Security fix CVE-2015-7558
REVERT: 9fd2349 bind: Security fix CVE-2015-8461
REVERT: 5a40d9f bind: Security fix CVE-2015-8000
REVERT: 1bbf183 libxml2: Security fix CVE-2015-8710
REVERT: 2ec6d1d libxml2: Security fix CVE-2015-8241
REVERT: 55aafb5 dpkg: Security fix CVE-2015-0860
REVERT: 029948b tzdata: update to 2016a
REVERT: 2bcf141 tzcode: update to 2016a
REVERT: cc3a391 kernel-yocto: fix checkout bare-cloned kernel repositories
REVERT: 049be17 libpcre: bug fixes include security
REVERT: 5e94ac7 qemu: Security fix CVE-2015-7295
REVERT: 7ee1828 qemu: Security fix CVE-2016-1568
REVERT: ca6ec2e qemu: Security fix CVE-2015-8345
REVERT: b55a677 qemu: Security fix CVE-2015-7512
REVERT: 4922f47 qemu: Security fix CVE-2015-7504
REVERT: 3ec0e95 qemu: Security fix CVE-2015-8504
REVERT: 942ce53 openssl: Security fix CVE-2016-0701
REVERT: ce8ae1c openssl: Security fix CVE-2015-3197
REVERT: 080e027 tiff: Security fix CVE-2015-8784
REVERT: c6ae9c1 tiff: Security fix CVE-2015-8781
REVERT: 049b7db bind: CVE-2015-8704 and CVE-2015-8705
REVERT: d632a92 rpmresolve.c: Fix unfreed pointers that keep DB opened
REVERT: 5b993ed openssh: CVE-2016-1907
REVERT: 27ee5b4 glibc: CVE-2015-8776
REVERT: a4134af glibc: CVE-2015-9761
REVERT: e10ec6f glibc: CVE-2015-8779
REVERT: a5a965d glibc: CVE-2015-8777.patch
REVERT: 2fb7ee2 bitbake: toaster: make runbuilds loop
REVERT: b9ad87b nativesdk-buildtools-perl-dummy: Bump PR
REVERT: 0a1c63a nativesdk-buildtools-perl-dummy: properly set PACKAGE_ARCH
REVERT: d4b400e nativesdk-buildtools-perl-dummy: fix rebuilding when SDKMACHINE changes
REVERT: 8c8c4ed Revert "gstreamer1.0-plugins-good.inc: add gudev back to PACKAGECONFIG"
REVERT: b832202 Revert "gstreamer: Deal with merge conflict which breaks systemd builds"
REVERT: dd0ba9e build-appliance-image: Update to jethro head revision
REVERT: 325d205 gstreamer: Deal with merge conflict which breaks systemd builds
REVERT: 53b114b build-appliance-image: Update to jethro head revision
REVERT: 02be35d poky.conf: Bump version for 2.0.1 jethro release
REVERT: f5551f8 ref-manual: Updated the list of supported image types.
REVERT: aa179ae dev-manual: Added three new wic option descriptions.
REVERT: 20007c8 dev-manual: Added the --overhead-factor wic option description.
REVERT: 2dd7f46 dev-manual: Added the --extra-space wic option description.
REVERT: 81cc737 dev-manual: Added wic --notable option description.
REVERT: 2b1dce5 dev-manual:
REVERT: a6f5293 kernel/kernel-arch: Explicitly mapping between i386/x86_64 and x86 for kernel ARCH
REVERT: e79a538 openssh: update to 7.1p2
REVERT: b171076 devtool: reset: do clean for multiple recipes at once with -a
REVERT: 255115f devtool: sdk-update: fix error checking
REVERT: 3f69105 devtool: sdk-update: fix metadata update step
REVERT: 5ba94af devtool: sdk-update: fix not using updateserver config file option
REVERT: d03d145 classes/populate_sdk_ext: disable signature warnings
REVERT: 00ff950 classes/populate_sdk_ext: fix cascading from preparation failure
REVERT: 22446c6 scripts/oe-publish-sdk: add missing call to git update-server-info
REVERT: 8597a61 devtool: use cp instead of shutil.copytree
REVERT: 95cc641 buildhistory: fix not recording SDK information
REVERT: 84d48ac recipetool: create: fix error when extracting source to a specified directory
REVERT: 4369329 recipetool: create: detect when specified URL returns a web page
REVERT: 4c3191f recipetool: create: prevent attempting to unpack entire DL_DIR
REVERT: caca77e recipetool: create: fix do_install handling for makefile-only software
REVERT: 383159e recipetool: create: avoid traceback on fetch error
REVERT: be40baa recipetool: create: handle https://....git URLs
REVERT: a897bfd devtool: sdk-update: fix traceback without update server set
REVERT: 9c4b61e classes/populate_sdk_ext: error out of install if buildtools install fails
REVERT: 4c07dd2 gstreamer1.0-plugins-good.inc: add gudev back to PACKAGECONFIG
REVERT: 83b72d8 linux-yocto: Update Genericx86* BSP to 4.1.15 kernel
REVERT: 44639bd libaio: don't disable linking to the system libraries
REVERT: a0be9bd linux-yocto/4.1: update to v4.1.15
REVERT: 53f0290 libxml2: security fix CVE-2015-5312
REVERT: f4b0c49 libxml2: security fix CVE-2015-8242
REVERT: fb409c9 libxml2: security fix CVE-2015-7500
REVERT: 55d097a libxml2: security fix CVE-2015-7499
REVERT: 8e6b2d6 libxml2: security fix CVE-2015-7497
REVERT: 332eb1d libxml2: security fix CVE-2015-7498
REVERT: cbc4e83 libxml2: security fix CVE-2015-8035
REVERT: c4b71e1 libxml2: security fix CVE-2015-7942
REVERT: fdea03d libxml2: security fix CVE-2015-8317
REVERT: 6fc1109 libxml2: security fix CVE-2015-7941
REVERT: 9eb4ce0 openssl: fix for CVE-2015-3195
REVERT: 6880f82 openssl: fix for CVE-2015-3194
REVERT: 7dcaa84 openssl: fix for CVE-2015-3193
REVERT: 435139b logrotate: do not move binary logrotate to /usr/bin
REVERT: 5f49c0a cairo: fix license for cairo-script-interpreter
REVERT: a29ec81 glibc: Fix ld.so / prelink interface for ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
REVERT: b1e980f gcc: Update default Power GCC settings to use secure-plt
REVERT: ed82690 prelink: Fix various prelink issues on IA32, ARM, and MIPS.
REVERT: 9a620da autotools: Allow recipe-individual configure scripts
REVERT: f828071 toolchain-scripts.bbclass: unset command_not_found_handle
REVERT: 49858bd devtool: upgrade: fetch remote repository before checking out new revision
REVERT: d213452 devtool: upgrade: remove erroneous error when not renaming recipe
REVERT: fec97f6 devtool: upgrade: fix updating PV and SRCREV
REVERT: 3b4f659 devtool: upgrade: fix removing other recipes from workspace on reset
REVERT: 61a7de0 devtool: include do_patch in SRCTREECOVEREDTASKS
REVERT: 82c0072 toolchain-shar-extract.sh: do not allow $ in paths for ext SDK
REVERT: f181e72 scripts/gen-lockedsig-cache: improve output
REVERT: 4b5d4ca toolchain-shar-extract.sh: proper fix for additional env setup scripts
REVERT: d2ea8f1 toolchain-shar-relocate: don't assume last state of env_setup_script is good
REVERT: 02ef437 populate_sdk_ext.bbclass: Be more permissive on the name of the buildtools
REVERT: 3653b17 classes/populate_sdk_ext: fail if SDK_ARCH != BUILD_ARCH
REVERT: 8879571 classes/populate_sdk_ext: tweak reporting of workspace exclusion
REVERT: eeda3c6 classes/populate_sdk_ext: make it clear when SDK installation has failed
REVERT: dee9fbe classes/populate_sdk_ext: tidy up preparation log file writing
REVERT: d001d46 classes/license: fix intermittent license collection warning
REVERT: 777451c classes/metadata_scm: fix git errors showing up on non-git repositories
REVERT: cb0ca72 oeqa/selftest/layerappend: fix test if build directory is not inside COREBASE
REVERT: 8970ad6 oeqa/selftest/devtool: fix test if build directory is not inside COREBASE
REVERT: 4f7fdd0 classes/distrodata: split SRC_URI properly before determining type
REVERT: 3b7df55 uninative.bbclass: Choose the correct loader based on BUILD_ARCH
REVERT: f3d7c3f openssl: sanity check that the bignum module is present
REVERT: 96b1b5c glibc: Backported a patch to fix glibc's bug(18589)
REVERT: 7aecb57 directfb.inc: force bfd linker for armv7a
REVERT: 75ca2c8 texinfo: don't create dependency on INHERIT variable
REVERT: 02c7b3f package_manager.py: define info_dir and status_file when OPKGLIBDIR isn't the default
REVERT: 003c94f libsdl2: require GLES when building Wayland support
REVERT: ad6db01 gst-plugins-bad: add PACKAGECONFIGs for voamrwbenc, voaacenc, resindvd
REVERT: f0d87fe gstreamer1.0-plugins-good: fix PACKAGECONFIG for gudev and add one for v4l2 and libv4l2
REVERT: 35f34a6 gstreamer1.0-plugins-bad: fix dependencies for uvch264 PACKAGECONFIG
REVERT: 3b77e20 gstreamer1.0-plugins-{base,good}: update PACKAGECONFIGs
REVERT: e2d4412 libunwind: fix build for qemuarm
REVERT: ef69078 guile, mailx, gcc, opensp, gstreamer1.0-libav, libunwind: disable thumb where it fails for qemuarm
REVERT: 4700e40 icu: force arm mode
REVERT: 743ee04 libxcb: Add a workaround for gcc5 bug on mips
REVERT: 8a3deca bitbake: fetch: use orig localpath when calling orig method
REVERT: 0073b23 yocto-bsp: Typo on the file extension
REVERT: 71dbbcd bsp-guide: Updated the license statement.
REVERT: 41f1026 dev-manual: Correction to the KVM stuff in the runqemu commands.
REVERT: 38e3c6e mega-manual: Added four new figures for GUI example.
REVERT: b99ec28 poky.ent: Fixed POKYVERSION variable.
REVERT: c670dc7 yocto-project-qs, ref-manual, poky.ent: CentOS Package updates
REVERT: b968190 dev-manual: Updated runqemu command options list
REVERT: 1278753 toaster-manual: Removed SDKMACHINE from the json file example.
REVERT: 7b25b70 ref-manual: Updated list of supported distros.
REVERT: d9423fb ref-manual: Updated the GCC 5 migration section for 2.0
REVERT: 347347a bitbake: lib/bb/utils: improve edit_bblayers_conf() handling of bblayers.conf formatting
REVERT: 5935783 bitbake: lib/bb/utils: fix error in edit_metadata() when deleting first line
REVERT: 7fdad70 rpcbind: Security Advisory - rpcbind - CVE-2015-7236
REVERT: 0cb2fa5 subversion: fix CVE-2015-3187
REVERT: 5b52e9b subversion: fix CVE-2015-3184
REVERT: 59bdde4 linux-firmware: rtl8192cx: Add latest available firmware
REVERT: 8ad2bcc init-install-efi: fix script for gummiboot loader
REVERT: c3087bd init-install-efi: fix script for eMMC installation
REVERT: d2bf9fb pulseaudio: Fix HDMI profile selection
REVERT: 0556c58 allarch: Force TARGET_*FLAGS variable values
REVERT: e683dac libsndfile: fix CVE-2014-9756
REVERT: 092757e libxslt: CVE-2015-7995
REVERT: dab5555 unzip: rename patch to reflect CVE fix
REVERT: 1753d4a readline: rename patch to contain CVE reference
REVERT: 9dd3422 libarchive: rename patch to reflect CVE
REVERT: 1401976 binutils: Fix octeon3 disassembly patch
REVERT: a54a0db opkg: add cache filename length fixes

git-subtree-dir: yocto-poky
git-subtree-split: 8358e543ab95a1d2b1d19c1e944275daa17378c1
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

yocto-poky/documentation/Makefile

diff --git a/yocto-poky/documentation/Makefile b/yocto-poky/documentation/Makefile
index 99adea2..418d3ca 100644
--- a/yocto-poky/documentation/Makefile
+++ b/yocto-poky/documentation/Makefile
@@ -128,12 +128,14 @@
            figures/wip.png
         else
 TARFILES = dev-style.css dev-manual.html \
-           figures/app-dev-flow.png figures/bsp-dev-flow.png \
+           figures/bsp-dev-flow.png \
            figures/dev-title.png figures/git-workflow.png \
            figures/index-downloads.png figures/kernel-dev-flow.png \
            figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
            figures/source-repos.png figures/yp-download.png \
            figures/recipe-workflow.png figures/build-workspace-directory.png \
+           figures/devtool-add-flow.png figures/devtool-modify-flow.png \
+           figures/devtool-upgrade-flow.png \
            eclipse
 	endif
 
@@ -198,9 +200,9 @@
 	figures/using-a-pre-built-image.png \
 	figures/poky-title.png figures/buildhistory.png \
         figures/buildhistory-web.png \
-	figures/adt-title.png figures/bsp-title.png \
+	figures/sdk-title.png figures/bsp-title.png \
 	figures/kernel-dev-title.png figures/kernel-architecture-overview.png \
-	figures/app-dev-flow.png figures/bsp-dev-flow.png \
+	figures/bsp-dev-flow.png \
         figures/dev-title.png \
 	figures/git-workflow.png figures/index-downloads.png \
         figures/kernel-dev-flow.png \
@@ -242,7 +244,12 @@
 	figures/sdk-generation.png figures/recipe-workflow.png \
 	figures/build-workspace-directory.png figures/mega-title.png \
 	figures/toaster-title.png figures/hosted-service.png \
-	figures/simple-configuration.png
+	figures/simple-configuration.png figures/devtool-add-flow.png \
+	figures/devtool-modify-flow.png figures/devtool-upgrade-flow.png \
+	figures/compatible-layers.png figures/import-layer.png figures/new-project.png \
+	figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
+	figures/sdk-devtool-add-flow.png figures/sdk-installed-extensible-sdk-directory.png \
+	figures/sdk-devtool-modify-flow.png figures/sdk-eclipse-dev-flow.png
 	endif
 
 MANUALS = $(DOC)/$(DOC).html
@@ -268,12 +275,13 @@
 STYLESHEET = $(DOC)/*.css
 endif
 
-
-ifeq ($(DOC),adt-manual)
+ifeq ($(DOC),sdk-manual)
 XSLTOPTS = --xinclude
 ALLPREQ = html eclipse tarball
-TARFILES = adt-manual.html adt-style.css figures/adt-title.png \
-           figures/using-a-pre-built-image.png \
+TARFILES = sdk-manual.html sdk-style.css figures/sdk-title.png \
+           figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
+	   figures/sdk-installed-extensible-sdk-directory.png figures/sdk-devtool-add-flow.png \
+	   figures/sdk-devtool-modify-flow.png figures/sdk-eclipse-dev-flow.png \
            eclipse
 MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
 FIGURES = figures
@@ -332,7 +340,8 @@
 ALLPREQ = html tarball
 TARFILES = toaster-manual.html toaster-manual-style.css \
 	   figures/toaster-title.png figures/simple-configuration.png \
-	   figures/hosted-service.png
+	   figures/hosted-service.png \
+	   figures/compatible-layers.png figures/import-layer.png figures/new-project.png
 MANUALS = $(DOC)/$(DOC).html
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
@@ -394,11 +403,11 @@
 .PHONY : eclipse-generate eclipse-resolve-links
 
 eclipse-generate:
-ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-dev profile-manual ref-manual yocto-project-qs),)
+ifeq ($(filter $(DOC), sdk-manual bsp-guide dev-manual kernel-dev profile-manual ref-manual yocto-project-qs),)
 	@echo " "
 	@echo "ERROR: You can only create eclipse documentation"
 	@echo "       of the following documentation parts:"
-	@echo "       - adt-manual"
+	@echo "       - sdk-manual"
 	@echo "       - bsp-guide"
 	@echo "       - dev-manual"
 	@echo "       - kernel-dev"

yocto-poky/documentation/README

diff --git a/yocto-poky/documentation/README b/yocto-poky/documentation/README
index d01678d..a4e70a8 100644
--- a/yocto-poky/documentation/README
+++ b/yocto-poky/documentation/README
@@ -34,14 +34,16 @@
 
 Folders exist for individual manuals as follows:
 
-* adt-manual       - The Yocto Project Application Developer's Guide.
+* sdk-manual       - The Yocto Project Software Development Kit (SDK) Developer's Guide.
 * bsp-guide        - The Yocto Project Board Support Package (BSP) Developer's Guide
 * dev-manual       - The Yocto Project Development Manual
 * kernel-dev       - The Yocto Project Linux Kernel Development Manual
 * ref-manual       - The Yocto Project Reference Manual
 * yocto-project-qs - The Yocto Project Quick Start
-* mega-manual      - An aggregated manual comprised of all YP manuals and guides
+* mega-manual      - The Yocto Project Mega-Manual, which is an aggregated manual comprised
+                     of all YP manuals and guides
 * profile-manual   - The Yocto Project Profile and Tracing Manual
+* toaster-manual   - The Toaster Manual
 
 Each folder is self-contained regarding content and figures.  Note that there
 is a sed file needed to process the links of the mega-manual.  The sed file
@@ -68,10 +70,10 @@
 To build a manual, you run the make command and pass it the name
 of the folder containing the manual's contents.
 For example, the following command run from the documentation directory
-creates an HTML and a PDF version of the ADT manual.
+creates an HTML version of the SDK manual.
 The DOC variable specifies the manual you are making:
 
-     $ make DOC=adt-manual
+     $ make DOC=sdk-manual
 
 poky.ent
 ========

yocto-poky/documentation/adt-manual/adt-manual.xml

diff --git a/yocto-poky/documentation/adt-manual/adt-manual.xml b/yocto-poky/documentation/adt-manual/adt-manual.xml
index 67b330a..972f8bf 100644
--- a/yocto-poky/documentation/adt-manual/adt-manual.xml
+++ b/yocto-poky/documentation/adt-manual/adt-manual.xml
@@ -91,6 +91,11 @@
                 <date>October 2015</date>
                 <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>Sometime in 2016</date>
+                <revremark>Released with the future Yocto Project 2.1 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>

yocto-poky/documentation/bsp-guide/bsp-guide.xml

diff --git a/yocto-poky/documentation/bsp-guide/bsp-guide.xml b/yocto-poky/documentation/bsp-guide/bsp-guide.xml
index d9bcc3f..c00b345 100644
--- a/yocto-poky/documentation/bsp-guide/bsp-guide.xml
+++ b/yocto-poky/documentation/bsp-guide/bsp-guide.xml
@@ -22,11 +22,11 @@
 
         <authorgroup>
             <author>
-                <firstname>Tom</firstname> <surname>Zanussi</surname>
+                <firstname>Saul</firstname> <surname>Wold</surname>
                 <affiliation>
                     <orgname>Intel Corporation</orgname>
                 </affiliation>
-                <email>tom.zanussi@intel.com</email>
+                <email>saul.wold@intel.com</email>
             </author>
             <author>
                 <firstname>Richard</firstname> <surname>Purdie</surname>
@@ -103,6 +103,11 @@
                 <date>October 2015</date>
                 <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>April 2016</date>
+                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

yocto-poky/documentation/bsp-guide/bsp.xml

diff --git a/yocto-poky/documentation/bsp-guide/bsp.xml b/yocto-poky/documentation/bsp-guide/bsp.xml
index ec39ec9..b0562c7 100644
--- a/yocto-poky/documentation/bsp-guide/bsp.xml
+++ b/yocto-poky/documentation/bsp-guide/bsp.xml
@@ -60,16 +60,28 @@
                 <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>.
                 If you go to that interface, you will find near the bottom of the list
                 under "Yocto Metadata Layers" several BSP layers all of which are
-                supported by the Yocto Project (e.g. <filename>meta-minnow</filename>,
-                <filename>meta-raspberrypi</filename>, and
+                supported by the Yocto Project (e.g. <filename>meta-raspberrypi</filename> and
                 <filename>meta-intel</filename>).
                 Each of these layers is a repository unto itself and clicking on a
                 layer reveals information that includes two links from which you can choose
                 to set up a clone of the layer's repository on your local host system.
-                Here is an example that clones the MinnowBoard BSP layer:
+                Here is an example that clones the Raspberry Pi BSP layer:
                 <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/meta-minnow
+     $ git clone git://git.yoctoproject.org/meta-raspberrypi
                 </literallayout>
+            </para>
+
+            <para>
+                In addition to BSP layers near the bottom of that referenced
+                Yocto Project Source Repository, the
+                <filename>meta-yocto-bsp</filename> layer is part of the
+                shipped <filename>poky</filename> repository.
+                The <filename>meta-yocto-bsp</filename> layer maintains several
+                BSPs such as the Beaglebone, EdgeRouter, and generic versions of
+                both 32 and 64-bit IA machines.
+            </para>
+
+            <para>
                 For information on the BSP development workflow, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</ulink>"
                 section in the Yocto Project Development Manual.
@@ -80,8 +92,9 @@
             </para>
 
             <para>
-                The layer's base directory (<filename>meta-<replaceable>bsp_name</replaceable></filename>) is the root
-                of the BSP Layer.
+                The layer's base directory
+                (<filename>meta-<replaceable>bsp_name</replaceable></filename>)
+                is the root of the BSP Layer.
                 This root is what you add to the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
                 variable in the <filename>conf/bblayers.conf</filename> file found in the
@@ -97,7 +110,7 @@
                 <literallayout class='monospaced'>
      BBLAYERS ?= " \
        /usr/local/src/yocto/meta \
-       /usr/local/src/yocto/meta-yocto \
+       /usr/local/src/yocto/meta-poky \
        /usr/local/src/yocto/meta-yocto-bsp \
        /usr/local/src/yocto/meta-mylayer \
        "
@@ -121,6 +134,8 @@
                 An example of this type of layer is the <filename>meta-intel</filename> layer,
                 which contains a number of individual BSP sub-layers, as well as a directory
                 named <filename>common/</filename> full of common content across those layers.
+                Another example is the <filename>meta-yocto-bsp</filename> layer mentioned
+                earlier.
             </para>
 
             <para>
@@ -130,7 +145,6 @@
             </para>
         </section>
 
-
         <section id="bsp-filelayout">
             <title>Example Filesystem Layout</title>
 
@@ -194,33 +208,142 @@
             </para>
 
             <para>
-                Below is an example of the eMenlow BSP:
+                Below is an example of the Raspberry Pi BSP:
 
                 <literallayout class='monospaced'>
-     meta-emenlow/COPYING.MIT
-     meta-emenlow/README
-     meta-emenlow/README.sources
-     meta-emenlow/binary/
-     meta-emenlow/conf/
-     meta-emenlow/conf/layer.conf
-     meta-emenlow/conf/machine/
-     meta-emenlow/conf/machine/emenlow-noemgd.conf
-     meta-emenlow/recipes-bsp/
-     meta-emenlow/recipes-bsp/formfactor/
-     meta-emenlow/recipes-bsp/formfactor/formfactor/
-     meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend
-     meta-emenlow/recipes-bsp/formfactor/formfactor/emenlow-noemgd/
-     meta-emenlow/recipes-bsp/formfactor/formfactor/emenlow-noemgd/machconfig
-     meta-emenlow/recipes-graphics/
-     meta-emenlow/recipes-graphics/xorg-xserver
-     meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config
-     meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
-     meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow-noemgd
-     meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow-noemgd/xorg.config
-     meta-emenlow/recipes-kernel/
-     meta-emenlow/recipes-kernel/linux/
-     meta-emenlow/recipes-kernel/linux/linux-yocto-dev.bbappend
-     meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend
+     meta-raspberrypi/COPYING.MIT
+     meta-raspberrypi/README
+     meta-raspberrypi/classes
+     meta-raspberrypi/classes/linux-raspberrypi-base.bbclass
+     meta-raspberrypi/classes/sdcard_image-rpi.bbclass
+     meta-raspberrypi/conf/
+     meta-raspberrypi/conf/layer.conf
+     meta-raspberrypi/conf/machine/
+     meta-raspberrypi/conf/machine/raspberrypi.conf
+     meta-raspberrypi/conf/machine/raspberrypi0.conf
+     meta-raspberrypi/conf/machine/raspberrypi2.conf
+     meta-raspberrypi/conf/machine/raspberrypi3.conf
+     meta-raspberrypi/conf/machine/include
+     meta-raspberrypi/conf/machine/include/rpi-base.inc
+     meta-raspberrypi/conf/machine/include/rpi-default-providers.inc
+     meta-raspberrypi/conf/machine/include/rpi-default-settings.inc
+     meta-raspberrypi/conf/machine/include/rpi-default-versions.inc
+     meta-raspberrypi/conf/machine/include/rpi-tune-arm1176jzf-s.inc
+     meta-raspberrypi/files
+     meta-raspberrypi/files/custom-licenses
+     meta-raspberrypi/files/custom-licenses/Broadcom
+     meta-raspberrypi/recipes-bsp
+     meta-raspberrypi/recipes-bsp/bootfiles
+     meta-raspberrypi/recipes-bsp/bootfiles/bcm2835-bootfiles.bb
+     meta-raspberrypi/recipes-bsp/bootfiles/rpi-config_git.bb
+     meta-raspberrypi/recipes-bsp/common
+     meta-raspberrypi/recipes-bsp/common/firmware.inc
+     meta-raspberrypi/recipes-bsp/formfactor_00.bbappend
+     meta-raspberrypi/recipes-bsp/formfactor/raspberrypi/machconfig
+     meta-raspberrypi/recipes-bsp/rpi-mkimage_git.bb
+     meta-raspberrypi/recipes-bsp/rpi-mkimage/License
+     meta-raspberrypi/recipes-bsp/rpi-mkimage/open-files-relative-to-script.patch
+     meta-raspberrypi/recipes-bsp/u-boot/u-boot-rpi_git.bb
+     meta-raspberrypi/recipes-core
+     meta-raspberrypi/recipes-core/images
+     meta-raspberrypi/recipes-core/images/rpi-basic-image.bb
+     meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb
+     meta-raspberrypi/recipes-core/images/rpi-test-image.bb
+     meta-raspberrypi/recipes-core/packagegroups
+     meta-raspberrypi/recipes-core/packagegroups/packagegroup-rpi-test.bb
+     meta-raspberrypi/recipes-core/psplash
+     meta-raspberrypi/recipes-core/psplash/files
+     meta-raspberrypi/recipes-core/psplash/psplash_git.bbappend
+     meta-raspberrypi/recipes-core/psplash/files/psplash-raspberrypi-img.h
+     meta-raspberrypi/recipes-devtools
+     meta-raspberrypi/recipes-devtools/bcm2835
+     meta-raspberrypi/recipes-devtools/bcm2835/bcm2835_1.46.bb
+     meta-raspberrypi/recipes-devtools/pi-blaster
+     meta-raspberrypi/recipes-devtools/pi-blaster/files
+     meta-raspberrypi/recipes-devtools/pi-blaster/*.patch
+     meta-raspberrypi/recipes-devtools/pi-blaster/pi-blaster.inc
+     meta-raspberrypi/recipes-devtools/pi-blaster/pi-blaster_git.bb
+     meta-raspberrypi/recipes-devtools/python
+     meta-raspberrypi/recipes-devtools/python/python-rtimu
+     meta-raspberrypi/recipes-devtools/python/python-rtimu/*.patch
+     meta-raspberrypi/recipes-devtools/python/python-rtimu_git.bb
+     meta-raspberrypi/recipes-devtools/python/python-sense-hat_2.1.0.bb
+     meta-raspberrypi/recipes-devtools/python/rpi-gpio
+     meta-raspberrypi/recipes-devtools/python/rpi-gpio/*.patch
+     meta-raspberrypi/recipes-devtools/python/rpi-gpio_0.6.1.bb
+     meta-raspberrypi/recipes-devtools/python/rpio
+     meta-raspberrypi/recipes-devtools/python/rpio/*.patch
+     meta-raspberrypi/recipes-devtools/python/rpio_0.10.0.bb
+     meta-raspberrypi/recipes-devtools/wiringPi
+     meta-raspberrypi/recipes-devtools/wiringPi/files
+     meta-raspberrypi/recipes-devtools/wiringPi/files/*.patch
+     meta-raspberrypi/recipes-devtools/wiringPi/wiringpi
+     meta-raspberrypi/recipes-devtools/wiringPi/wiringpi/*.patch
+     meta-raspberrypi/recipes-devtools/wiringPi/wiringpi_git.bb
+     meta-raspberrypi/recipes-graphics
+     meta-raspberrypi/recipes-graphics/eglinfo
+     meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-fb_%.bbappend
+     meta-raspberrypi/recipes-graphics/eglinfo/eglinfo-x11_%.bbappend
+     meta-raspberrypi/recipes-graphics/userland
+     meta-raspberrypi/recipes-graphics/userland/userland
+     meta-raspberrypi/recipes-graphics/userland/userland/*.patch
+     meta-raspberrypi/recipes-graphics/userland/userland_git.bb
+     meta-raspberrypi/recipes-graphics/vc-graphics
+     meta-raspberrypi/recipes-graphics/vc-graphics/files
+     meta-raspberrypi/recipes-graphics/vc-graphics/files/egl.pc
+     meta-raspberrypi/recipes-graphics/vc-graphics/files/vchiq.sh
+     meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics-hardfp.bb
+     meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.bb
+     meta-raspberrypi/recipes-graphics/vc-graphics/vc-graphics.inc
+     meta-raspberrypi/recipes-graphics/wayland
+     meta-raspberrypi/recipes-graphics/wayland/weston_%.bbappend
+     meta-raspberrypi/recipes-graphics/weston
+     meta-raspberrypi/recipes-graphics/weston/weston_%.bbappend
+     meta-raspberrypi/recipes-graphics/xorg-xserver
+     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config
+     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi
+     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf
+     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d
+     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
+     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/99-pitft.conf
+     meta-raspberrypi/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
+     meta-raspberrypi/recipes-kernel
+     meta-raspberrypi/recipes-kernel/linux-firmware
+     meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware
+     meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware/LICENSE.broadcom_brcm80211
+     meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware/brcmfmac43430-sdio.bin
+     meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware/brcmfmac43430-sdio.txt
+     meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_git.bbappend
+     meta-raspberrypi/recipes-kernel/linux
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-3.14
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-3.14/*.patch
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-3.18
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-3.18/*.patch
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.1
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.1/*.patch
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi.inc
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_3.14.bb
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_3.18.bb
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.1.bb
+     meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.4.bb
+     meta-raspberrypi/recipes-kernel/linux/linux.inc
+     meta-raspberrypi/recipes-multimedia
+     meta-raspberrypi/recipes-multimedia/gstreamer
+     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx
+     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx/*.patch
+     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_%.bbappend
+     meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
+     meta-raspberrypi/recipes-multimedia/omxplayer
+     meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer
+     meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer/*.patch
+     meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer_git.bb
+     meta-raspberrypi/scripts
+     meta-raspberrypi/scripts/lib
+     meta-raspberrypi/scripts/lib/image
+     meta-raspberrypi/scripts/lib/image/canned-wks
+     meta-raspberrypi/scripts/lib/image/canned-wks/sdimage-raspberrypi.wks
                 </literallayout>
             </para>
 
@@ -241,7 +364,7 @@
             <para>
                 These optional files satisfy licensing requirements for the BSP.
                 The type or types of files here can vary depending on the licensing requirements.
-                For example, in the eMenlow BSP all licensing requirements are handled with the
+                For example, in the Raspberry Pi BSP all licensing requirements are handled with the
                 <filename>COPYING.MIT</filename> file.
             </para>
 
@@ -363,7 +486,7 @@
 
      # We have a recipes directory, add to BBFILES
      BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
-             ${LAYERDIR}/recipes-*/*/*.bbappend"
+                 ${LAYERDIR}/recipes-*/*/*.bbappend"
 
      BBFILE_COLLECTIONS += "<replaceable>bsp</replaceable>"
      BBFILE_PATTERN_<replaceable>bsp</replaceable> = "^${LAYERDIR}/"
@@ -375,20 +498,21 @@
 
             <para>
                 To illustrate the string substitutions, here are the corresponding statements
-                from the eEmenlow <filename>conf/layer.conf</filename> file:
+                from the Raspberry Pi <filename>conf/layer.conf</filename> file:
                <literallayout class='monospaced'>
-     # We have a conf and classes directory, add to BBPATH
+     # We have a conf and classes directory, append to BBPATH
      BBPATH .= ":${LAYERDIR}"
 
-     # We have recipes-* directories, add to BBFILES
-     BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
-	     ${LAYERDIR}/recipes-*/*/*.bbappend"
+     # We have a recipes directory containing .bb and .bbappend files, add to BBFILES
+     BBFILES += "${LAYERDIR}/recipes*/*/*.bb \
+                 ${LAYERDIR}/recipes*/*/*.bbappend"
 
-     BBFILE_COLLECTIONS += "emenlow"
-     BBFILE_PATTERN_emenlow := "^${LAYERDIR}/"
-     BBFILE_PRIORITY_emenlow = "6"
+     BBFILE_COLLECTIONS += "raspberrypi"
+     BBFILE_PATTERN_raspberrypi := "^${LAYERDIR}/"
+     BBFILE_PRIORITY_raspberrypi = "9"
 
-     LAYERDEPENDS_emenlow = "intel"
+     # Additional license directories.
+     LICENSE_PATH += "${LAYERDIR}/files/custom-licenses"
                 </literallayout>
             </para>
 
@@ -450,13 +574,11 @@
             <para>
                 To use an include file, you simply include them in the
                 machine configuration file.
-                For example, the eEmenlow BSP
-                <filename>emenlow-noemgd.conf</filename> contains the
-                following statements:
+                For example, the Raspberry Pi BSP
+                <filename>raspberrypi3.conf</filename> contains the
+                following statement:
                 <literallayout class='monospaced'>
-     require conf/machine/include/intel-core2-32-common.inc
-     require conf/machine/include/intel-common-pkgarch.inc
-     require conf/machine/include/meta-intel.inc
+     include conf/machine/raspberrypi2.conf
                 </literallayout>
             </para>
             </section>
@@ -474,20 +596,22 @@
                 This optional directory contains miscellaneous recipe files for
                 the BSP.
                 Most notably would be the formfactor files.
-                For example, in the eMenlow BSP there is the
+                For example, in the Raspberry Pi BSP there is the
                 <filename>formfactor_0.0.bbappend</filename> file, which is an
                 append file used to augment the recipe that starts the build.
                 Furthermore, there are machine-specific settings used during
                 the build that are defined by the
                 <filename>machconfig</filename> file further down in the
                 directory.
-                In the eMenlow example, the <filename>machconfig</filename>
-                file supports the Video Electronics Standards Association
-                (VESA) graphics driver:
+                Here is the <filename>machconfig</filename>
+                file for the Raspberry Pi BSP:
                 <literallayout class='monospaced'>
-     # Assume a USB mouse and keyboard are connected
      HAVE_TOUCHSCREEN=0
      HAVE_KEYBOARD=1
+
+     DISPLAY_CAN_ROTATE=0
+     DISPLAY_ORIENTATION=0
+     DISPLAY_DPI=133
                 </literallayout>
             </para>
 
@@ -515,18 +639,6 @@
                 special requirements for graphics support.
                 All files that are needed for the BSP to support a display are
                 kept here.
-                For example, the <filename>meta-emenlow</filename> layer,
-                which supports the eMenlow platform consisting of the
-                <trademark class='registered'>Intel</trademark>
-                <trademark class='trade'>Atom</trademark>
-                Z5xx processor with the
-                <trademark class='registered'>Intel</trademark>
-                System Controller Hub US15W, uses these files for supporting
-                the Video Electronics Standards Association (VESA) graphics:
-                <literallayout class='monospaced'>
-     meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
-     meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow-noemgd/xorg.conf
-                </literallayout>
             </para>
             </section>
 
@@ -551,47 +663,63 @@
                 the <filename>meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux</filename> directory).
             </para>
             <para>
-                Suppose you are using the <filename>linux-yocto_3.14.bb</filename> recipe to build
+                Suppose you are using the <filename>linux-yocto_4.4.bb</filename> recipe to build
                 the kernel.
                 In other words, you have selected the kernel in your
                 <replaceable>bsp_name</replaceable><filename>.conf</filename> file by adding these types
                 of statements:
                 <literallayout class='monospaced'>
      PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-     PREFERRED_VERSION_linux-yocto ?= "3.14%"
+     PREFERRED_VERSION_linux-yocto ?= "4.4%"
                 </literallayout>
                 <note>
                     When the preferred provider is assumed by default, the
                     <filename>PREFERRED_PROVIDER</filename> statement does not appear in the
                     <replaceable>bsp_name</replaceable><filename>.conf</filename> file.
                 </note>
-                You would use the <filename>linux-yocto_3.14.bbappend</filename> file to append
-                specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.
+                You would use the <filename>linux-yocto_4.4.bbappend</filename>
+                file to append specific BSP settings to the kernel, thus
+                configuring the kernel for your particular BSP.
             </para>
+
             <para>
-                As an example, look at the existing eMenlow BSP.
-                The append file used is:
+                As an example, consider the following append file
+                used by the BSPs in <filename>meta-yocto-bsp</filename>:
                 <literallayout class='monospaced'>
-     meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend
+     meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend
                 </literallayout>
                 The following listing shows the file.
-                Be aware that the actual commit ID strings in this example listing might be different
-                than the actual strings in the file from the <filename>meta-intel</filename>
-                Git source repository.
+                Be aware that the actual commit ID strings in this
+                example listing might be different than the actual strings
+                in the file from the <filename>meta-yocto-bsp</filename>
+                layer upstream.
                 <literallayout class='monospaced'>
-     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+     KBRANCH_genericx86  = "standard/base"
+     KBRANCH_genericx86-64  = "standard/base"
 
-     COMPATIBLE_MACHINE_emenlow-noemgd = "emenlow-noemgd"
-     KMACHINE_emenlow-noemgd = "emenlow"
-     KBRANCH_emenlow-noemgd = "standard/base"
-     KERNEL_FEATURES_append_emenlow-noemgd = " features/drm-gma500/drm-gma500.scc"
+     KMACHINE_genericx86 ?= "common-pc"
+     KMACHINE_genericx86-64 ?= "common-pc-64"
+     KBRANCH_edgerouter = "standard/edgerouter"
+     KBRANCH_beaglebone = "standard/beaglebone"
+     KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 
-     LINUX_VERSION_emenlow-noemgd = "3.14.19"
-     SRCREV_machine_emenlow-noemgd = "902f34d36102a4b2008b776ecae686f80d307e12"
-     SRCREV_meta_emenlow-noemgd = "28e39741b8b3018334021d981369d3fd61f18f5b"
+     SRCREV_machine_genericx86    ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
+     SRCREV_machine_genericx86-64 ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
+     SRCREV_machine_edgerouter ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
+     SRCREV_machine_beaglebone ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
+     SRCREV_machine_mpc8315e-rdb ?= "df00877ef9387b38b9601c82db57de2a1b23ce53"
+
+     COMPATIBLE_MACHINE_genericx86 = "genericx86"
+     COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
+     COMPATIBLE_MACHINE_edgerouter = "edgerouter"
+     COMPATIBLE_MACHINE_beaglebone = "beaglebone"
+     COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
+
+     LINUX_VERSION_genericx86 = "4.4.3"
+     LINUX_VERSION_genericx86-64 = "4.4.3"
                 </literallayout>
-                This append file contains statements used to support the
-                eMenlow BSP.
+                This append file contains statements used to support
+                several BSPs that ship with the Yocto Project.
                 The file defines machines using the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
                 variable and uses the
@@ -602,25 +730,31 @@
                 The file also uses the optional
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink>
                 variable to ensure the build process uses the
-                <filename>standard/emenlow</filename> kernel branch.
-                The
+                appropriate kernel branch.
+            </para>
+
+            <para>
+                Although this particular example does not use it, the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
-                variable enables features specific to the kernel
-                (e.g. Intel GMA-500 DRM Driver in this case).
+                variable could be used to enable features specific to
+                the kernel.
                 The append file points to specific commits in the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
                 Git repository and the <filename>meta</filename> Git repository
                 branches to identify the exact kernel needed to build the
-                eMenlow BSP.
+                BSP.
             </para>
 
             <para>
-                One thing missing in this particular BSP, which you will typically need when
-                developing a BSP, is the kernel configuration file (<filename>.config</filename>) for your BSP.
-                When developing a BSP, you probably have a kernel configuration file or a set of kernel
-                configuration files that, when taken together, define the kernel configuration for your BSP.
-                You can accomplish this definition by putting the configurations in a file or a set of files
-                inside a directory located at the same level as your kernel's append file and having the same
+                One thing missing in this particular BSP, which you will
+                typically need when developing a BSP, is the kernel configuration
+                file (<filename>.config</filename>) for your BSP.
+                When developing a BSP, you probably have a kernel configuration
+                file or a set of kernel configuration files that, when taken
+                together, define the kernel configuration for your BSP.
+                You can accomplish this definition by putting the configurations
+                in a file or a set of files inside a directory located at the
+                same level as your kernel's append file and having the same
                 name as the kernel's main recipe file.
                 With all these conditions met, simply reference those files in the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
@@ -628,37 +762,42 @@
             </para>
 
             <para>
-                For example, suppose you had some configuration options in a file called
-                <filename>network_configs.cfg</filename>.
-                You can place that file inside a directory named <filename>linux-yocto</filename> and then add
-                a <filename>SRC_URI</filename> statement such as the following to the append file.
-                When the OpenEmbedded build system builds the kernel, the configuration options are
-                picked up and applied.
+                For example, suppose you had some configuration options
+                in a file called <filename>network_configs.cfg</filename>.
+                You can place that file inside a directory named
+                <filename>linux-yocto</filename> and then add
+                a <filename>SRC_URI</filename> statement such as the
+                following to the append file.
+                When the OpenEmbedded build system builds the kernel, the
+                configuration options are picked up and applied.
                 <literallayout class='monospaced'>
      SRC_URI += "file://network_configs.cfg"
                 </literallayout>
             </para>
 
             <para>
-                To group related configurations into multiple files, you perform a similar procedure.
-                Here is an example that groups separate configurations specifically for Ethernet and graphics
-                into their own files and adds the configurations
-                by using a <filename>SRC_URI</filename> statement like the following in your append file:
+                To group related configurations into multiple files, you
+                perform a similar procedure.
+                Here is an example that groups separate configurations
+                specifically for Ethernet and graphics into their own
+                files and adds the configurations by using a
+                <filename>SRC_URI</filename> statement like the following
+                in your append file:
                 <literallayout class='monospaced'>
      SRC_URI += "file://myconfig.cfg \
-            file://eth.cfg \
-            file://gfx.cfg"
+                 file://eth.cfg \
+                 file://gfx.cfg"
                 </literallayout>
             </para>
 
             <para>
-                The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
-                variable is in boilerplate form in the
-                previous example in order to make it easy to do that.
-                This variable must be in your layer or BitBake will not find the patches or
-                configurations even if you have them in your <filename>SRC_URI</filename>.
-                The <filename>FILESEXTRAPATHS</filename> variable enables the build process to
-                find those configuration files.
+                Another variable you can use in your kernel recipe append
+                file is the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                variable.
+                When you use this statement, you are extending the locations
+                used by the OpenEmbedded system to look for files and
+                patches as the recipe is processed.
             </para>
 
             <note>
@@ -711,7 +850,7 @@
                             "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding
                             and Creating Layers"</ulink> in the Yocto Project Development Manual.</para></listitem>
                         <listitem><para>The requirements in this section apply regardless of how you
-                            ultimately package a BSP.
+                            package a BSP.
                             You should consult the packaging and distribution guidelines for your
                             specific release process.
                             For an example of packaging and distribution requirements, see the
@@ -731,7 +870,7 @@
                 </para>
 
                 <para>
-                    Following are the requirements for a released BSP that conforms to the
+                    Following are the requirements for a released BSP that conform to the
                     Yocto Project:
                     <itemizedlist>
                         <listitem><para><emphasis>Layer Name:</emphasis>
@@ -777,15 +916,16 @@
                             You must specify which license to use since there is no
                             default license if one is not specified.
                             See the
-                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/COPYING.MIT'><filename>COPYING.MIT</filename></ulink>
-                            file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer
-                            as an example.</para></listitem>
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-raspberrypi/tree/COPYING.MIT'><filename>COPYING.MIT</filename></ulink>
+                            file for the Raspberry Pi BSP in the
+                            <filename>meta-raspberrypi</filename> BSP layer as an example.
+                            </para></listitem>
                         <listitem><para><emphasis>README File:</emphasis>
                             You must include a <filename>README</filename> file in the
                             <filename>meta-<replaceable>bsp_name</replaceable></filename> directory.
                             See the
-                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README'><filename>README</filename></ulink>
-                            file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-raspberrypi/tree/README'><filename>README</filename></ulink>
+                            file for the Raspberry Pi BSP in the <filename>meta-raspberrypi</filename> BSP layer
                             as an example.</para>
                             <para>At a minimum, the <filename>README</filename> file should
                             contain the following:
@@ -828,10 +968,7 @@
                             This file specifies exactly where you can find the sources used to
                             generate the binary images contained in the
                             <filename>binary</filename> directory, if present.
-                            See the
-                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README.sources'><filename>README.sources</filename></ulink>
-                            file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer
-                            as an example.</para></listitem>
+                            </para></listitem>
                         <listitem><para><emphasis>Layer Configuration File:</emphasis>
                             You must include a <filename>conf/layer.conf</filename> in the
                             <filename>meta-<replaceable>bsp_name</replaceable></filename> directory.
@@ -1175,13 +1312,14 @@
                     for that sub-command:
                     <literallayout class='monospaced'>
      $ yocto-bsp create
+     ERROR:root:Wrong number of arguments, exiting
 
      Usage:
 
       Create a new Yocto BSP
 
       usage: yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
-             [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
+            [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
 
       This command creates a Yocto BSP based on the specified parameters.
       The new BSP will be a new Yocto BSP layer contained by default within
@@ -1189,6 +1327,12 @@
       can be used to place the BSP layer in a directory with a different
       name and location.
 
+      The value of the 'karch' parameter determines the set of files that
+      will be generated for the BSP, along with the specific set of
+      'properties' that will be used to fill out the BSP-specific portions
+      of the BSP.  The possible values for the 'karch' parameter can be
+      listed via 'yocto-bsp list karch'.
+
       ...
                     </literallayout>
                 </para>
@@ -1203,7 +1347,7 @@
          yocto-bsp create - Create a new Yocto BSP
 
      SYNOPSIS
-         yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
+         yocto-bsp create &lt;bsp-name> &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
              [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
 
      DESCRIPTION
@@ -1213,12 +1357,6 @@
          'meta-bsp-name'.  The -o option can be used to place the BSP layer
          in a directory with a different name and location.
 
-         The value of the 'karch' parameter determines the set of files
-         that will be generated for the BSP, along with the specific set of
-         'properties' that will be used to fill out the BSP-specific
-         portions of the BSP.  The possible values for the 'karch' parameter
-         can be listed via 'yocto-bsp list karch'.
-
          ...
                     </literallayout>
                 </para>
@@ -1280,13 +1418,13 @@
                     <literallayout class='monospaced'>
      $ yocto-bsp list karch
      Architectures available:
-         qemu
-         mips64
          powerpc
          x86_64
-         arm
-         mips
          i386
+         arm
+         qemu
+         mips
+         mips64
                     </literallayout>
                 </para>
 
@@ -1320,35 +1458,34 @@
      $ yocto-bsp create myarm qemu
      Checking basic git connectivity...
      Done.
+
      Which qemu architecture would you like to use? [default: i386]
-         1) i386    (32-bit)
-         2) x86_64  (64-bit)
-         3) ARM     (32-bit)
-         4) PowerPC (32-bit)
-         5) MIPS    (32-bit)
-         6) MIPS64  (64-bit)
+	     1) i386    (32-bit)
+	     2) x86_64  (64-bit)
+	     3) ARM     (32-bit)
+	     4) PowerPC (32-bit)
+	     5) MIPS    (32-bit)
+	     6) MIPS64  (64-bit)
      3
-     Would you like to use the default (3.19) kernel? (y/n) [default: y] y
+     Would you like to use the default (4.1) kernel? (y/n) [default: y]
      Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y]
-     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.19.git...
+     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-4.1.git...
      Please choose a machine branch to base your new BSP branch on: [default: standard/base]
-         1) standard/arm-versatile-926ejs
-         2) standard/base
-         3) standard/beagleboard
-         4) standard/beaglebone
-         5) standard/ck
-         6) standard/common-pc
-         7) standard/crownbay
-         8) standard/edgerouter
-         9) standard/fsl-mpc8315e-rdb
-         10) standard/mti-malta32
-         11) standard/mti-malta64
-         12) standard/qemuarm64
-         13) standard/qemuppc
+	     1) standard/arm-versatile-926ejs
+	     2) standard/base
+	     3) standard/beagleboard
+	     4) standard/beaglebone
+	     5) standard/edgerouter
+	     6) standard/fsl-mpc8315e-rdb
+	     7) standard/mti-malta32
+	     8) standard/mti-malta64
+	     9) standard/qemuarm64
+	     10) standard/qemuppc
      1
      Would you like SMP support? (y/n) [default: y]
      Does your BSP have a touchscreen? (y/n) [default: n]
      Does your BSP have a keyboard? (y/n) [default: y]
+
      New qemu BSP created in meta-myarm
                     </literallayout>
                     Take a closer look at the example now:
@@ -1358,7 +1495,7 @@
                             In the example, we use the ARM architecture.
                             </para></listitem>
                         <listitem><para>The script then prompts you for the kernel.
-                            The default 3.19 kernel is acceptable.
+                            The default 4.4 kernel is acceptable.
                             So, the example accepts the default.
                             If you enter 'n', the script prompts you to further enter the kernel
                             you do want to use.</para></listitem>
@@ -1399,15 +1536,10 @@
                     <literallayout class='monospaced'>
      BBLAYERS = ? " \
         /usr/local/src/yocto/meta \
-        /usr/local/src/yocto/meta-yocto \
+        /usr/local/src/yocto/meta-poky \
         /usr/local/src/yocto/meta-yocto-bsp \
         /usr/local/src/yocto/meta-myarm \
         "
-
-     BBLAYERS_NON_REMOVABLE ?= " \
-        /usr/local/src/yocto/meta \
-        /usr/local/src/yocto/meta-yocto \
-        "
                     </literallayout>
                     Adding the layer to this file allows the build system to build the BSP and
                     the <filename>yocto-kernel</filename> tool to be able to find the layer and
@@ -1438,8 +1570,11 @@
                     <literallayout class='monospaced'>
      $ yocto-kernel --help
      Usage:
+
       Modify and list Yocto BSP kernel config items and patches.
+
       usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
+
       Current 'yocto-kernel' commands are:
         config list       List the modifiable set of bare kernel config options for a BSP
         config add        Add or modify bare kernel config options for a BSP
@@ -1454,7 +1589,11 @@
         feature describe  Describe a particular feature
         feature create    Create a new BSP-local feature
         feature destroy   Remove a BSP-local feature
+
       See 'yocto-kernel help COMMAND' for more information on a specific command.
+
+
+
      Options:
        --version    show program's version number and exit
        -h, --help   show this help message and exit

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

diff --git a/yocto-poky/documentation/dev-manual/dev-manual-common-tasks.xml b/yocto-poky/documentation/dev-manual/dev-manual-common-tasks.xml
index f0836e8..f926f1d 100644
--- a/yocto-poky/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/yocto-poky/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -72,7 +72,7 @@
                 <filename>meta</filename>,
                 <filename>meta-skeleton</filename>,
                 <filename>meta-selftest</filename>,
-                <filename>meta-yocto</filename>, and
+                <filename>meta-poky</filename>, and
                 <filename>meta-yocto-bsp</filename>.
                 Each of these folders represents a distinct layer.
             </para>
@@ -165,12 +165,12 @@
                                     directory to the
                                     <filename>BBPATH</filename>.
                                     On the other hand, distro layers, such as
-                                    <filename>meta-yocto</filename>, can choose
+                                    <filename>meta-poky</filename>, can choose
                                     to enforce their own precedence over
                                     <filename>BBPATH</filename>.
                                     For an example of that syntax, see the
                                     <filename>layer.conf</filename> file for
-                                    the <filename>meta-yocto</filename> layer.
+                                    the <filename>meta-poky</filename> layer.
                                 </note></para></listitem>
                             <listitem><para>The recipes for the layers are
                                 appended to
@@ -336,11 +336,12 @@
      DEPENDS_append_one = " foo"
      DEPENDS_prepend_one = "foo "
                             </literallayout>
-                            As an actual example, here's a line from the recipe for
-                            the OProfile profiler, which lists an extra build-time
-                            dependency when building specifically for 64-bit PowerPC:
+                            As an actual example, here's a line from the recipe
+                            for gnutls, which adds dependencies on
+                            "argp-standalone" when building with the musl C
+                            library:
                             <literallayout class='monospaced'>
-     DEPENDS_append_powerpc64 = " libpfm4"
+     DEPENDS_append_libc-musl = " argp-standalone"
                             </literallayout>
                             <note>
                                 Avoiding "+=" and "=+" and using
@@ -444,7 +445,7 @@
 
      BBLAYERS ?= " \
        $HOME/poky/meta \
-       $HOME/poky/meta-yocto \
+       $HOME/poky/meta-poky \
        $HOME/poky/meta-yocto-bsp \
        $HOME/poky/meta-mylayer \
        "
@@ -550,8 +551,8 @@
             <para>
                 Following is the append file, which is named
                 <filename>formfactor_0.0.bbappend</filename> and is from the
-                Emenlow BSP Layer named
-                <filename>meta-intel/meta-emenlow</filename>.
+                Raspberry Pi BSP Layer named
+                <filename>meta-raspberrypi</filename>.
                 The file is in <filename>recipes-bsp/formfactor</filename>:
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@@ -577,7 +578,7 @@
                 which resolves to a directory named
                 <filename>formfactor</filename> in the same directory
                 in which the append file resides (i.e.
-                <filename>meta-intel/meta-emenlow/recipes-bsp/formfactor/formfactor</filename>.
+                <filename>meta-raspberrypi/recipes-bsp/formfactor/formfactor</filename>.
                 This implies that you must have the supporting directory
                 structure set up that will contain any files or patches you
                 will be including from the layer.
@@ -870,7 +871,7 @@
                 <literallayout class='monospaced'>
      BBLAYERS = ?" \
         /usr/local/src/yocto/meta \
-        /usr/local/src/yocto/meta-yocto \
+        /usr/local/src/yocto/meta-poky \
         /usr/local/src/yocto/meta-yocto-bsp \
         /usr/local/src/yocto/meta-mylayer \
         "
@@ -3495,14 +3496,7 @@
             </para>
 
             <para>
-                This section overviews the Multilib process only.
-                For more details on how to implement Multilib, see the
-                <ulink url='&YOCTO_WIKI_URL;/wiki/Multilib'>Multilib</ulink> wiki
-                page.
-            </para>
-
-            <para>
-                Aside from this wiki page, several examples exist in the
+                Several examples exist in the
                 <filename>meta-skeleton</filename> layer found in the
                <link linkend='source-directory'>Source Directory</link>:
                 <itemizedlist>
@@ -3603,8 +3597,39 @@
                 <title>Additional Implementation Details</title>
 
                 <para>
-                    Different packaging systems have different levels of native Multilib
-                    support.
+                    Generic implementation details as well as details that are
+                    specific to package management systems exist.
+                    Following are implementation details that exist regardless
+                    of the package management system:
+                    <itemizedlist>
+                        <listitem><para>The typical convention used for the
+                            class extension code as used by
+                            Multilib assumes that all package names specified
+                            in
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
+                            that contain <filename>${PN}</filename> have
+                            <filename>${PN}</filename> at the start of the name.
+                            When that convention is not followed and
+                            <filename>${PN}</filename> appears at
+                            the middle or the end of a name, problems occur.
+                            </para></listitem>
+                        <listitem><para>The
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_VENDOR'><filename>TARGET_VENDOR</filename></ulink>
+                            value under Multilib will be extended to
+                            "-<replaceable>vendor</replaceable>ml<replaceable>multilib</replaceable>"
+                            (e.g. "-pokymllib32" for a "lib32" Multilib with
+                            Poky).
+                            The reason for this slightly unwieldy contraction
+                            is that any "-" characters in the vendor
+                            string presently break Autoconf's
+                            <filename>config.sub</filename>, and
+                            other separators are problematic for different
+                            reasons.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+'
+                <para>
                     For the RPM Package Management System, the following implementation details
                     exist:
                     <itemizedlist>
@@ -3701,6 +3726,46 @@
         </section>
     </section>
 
+    <section id='dev-optionally-using-an-external-toolchain'>
+        <title>Optionally Using an External Toolchain</title>
+
+        <para>
+            You might want to use an external toolchain as part of your
+            development.
+            If this is the case, the fundamental steps you need to accomplish
+            are as follows:
+            <itemizedlist>
+                <listitem><para>
+                    Understand where the installed toolchain resides.
+                    For cases where you need to build the external toolchain,
+                    you would need to take separate steps to build and install
+                    the toolchain.
+                    </para></listitem>
+                <listitem><para>
+                    Make sure you add the layer that contains the toolchain to
+                    your <filename>bblayers.conf</filename> file through the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
+                    variable.
+                    </para></listitem>
+                <listitem><para>
+                    Set the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTERNAL_TOOLCHAIN'><filename>EXTERNAL_TOOLCHAIN</filename></ulink>
+                    variable in your <filename>local.conf</filename> file
+                    to the location in which you installed the toolchain.
+                    </para></listitem>
+            </itemizedlist>
+            A good example of an external toolchain used with the Yocto Project
+            is <trademark class='registered'>Mentor Graphics</trademark>
+            Sourcery G++ Toolchain.
+            You can see information on how to use that particular layer in the
+            <filename>README</filename> file at
+            <ulink url='http://github.com/MentorEmbedded/meta-sourcery/'></ulink>.
+            You can find further information by reading about the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-TCMODE'><filename>TCMODE</filename></ulink>
+            variable in the Yocto Project Reference Manual's variable glossary.
+        </para>
+    </section>
+
     <section id='creating-partitioned-images'>
         <title>Creating Partitioned Images</title>
 
@@ -3779,8 +3844,8 @@
                         standalone utility that initially provides
                         easier-to-use and more flexible replacements for a
                         couple bits of existing functionality in OE Core's
-                        <filename>boot-directdisk.bbclass</filename> and
-                        <filename>mkefidisk.sh</filename> scripts.
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-image-live'><filename>image-live</filename></ulink>
+                        class and <filename>mkefidisk.sh</filename> script.
                         The difference between
                         <filename>wic</filename> and those examples is
                         that with <filename>wic</filename> the
@@ -3823,7 +3888,8 @@
                         in the form generated by the build system.
                         </para></listitem>
                     <listitem><para>
-                        You must build several native tools:
+                        You must build several native tools, which are tools
+                        built to run on the build system:
                         <literallayout class='monospaced'>
      $ bitbake parted-native dosfstools-native mtools-native
                         </literallayout>
@@ -4102,8 +4168,8 @@
                 </para>
 
                 <para>
-                    The output specifies the exact created as well as where
-                    it was created.
+                    The output specifies the exact image created as well as
+                    where it was created.
                     The output also names the artifacts used and the exact
                     <filename>.wks</filename> script that was used to generate
                     the image.
@@ -4491,11 +4557,18 @@
                 <title>Command: part or partition</title>
 
                 <para>
-                This command creates a partition on the system and uses the
-                following syntax:
+                Either of these commands create a partition on the system
+                and uses the following syntax:
                     <literallayout class='monospaced'>
-     part <replaceable>mntpoint</replaceable>
+     part [<replaceable>mntpoint</replaceable>]
+     partition [<replaceable>mntpoint</replaceable>]
                     </literallayout>
+                    If you do not provide
+                    <replaceable>mntpoint</replaceable>, wic creates a partition
+                    but does not mount it.
+                </para>
+
+                <para>
                     The <filename><replaceable>mntpoint</replaceable></filename>
                     is where the
                     partition will be mounted and must be of one of the
@@ -4503,16 +4576,36 @@
                     <itemizedlist>
                         <listitem><para><filename>/<replaceable>path</replaceable></filename>:
                             For example, <filename>/</filename>,
-                            <filename>/usr</filename>, and
+                            <filename>/usr</filename>, or
                             <filename>/home</filename></para></listitem>
                         <listitem><para><filename>swap</filename>:
-                            The partition will be used as swap space.
+                            The created partition is used as swap space.
                             </para></listitem>
                     </itemizedlist>
                 </para>
 
                 <para>
-                    Following are the supported options:
+                    Specifying a <replaceable>mntpoint</replaceable> causes
+                    the partition to automatically be mounted.
+                    Wic achieves this by adding entries to the filesystem
+                    table (fstab) during image generation.
+                    In order for wic to generate a valid fstab, you must
+                    also provide one of the <filename>--ondrive</filename>,
+                    <filename>--ondisk</filename>, or
+                    <filename>--use-uuid</filename> partition options as part
+                    of the command.
+                    Here is an example using "/" as the mountpoint.
+                    The command uses "--ondisk" to force the partition onto
+                    the <filename>sdb</filename> disk:
+                    <literallayout class='monospaced'>
+     part / --source rootfs --ondisk sdb --fstype=ext3 --label platform --align 1024
+                    </literallayout>
+                </para>
+
+                <para>
+                    Here is a list that describes other supported options you
+                    can use with the <filename>part</filename> and
+                    <filename>partition</filename> commands:
                     <itemizedlist>
                         <listitem><para><emphasis><filename>--size</filename>:</emphasis>
                             The minimum partition size in MBytes.
@@ -4684,6 +4777,14 @@
                             <filename>APPEND</filename> or
                             <filename>grub</filename> kernel command line.
                             </para></listitem>
+                        <listitem><para><emphasis><filename>--configfile</filename>:</emphasis>
+                            Specifies a user-defined configuration file for
+                            the bootloader.
+                            You can provide a full pathname for the file or
+                            a file that exists in the
+                            <filename>canned-wks</filename> folder.
+                            This option overrides all other bootloader options.
+                            </para></listitem>
                     </itemizedlist>
                 </para>
             </section>
@@ -5013,7 +5114,7 @@
                         This configuration file will be your baseline.
                         </para></listitem>
                     <listitem><para>Separately run the
-                        <filename>do_configme</filename> and
+                        <filename>do_kernel_configme</filename> and
                         <filename>do_kernel_configcheck</filename> tasks.
                         </para></listitem>
                     <listitem><para>Take the resulting list of files from the
@@ -5041,7 +5142,7 @@
                     <listitem><para>
                         After you have worked through the output of the kernel
                         configuration audit, you can re-run the
-                        <filename>do_configme</filename> and
+                        <filename>do_kernel_configme</filename> and
                         <filename>do_kernel_configcheck</filename> tasks to
                         see the results of your changes.
                         If you have more issues, you can deal with them as
@@ -5057,6 +5158,112 @@
                 Yocto kernel.
             </para>
         </section>
+
+        <section id='determining-hardware-and-non-hardware-features-for-the-kernel-configuration-audit-phase'>
+            <title>Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase</title>
+
+            <para>
+                This section describes part of the kernel configuration audit
+                phase that most developers can ignore.
+                During this part of the audit phase, the contents of the final
+                <filename>.config</filename> file are compared against the
+                fragments specified by the system.
+                These fragments can be system fragments, distro fragments,
+                or user specified configuration elements.
+                Regardless of their origin, the OpenEmbedded build system
+                warns the user if a specific option is not included in the
+                final kernel configuration.
+            </para>
+
+            <para>
+                In order to not overwhelm the user with configuration warnings,
+                by default the system only reports on missing "hardware"
+                options because a missing hardware option could mean a boot
+                failure or that important hardware is not available.
+            </para>
+
+            <para>
+                To determine whether or not a given option is "hardware" or
+                "non-hardware", the kernel Metadata contains files that
+                classify individual or groups of options as either hardware
+                or non-hardware.
+                To better show this, consider a situation where the
+                Yocto Project kernel cache contains the following files:
+                <literallayout class='monospaced'>
+     kernel-cache/features/drm-psb/hardware.cfg
+     kernel-cache/features/kgdb/hardware.cfg
+     kernel-cache/ktypes/base/hardware.cfg
+     kernel-cache/bsp/mti-malta32/hardware.cfg
+     kernel-cache/bsp/fsl-mpc8315e-rdb/hardware.cfg
+     kernel-cache/bsp/qemu-ppc32/hardware.cfg
+     kernel-cache/bsp/qemuarma9/hardware.cfg
+     kernel-cache/bsp/mti-malta64/hardware.cfg
+     kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg
+     kernel-cache/bsp/common-pc/hardware.cfg
+     kernel-cache/bsp/common-pc-64/hardware.cfg
+     kernel-cache/features/rfkill/non-hardware.cfg
+     kernel-cache/ktypes/base/non-hardware.cfg
+     kernel-cache/features/aufs/non-hardware.kcf
+     kernel-cache/features/ocf/non-hardware.kcf
+     kernel-cache/ktypes/base/non-hardware.kcf
+     kernel-cache/ktypes/base/hardware.kcf
+     kernel-cache/bsp/qemu-ppc32/hardware.kcf
+                </literallayout>
+                The following list provides explanations for the various
+                files:
+                <itemizedlist>
+                    <listitem><para><filename>hardware.kcf</filename>:
+                        Specifies a list of kernel Kconfig files that contain
+                        hardware options only.
+                        </para></listitem>
+                    <listitem><para><filename>non-hardware.kcf</filename>:
+                        Specifies a list of kernel Kconfig files that contain
+                        non-hardware options only.
+                        </para></listitem>
+                    <listitem><para><filename>hardware.cfg</filename>:
+                        Specifies a list of kernel
+                        <filename>CONFIG_</filename> options that are hardware,
+                        regardless of whether or not they are within a Kconfig
+                        file specified by a hardware or non-hardware
+                        Kconfig file (i.e. <filename>hardware.kcf</filename> or
+                        <filename>non-hardware.kcf</filename>).
+                        </para></listitem>
+                    <listitem><para><filename>non-hardware.cfg</filename>:
+                        Specifies a list of kernel
+                        <filename>CONFIG_</filename> options that are
+                        not hardware, regardless of whether or not they are
+                        within a Kconfig file specified by a hardware or
+                        non-hardware Kconfig file (i.e.
+                        <filename>hardware.kcf</filename> or
+                        <filename>non-hardware.kcf</filename>).
+                        </para></listitem>
+                </itemizedlist>
+                Here is a specific example using the
+                <filename>kernel-cache/bsp/mti-malta32/hardware.cfg</filename>:
+                <literallayout class='monospaced'>
+     CONFIG_SERIAL_8250
+     CONFIG_SERIAL_8250_CONSOLE
+     CONFIG_SERIAL_8250_NR_UARTS
+     CONFIG_SERIAL_8250_PCI
+     CONFIG_SERIAL_CORE
+     CONFIG_SERIAL_CORE_CONSOLE
+     CONFIG_VGA_ARB
+                </literallayout>
+                The kernel configuration audit automatically detects these
+                files (hence the names must be exactly the ones discussed here),
+                and uses them as inputs when generating warnings about the
+                final <filename>.config</filename> file.
+            </para>
+
+            <para>
+                A user-specified kernel Metadata repository, or recipe space
+                feature, can use these same files to classify options that are
+                found within its <filename>.cfg</filename> files as hardware
+                or non-hardware, to prevent the OpenEmbedded build system from
+                producing an error or warning when an option is not in the
+                final <filename>.config</filename> file.
+            </para>
+        </section>
     </section>
 
     <section id="patching-the-kernel">
@@ -5305,14 +5512,14 @@
                         <filename>poky/build/conf</filename> directory needs to have the path to your local
                         <filename>meta-mylayer</filename> layer.
                         By default, the <filename>BBLAYERS</filename> variable contains paths to
-                        <filename>meta</filename>, <filename>meta-yocto</filename>, and
+                        <filename>meta</filename>, <filename>meta-poky</filename>, and
                         <filename>meta-yocto-bsp</filename> in the
                         <filename>poky</filename> Git repository.
                         Add the path to your <filename>meta-mylayer</filename> location:
                         <literallayout class='monospaced'>
      BBLAYERS ?= " \
        $HOME/poky/meta \
-       $HOME/poky/meta-yocto \
+       $HOME/poky/meta-poky \
        $HOME/poky/meta-yocto-bsp \
        $HOME/poky/meta-mylayer \
        "
@@ -5416,10 +5623,6 @@
                     "<ulink url='http://elinux.org/images/6/6f/Security-issues.pdf'>Security Issues for Embedded Devices</ulink>"</emphasis>
                     by Jake Edge
                     </para></listitem>
-                <listitem><para><emphasis>
-                    "<ulink url='https://www.nccgroup.com/media/18475/exploiting_security_gateways_via_their_web_interfaces.pdf'>They ought to know better: Exploiting Security Gateways via their Web Interfaces</ulink>"</emphasis>
-                    by Ben Williams
-                    </para></listitem>
             </itemizedlist>
         </para>
 
@@ -5785,7 +5988,7 @@
             By default, <filename>TEMPLATECONF</filename> is set as
             follows in the <filename>poky</filename> repository:
             <literallayout class='monospaced'>
-     TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}
+     TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
             </literallayout>
             This is the directory used by the build system to find templates
             from which to build some key configuration files.
@@ -5837,7 +6040,7 @@
         <para>
             Aside from the <filename>*.sample</filename> configuration files,
             the <filename>conf-notes.txt</filename> also resides in the
-            default <filename>meta-yocto/conf</filename> directory.
+            default <filename>meta-poky/conf</filename> directory.
             The scripts that set up the build environment
             (i.e.
             <ulink url="&YOCTO_DOCS_REF_URL;#structure-core-script"><filename>&OE_INIT_FILE;</filename></ulink>
@@ -5860,7 +6063,6 @@
          core-image-minimal
          core-image-sato
          meta-toolchain
-         adt-installer
          meta-ide-support
             </literallayout>
         </para>
@@ -7544,13 +7746,16 @@
                             Consequently, you usually need to add a
                             cross-compilation function to the package.
                             </para>
+
                             <para>Many packages based on Automake compile and
                             run the test suite by using a single command
                             such as <filename>make check</filename>.
-                            However, the native <filename>make check</filename>
+                            However, the host <filename>make check</filename>
                             builds and runs on the same computer, while
                             cross-compiling requires that the package is built
-                            on the host but executed on the target.
+                            on the host but executed for the target
+                            architecture (though often, as in the case for
+                            ptest, the execution occurs on the host).
                             The built version of Automake that ships with the
                             Yocto Project includes a patch that separates
                             building and execution.
@@ -7999,21 +8204,22 @@
             This line pulls in the listed include file that contains
             numerous lines of exactly that form:
             <literallayout class='monospaced'>
+     #SRCREV_pn-opkg-native ?= "${AUTOREV}"
+     #SRCREV_pn-opkg-sdk ?= "${AUTOREV}"
+     #SRCREV_pn-opkg ?= "${AUTOREV}"
+     #SRCREV_pn-opkg-utils-native ?= "${AUTOREV}"
+     #SRCREV_pn-opkg-utils ?= "${AUTOREV}"
      SRCREV_pn-gconf-dbus ?= "${AUTOREV}"
      SRCREV_pn-matchbox-common ?= "${AUTOREV}"
      SRCREV_pn-matchbox-config-gtk ?= "${AUTOREV}"
      SRCREV_pn-matchbox-desktop ?= "${AUTOREV}"
      SRCREV_pn-matchbox-keyboard ?= "${AUTOREV}"
-     SRCREV_pn-matchbox-panel ?= "${AUTOREV}"
      SRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}"
      SRCREV_pn-matchbox-themes-extra ?= "${AUTOREV}"
      SRCREV_pn-matchbox-terminal ?= "${AUTOREV}"
      SRCREV_pn-matchbox-wm ?= "${AUTOREV}"
-     SRCREV_pn-matchbox-wm-2 ?= "${AUTOREV}"
      SRCREV_pn-settings-daemon ?= "${AUTOREV}"
      SRCREV_pn-screenshot ?= "${AUTOREV}"
-     SRCREV_pn-libfakekey ?= "${AUTOREV}"
-     SRCREV_pn-oprofileui ?= "${AUTOREV}"
           .
           .
           .
@@ -8134,7 +8340,8 @@
                         specific to or dependent on the target
                         architecture:</emphasis>
                         You can work around these attempts by using native
-                        tools to accomplish the same tasks, or
+                        tools, which run on the host system,
+                        to accomplish the same tasks, or
                         by alternatively running the processes under QEMU,
                         which has the <filename>qemu_run_binary</filename>
                         function.
@@ -9080,11 +9287,8 @@
                 Before you can initiate a remote debugging session, you need
                 to be sure you have set up the cross-development environment,
                 toolchain, and sysroot.
-                The "<ulink url='&YOCTO_DOCS_ADT_URL;#adt-prepare'>Preparing for Application Development</ulink>"
-                chapter of the Yocto Project Application Developer's Guide
+                The <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>
                 describes this process.
-                Be sure you have read that chapter and have set up
-                your environment.
             </para>
         </section>
 
@@ -9193,9 +9397,8 @@
                     location is at <filename>/opt/poky/&DISTRO;</filename>
                     and begins with the string "environment-setup".
                     For more information, see the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</ulink>"
-                    section in the Yocto Project Application Developer's
-                    Guide.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's
+                    Guide</ulink>.
                 </para>
 
                 <para>
@@ -9533,6 +9736,7 @@
         </section>
     </section>
 
+<!--
     <section id="platdev-oprofile">
         <title>Profiling with OProfile</title>
 
@@ -9594,14 +9798,14 @@
 
             <para>
                 <literallayout class='monospaced'>
-     # opcontrol --reset
-     # opcontrol --start --separate=lib --no-vmlinux -c 5
+     # opcontrol &dash;&dash;reset
+     # opcontrol &dash;&dash;start &dash;&dash;separate=lib &dash;&dash;no-vmlinux -c 5
               .
               .
         [do whatever is being profiled]
               .
               .
-     # opcontrol --stop
+     # opcontrol &dash;&dash;stop
      $ opreport -cl
                 </literallayout>
             </para>
@@ -9614,7 +9818,7 @@
                 five levels deep.
                 <note>
                     To profile the kernel, you would specify the
-                    <filename>--vmlinux=/path/to/vmlinux</filename> option.
+                    <filename>&dash;&dash;vmlinux=/path/to/vmlinux</filename> option.
                     The <filename>vmlinux</filename> file is usually in the source directory in the
                     <filename>/boot/</filename> directory and must match the running kernel.
                 </note>
@@ -9677,7 +9881,7 @@
                     With this connection, you just need to run "oprofile-server" on the device.
                     By default, OProfile listens on port 4224.
                     <note>
-                        You can change the port using the <filename>--port</filename> command-line
+                        You can change the port using the <filename>&dash;&dash;port</filename> command-line
                         option.
                     </note>
                 </para>
@@ -9767,14 +9971,14 @@
                     If network access to the target is unavailable, you can generate
                     an archive for processing in <filename>oprofile-viewer</filename> as follows:
                     <literallayout class='monospaced'>
-     # opcontrol --reset
-     # opcontrol --start --separate=lib --no-vmlinux -c 5
+     # opcontrol &dash;&dash;reset
+     # opcontrol &dash;&dash;start &dash;&dash;separate=lib &dash;&dash;no-vmlinux -c 5
             .
             .
      [do whatever is being profiled]
             .
             .
-     # opcontrol --stop
+     # opcontrol &dash;&dash;stop
      # oparchive -o my_archive
                     </literallayout>
                 </para>
@@ -9789,6 +9993,7 @@
             </section>
         </section>
     </section>
+-->
 
     <section id='maintaining-open-source-license-compliance-during-your-products-lifecycle'>
         <title>Maintaining Open Source License Compliance During Your Product's Lifecycle</title>
@@ -9937,10 +10142,33 @@
                 <literallayout class='monospaced'>
      COPY_LIC_MANIFEST = "1"
      COPY_LIC_DIRS = "1"
+     LICENSE_CREATE_PACKAGE = "1"
                 </literallayout>
                 Adding these statements to the configuration file ensures
                 that the licenses collected during package generation
                 are included on your image.
+                <note>
+                    <para>Setting all three variables to "1" results in the
+                    image having two copies of the same license file.
+                    One copy resides in
+                    <filename>/usr/share/common-licenses</filename> and
+                    the other resides in
+                    <filename>/usr/share/license</filename>.</para>
+
+                    <para>The reason for this behavior is because
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-COPY_LIC_DIRS'><filename>COPY_LIC_DIRS</filename></ulink>
+                    and
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-COPY_LIC_MANIFEST'><filename>COPY_LIC_MANIFEST</filename></ulink>
+                    add a copy of the license when the image is built but do not
+                    offer a path for adding licenses for newly installed packages
+                    to an image.
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE_CREATE_PACKAGE'><filename>LICENSE_CREATE_PACKAGE</filename></ulink>
+                    adds a separate package and an upgrade path for adding
+                    licenses to an image.</para>
+                </note>
+            </para>
+
+            <para>
                 As the source archiver has already archived the original
                 unmodified source that contains the license files,
                 you would have already met the requirements for inclusion
@@ -9979,8 +10207,8 @@
                 during your build.
                 Here is an example:
                 <literallayout class='monospaced'>
-     # We built using the &DISTRO_NAME; branch of the poky repo
-     $ git clone -b &DISTRO_NAME; git://git.yoctoproject.org/poky
+     # We built using the &DISTRO_NAME_NO_CAP; branch of the poky repo
+     $ git clone -b &DISTRO_NAME_NO_CAP; git://git.yoctoproject.org/poky
      $ cd poky
      # We built using the release_branch for our layers
      $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer
@@ -9990,7 +10218,7 @@
                 </literallayout>
                 One thing a development organization might want to consider
                 for end-user convenience is to modify
-                <filename>meta-yocto/conf/bblayers.conf.sample</filename> to
+                <filename>meta-poky/conf/bblayers.conf.sample</filename> to
                 ensure that when the end user utilizes the released build
                 system to build an image, the development organization's
                 layers are included in the <filename>bblayers.conf</filename>
@@ -10005,7 +10233,7 @@
 
      BBLAYERS ?= " \
        ##OEROOT##/meta \
-       ##OEROOT##/meta-yocto \
+       ##OEROOT##/meta-poky \
        ##OEROOT##/meta-yocto-bsp \
        ##OEROOT##/meta-mylayer \
        "

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

diff --git a/yocto-poky/documentation/dev-manual/dev-manual-intro.xml b/yocto-poky/documentation/dev-manual/dev-manual-intro.xml
index e350882..caa066e 100644
--- a/yocto-poky/documentation/dev-manual/dev-manual-intro.xml
+++ b/yocto-poky/documentation/dev-manual/dev-manual-intro.xml
@@ -29,8 +29,8 @@
         <para>
             The Yocto Project Development Manual does, however, provide
             guidance and examples on how to change the kernel source code,
-            reconfigure the kernel, and develop an application using the
-            popular <trademark class='trade'>Eclipse</trademark> IDE.
+            reconfigure the kernel, and develop an application using
+            <filename>devtool</filename>.
         </para>
 
         <note>
@@ -86,17 +86,21 @@
             <itemizedlist>
                 <listitem><para><emphasis>Step-by-step instructions when those instructions exist in other Yocto
                     Project documentation:</emphasis>
-                    For example, the Yocto Project Application Developer's Guide contains detailed
-                    instructions on how to run the
-                    <ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>ADT Installer</ulink>,
-                    which is used to set up a cross-development environment.</para></listitem>
+                    For example, the
+                    <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>
+                    manual contains detailed instructions on how to install an
+                    SDK, which is used to develop applications for target
+                    hardware.
+                    </para></listitem>
                 <listitem><para><emphasis>Reference material:</emphasis>
                     This type of material resides in an appropriate reference manual.
                     For example, system variables are documented in the
-                    <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>.</para></listitem>
+                    <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>.
+                    </para></listitem>
                 <listitem><para><emphasis>Detailed public information that is not specific to the Yocto Project:</emphasis>
                     For example, exhaustive information on how to use Git is covered better through the
-                    Internet than in this manual.</para></listitem>
+                    Internet than in this manual.
+                    </para></listitem>
             </itemizedlist>
         </para>
     </section>
@@ -126,10 +130,12 @@
                     The build system is sometimes referred to as "Poky".
                     </para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>:</emphasis>
-                    This guide provides information that lets you get going with the Application
-                    Development Toolkit (ADT) and stand-alone cross-development toolchains to
-                    develop projects using the Yocto Project.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>:</emphasis>
+                    This guide provides information that lets you get going
+                    with the standard or extensible SDK.
+                    An SDK, with its cross-development toolchains, allows you
+                    to develop projects inside or outside of the Yocto Project
+                    environment.
                     </para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
@@ -169,11 +175,6 @@
                     release of the Yocto Project.
                     </para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>:</emphasis>
-                    A graphical user interface for BitBake.
-                    Hob's primary goal is to enable a user to perform common tasks more easily.
-                    </para></listitem>
-                <listitem><para><emphasis>
                     <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/toaster'>Toaster</ulink>:</emphasis>
                     An Application Programming Interface (API) and web-based
                     interface to the OpenEmbedded build system, which uses

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

diff --git a/yocto-poky/documentation/dev-manual/dev-manual-model.xml b/yocto-poky/documentation/dev-manual/dev-manual-model.xml
index 6e42c7b..ff44a3f 100644
--- a/yocto-poky/documentation/dev-manual/dev-manual-model.xml
+++ b/yocto-poky/documentation/dev-manual/dev-manual-model.xml
@@ -27,11 +27,10 @@
              that you intend to run on target hardware.
              For information on how to set up your host development system for
              user-space application development, see the
-             <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
+             <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
              For a simple example of user-space application development using
              the <trademark class='trade'>Eclipse</trademark> IDE, see the
-             "<link linkend='application-development-workflow'>Application
-             Development Workflow</link>" section.
+             "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-developing-applications-using-eclipse'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></ulink>" section.
              </para></listitem>
          <listitem><para><emphasis>Temporary Source Code Modification:</emphasis>
              Direct modification of temporary source code is a convenient
@@ -48,14 +47,10 @@
              Toaster provides an efficient interface to the OpenEmbedded build
              that allows you to start builds and examine build statistics.
              </para></listitem>
-         <listitem><para><emphasis>Image Development using Hob:</emphasis>
-             You can use the <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>
-             to build custom operating system images within the build
-             environment.
-             Hob provides an efficient interface to the OpenEmbedded build system.
-             </para></listitem>
          <listitem><para><emphasis>Using a Development Shell:</emphasis>
-             You can use a <filename>devshell</filename> to efficiently debug
+             You can use a
+             <link linkend='platdev-appdev-devshell'><filename>devshell</filename></link>
+             to efficiently debug
              commands or simply edit packages.
              Working inside a development shell is a quick way to set up the
              OpenEmbedded build environment to work on parts of a project.
@@ -154,38 +149,60 @@
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
                     section in the Yocto Project Board Support (BSP) Developer's Guide.
                     </para>
+
                     <para>
-                    Another example that illustrates a layer is an application.
-                    Suppose you are creating an application that has library or other dependencies in
-                    order for it to compile and run.
-                    The layer, in this case, would be where all the recipes that define those dependencies
-                    are kept.
-                    The key point for a layer is that it is an isolated area that contains
-                    all the relevant information for the project that the OpenEmbedded build
-                    system knows about.
-                    For more information on layers, see the
-                    "<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>"
-                    section.
-                    For more information on BSP layers, see the
-                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" section in the
-                    Yocto Project Board Support Package (BSP) Developer's Guide.</para>
-                    <note>Five BSPs exist that are part of the
-                    Yocto Project release: <filename>genericx86</filename>, <filename>genericx86-64</filename>,
-                    <filename>beaglebone</filename> (ARM),
-                    <filename>mpc8315e</filename> (PowerPC),
-                    and <filename>edgerouter</filename> (MIPS).
-                    The recipes and configurations for these five BSPs are located and dispersed
-                    within the <link linkend='source-directory'>Source Directory</link>.
-                    On the other hand, the <filename>meta-intel</filename> layer
-                    contains BSP layers for many supported BSPs (e.g.
-                    Crystal Forest, Emenlow, Fish River Island 2, Haswell,
-                    Jasper Forest, and so forth).
-                    Aside from the BSPs in the <filename>meta-intel</filename>
-                    layer, the
-                    <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
-                    contain additional BSP layers such as
-                    <filename>meta-minnow</filename> and
-                    <filename>meta-raspberrypi</filename>.</note>
+                        Another example that illustrates a layer
+                        is an application.
+                        Suppose you are creating an application that has
+                        library or other dependencies in order for it to
+                        compile and run.
+                        The layer, in this case, would be where all the
+                        recipes that define those dependencies are kept.
+                        The key point for a layer is that it is an isolated
+                        area that contains all the relevant information for
+                        the project that the OpenEmbedded build system knows
+                        about.
+                        For more information on layers, see the
+                        "<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>"
+                        section.
+                        For more information on BSP layers, see the
+                        "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
+                        section in the Yocto Project Board Support Package (BSP)
+                        Developer's Guide.
+                        <note>
+                            <para>
+                                Five BSPs exist that are part of the Yocto Project release:
+                                <filename>beaglebone</filename> (ARM),
+                                <filename>mpc8315e</filename> (PowerPC),
+                                and <filename>edgerouter</filename> (MIPS).
+                                The recipes and configurations for these five BSPs
+                                are located and dispersed within the
+                                <link linkend='source-directory'>Source Directory</link>.
+                            </para>
+
+                            <para>
+                                Three core Intel BSPs exist as part of the Yocto
+                                Project release in the
+                                <filename>meta-intel</filename> layer:
+                                <itemizedlist>
+                                    <listitem><para><filename>intel-core2-32</filename>,
+                                        which is a BSP optimized for the Core2 family of CPUs
+                                        as well as all CPUs prior to the Silvermont core.
+                                        </para></listitem>
+                                    <listitem><para><filename>intel-corei7-64</filename>,
+                                        which is a BSP optimized for Nehalem and later
+                                        Core and Xeon CPUs as well as Silvermont and later
+                                        Atom CPUs, such as the Baytrail SoCs.
+                                        </para></listitem>
+                                    <listitem><para><filename>intel-quark</filename>,
+                                        which is a BSP optimized for the Intel Galileo
+                                        gen1 &amp; gen2 development boards.
+                                        </para></listitem>
+                                </itemizedlist>
+                            </para>
+                        </note>
+                    </para>
+
                     <para>When you set up a layer for a new BSP, you should follow a standard layout.
                     This layout is described in the
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
@@ -296,18 +313,6 @@
                 the Yocto Project:
                 <itemizedlist>
                     <listitem><para><emphasis>
-                        <filename>linux-yocto-3.8</filename></emphasis> - The
-                        stable Yocto Project kernel to use with the Yocto
-                        Project Release 1.4. This kernel is based on the
-                        Linux 3.8 released kernel.
-                        </para></listitem>
-                    <listitem><para><emphasis>
-                        <filename>linux-yocto-3.10</filename></emphasis> - An
-                        additional, unsupported Yocto Project kernel used with
-                        the Yocto Project Release 1.5.
-                        This kernel is based on the Linux 3.10 released kernel.
-                        </para></listitem>
-                    <listitem><para><emphasis>
                         <filename>linux-yocto-3.14</filename></emphasis> - The
                         stable Yocto Project kernel to use with the Yocto
                         Project Releases 1.6 and 1.7.
@@ -326,11 +331,35 @@
                         This kernel is based on the Linux 3.19 released kernel.
                         </para></listitem>
                     <listitem><para><emphasis>
+                        <filename>linux-yocto-4.1</filename></emphasis> - The
+                        stable Yocto Project kernel to use with the Yocto
+                        Project Release 2.0.
+                        This kernel is based on the Linux 4.1 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-4.4</filename></emphasis> - The
+                        stable Yocto Project kernel to use with the Yocto
+                        Project Release 2.1.
+                        This kernel is based on the Linux 4.4 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
                         <filename>linux-yocto-dev</filename></emphasis> - A
                         development kernel based on the latest upstream release
                         candidate available.
                         </para></listitem>
                 </itemizedlist>
+                <note>
+                    Long Term Support Initiative (LTSI) for Yocto Project kernels
+                    is as follows:
+                    <itemizedlist>
+                        <listitem><para>For Yocto Project releases 1.7, 1.8, and 2.0,
+                            the LTSI kernel is <filename>linux-yocto-3.14</filename>.
+                            </para></listitem>
+                        <listitem><para>For Yocto Project release 2.1, the
+                            LTSI kernel is <filename>linux-yocto-4.1</filename>.
+                            </para></listitem>
+                    </itemizedlist>
+                </note>
             </para>
 
             <para>
@@ -535,1161 +564,18 @@
     </section>
 </section>
 
-<section id='application-development-workflow'>
-    <title>Application Development Workflow</title>
+<section id='application-development-workflow-using-an-sdk'>
+    <title>Application Development Workflow Using an SDK</title>
 
     <para>
-        Application development involves creating an application that you want
-        to run on your target hardware, which is running a kernel image created using the
-        OpenEmbedded build system.
-        The Yocto Project provides an
-        <ulink url='&YOCTO_DOCS_ADT_URL;#adt-intro'>Application Development Toolkit (ADT)</ulink>
-        and stand-alone
-        <ulink url='&YOCTO_DOCS_ADT_URL;#the-cross-development-toolchain'>cross-development toolchains</ulink>
-        that facilitate quick development and integration of your application into its runtime environment.
-        Using the ADT and toolchains, you can compile and link your application.
-        You can then deploy your application to the actual hardware or to the QEMU emulator for testing.
-        If you are familiar with the popular <trademark class='trade'>Eclipse</trademark> IDE,
-        you can use an Eclipse Yocto Plug-in to
-        allow you to develop, deploy, and test your application all from within Eclipse.
+        Standard and extensible Software Development Kits (SDK) make it easy
+        to develop applications inside or outside of the Yocto Project
+        development environment.
+        Tools exist to help the application developer during any phase
+        of development.
+        For information on how to install and use an SDK, see the
+        <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
     </para>
-
-    <para>
-        While we strongly suggest using the ADT to develop your application, this option might not
-        be best for you.
-        If this is the case, you can still use pieces of the Yocto Project for your development process.
-        However, because the process can vary greatly, this manual does not provide detail on the process.
-    </para>
-
-    <section id='workflow-using-the-adt-and-eclipse'>
-        <title>Workflow Using the ADT and <trademark class='trade'>Eclipse</trademark></title>
-
-        <para>
-            To help you understand how application development works using the ADT, this section
-            provides an overview of the general development process and a detailed example of the process
-            as it is used from within the Eclipse IDE.
-        </para>
-
-        <para>
-            The following illustration and list summarize the application development general workflow.
-        </para>
-
-        <para>
-            <imagedata fileref="figures/app-dev-flow.png"
-                width="7in" depth="8in" align="center" scale="100" />
-        </para>
-
-        <para>
-            <orderedlist>
-                <listitem><para><emphasis>Prepare the host system for the Yocto Project</emphasis>:
-                    See
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
-                    and
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>" sections both
-                    in the Yocto Project Reference Manual for requirements.
-                    In particular, be sure your host system has the
-                    <filename>xterm</filename> package installed.
-                    </para></listitem>
-                <listitem><para><emphasis>Secure the Yocto Project kernel target image</emphasis>:
-                    You must have a target kernel image that has been built using the OpenEmbedded
-                    build system.</para>
-                    <para>Depending on whether the Yocto Project has a pre-built image that matches your target
-                    architecture and where you are going to run the image while you develop your application
-                    (QEMU or real hardware), the area from which you get the image differs.
-                        <itemizedlist>
-                            <listitem><para>Download the image from
-                                <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
-                                if your target architecture is supported and you are going to develop
-                                and test your application on actual hardware.</para></listitem>
-                            <listitem><para>Download the image from
-                                <ulink url='&YOCTO_QEMU_DL_URL;'>
-                                <filename>machines/qemu</filename></ulink> if your target architecture is supported
-                                and you are going to develop and test your application using the QEMU
-                                emulator.</para></listitem>
-                            <listitem><para>Build your image if you cannot find a pre-built image that matches
-                                your target architecture.
-                                If your target architecture is similar to a supported architecture, you can
-                                modify the kernel image before you build it.
-                                See the
-                                "<link linkend='patching-the-kernel'>Patching the Kernel</link>"
-                                section for an example.</para></listitem>
-                        </itemizedlist></para>
-                    <para>For information on pre-built kernel image naming schemes for images
-                    that can run on the QEMU emulator, see the
-                    "<ulink url='&YOCTO_DOCS_QS_URL;#downloading-the-pre-built-linux-kernel'>Downloading the Pre-Built Linux Kernel</ulink>"
-                    section in the Yocto Project Application Developer's Guide.</para></listitem>
-                <listitem><para><emphasis>Install the ADT</emphasis>:
-                    The ADT provides a target-specific cross-development toolchain, the root filesystem,
-                    the QEMU emulator, and other tools that can help you develop your application.
-                    While it is possible to get these pieces separately, the ADT Installer provides an
-                    easy, inclusive method.
-                    You can get these pieces by running an ADT installer script, which is configurable.
-                    For information on how to install the ADT, see the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>"
-                    section
-                    in the Yocto Project Application Developer's Guide.</para></listitem>
-                <listitem><para><emphasis>If applicable, secure the target root filesystem
-                    and the Cross-development toolchain</emphasis>:
-                    If you choose not to install the ADT using the ADT Installer,
-                    you need to find and download the appropriate root filesystem and
-                    the cross-development toolchain.</para>
-                    <para>You can find the tarballs for the root filesystem in the same area used
-                    for the kernel image.
-                    Depending on the type of image you are running, the root filesystem you need differs.
-                    For example, if you are developing an application that runs on an image that
-                    supports Sato, you need to get a root filesystem that supports Sato.</para>
-                    <para>You can find the cross-development toolchains at
-                    <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>.
-                    Be sure to get the correct toolchain for your development host and your
-                    target architecture.
-                    See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
-                    section in the Yocto Project Application Developer's Guide for information
-                    and the
-                    "<ulink url='&YOCTO_DOCS_QS_URL;#installing-the-toolchain'>Installing the Toolchain</ulink>"
-                    in the Yocto Project Application Developer's Guide for information on finding and installing
-                    the correct toolchain based on your host development system and your target
-                    architecture.
-                    </para></listitem>
-                <listitem><para><emphasis>Create and build your application</emphasis>:
-                    At this point, you need to have source files for your application.
-                    Once you have the files, you can use the Eclipse IDE to import them and build the
-                    project.
-                    If you are not using Eclipse, you need to use the cross-development tools you have
-                    installed to create the image.</para></listitem>
-                <listitem><para><emphasis>Deploy the image with the application</emphasis>:
-                    If you are using the Eclipse IDE, you can deploy your image to the hardware or to
-                    QEMU through the project's preferences.
-                    If you are not using the Eclipse IDE, then you need to deploy the application
-                    to the hardware using other methods.
-                    Or, if you are using QEMU, you need to use that tool and
-                    load your image in for testing.
-                    See the
-                    "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
-                    chapter for information on using QEMU.
-                    </para></listitem>
-                <listitem><para><emphasis>Test and debug the application</emphasis>:
-                    Once your application is deployed, you need to test it.
-                    Within the Eclipse IDE, you can use the debugging environment along with the
-                    set of user-space tools installed along with the ADT to debug your application.
-                    Of course, the same user-space tools are available separately if you choose
-                    not to use the Eclipse IDE.</para></listitem>
-           </orderedlist>
-        </para>
-    </section>
-
-    <section id='adt-eclipse'>
-        <title>Working Within Eclipse</title>
-
-        <para>
-            The Eclipse IDE is a popular development environment and it fully
-            supports development using the Yocto Project.
-            <note>
-                This release of the Yocto Project supports both the Luna
-                and Kepler versions of the Eclipse IDE.
-                Thus, the following information provides setup information for
-                both versions.
-            </note>
-        </para>
-
-        <para>
-            When you install and configure the Eclipse Yocto Project Plug-in
-            into the Eclipse IDE, you maximize your Yocto Project 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, deployment, and
-            execution of your output into a QEMU emulation session as well as
-            actual target hardware.
-            You can also perform cross-debugging and profiling.
-            The environment also supports a suite of tools that allows you
-            to perform remote profiling, tracing, collection of power data,
-            collection of 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 application.
-        </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>Install the optimal version of the Eclipse
-                       IDE.</para></listitem>
-                    <listitem><para>Configure the Eclipse IDE.
-                       </para></listitem>
-                    <listitem><para>Install the Eclipse Yocto Plug-in.
-                       </para></listitem>
-                    <listitem><para>Configure the Eclipse Yocto Plug-in.
-                       </para></listitem>
-                </orderedlist>
-                <note>
-                    Do not install Eclipse from your distribution's package
-                    repository.
-                    Be sure to install Eclipse from the official Eclipse
-                    download site as directed in the next section.
-                </note>
-            </para>
-
-            <section id='installing-eclipse-ide'>
-                <title>Installing the Eclipse IDE</title>
-
-                <para>
-                    It is recommended that you have the Luna SR2 (4.4.2)
-                    version of the Eclipse IDE installed on your development
-                    system.
-                    However, if you currently have the Kepler 4.3.2 version
-                    installed and you do not want to upgrade the IDE, you can
-                    configure Kepler to work with the Yocto Project.
-                </para>
-
-                <para>
-                    If you do not have the Luna SR2 (4.4.2) Eclipse IDE
-                    installed, you can find the tarball at
-                    <ulink url='&ECLIPSE_MAIN_URL;'></ulink>.
-                    From that site, choose the appropriate download from the
-                    "Eclipse IDE for C/C++ Developers".
-                    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.
-                    For example, the following commands unpack and install the
-                    downloaded Eclipse IDE tarball into a clean directory
-                    using the default name <filename>eclipse</filename>:
-                    <literallayout class='monospaced'>
-     $ cd ~
-     $ tar -xzvf ~/Downloads/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id='configuring-the-eclipse-ide'>
-                <title>Configuring the Eclipse IDE</title>
-
-                <para>
-                    This section presents the steps needed to configure the
-                    Eclipse IDE.
-                </para>
-
-                <para>
-                    Before installing and configuring the Eclipse Yocto Plug-in,
-                    you need to configure the Eclipse IDE.
-                    Follow these general steps:
-                    <orderedlist>
-                        <listitem><para>Start the Eclipse IDE.</para></listitem>
-                        <listitem><para>Make sure you are in your Workbench and
-                            select "Install New Software" from the "Help"
-                            pull-down menu.</para></listitem>
-                        <listitem><para>Select
-                            <filename>Luna - &ECLIPSE_LUNA_URL;</filename>
-                            from the "Work with:" pull-down menu.
-                            <note>
-                                For Kepler, select
-                                <filename>Kepler - &ECLIPSE_KEPLER_URL;</filename>
-                            </note>
-                            </para></listitem>
-                        <listitem><para>Expand the box next to "Linux Tools"
-                            and select the
-                            <filename>Linux Tools LTTng Tracer Control</filename>,
-                            <filename>Linux Tools LTTng Userspace Analysis</filename>,
-                            and
-                            <filename>LTTng Kernel Analysis</filename> boxes.
-                            If these selections do not appear in the list,
-                            that means the items are already installed.
-                            <note>
-                                For Kepler, select
-                                <filename>LTTng - Linux Tracing Toolkit</filename>
-                                box.
-                            </note>
-                            </para></listitem>
-                        <listitem><para>Expand the box next to "Mobile and
-                            Device Development" and select the following boxes.
-                            Again, if any of the following items are not
-                            available for selection, that means the items are
-                            already installed:
-                            <itemizedlist>
-                                <listitem><para><filename>C/C++ Remote Launch (Requires RSE Remote System Explorer)</filename></para></listitem>
-                                <listitem><para><filename>Remote System Explorer End-user Runtime</filename></para></listitem>
-                                <listitem><para><filename>Remote System Explorer User Actions</filename></para></listitem>
-                                <listitem><para><filename>Target Management Terminal (Core SDK)</filename></para></listitem>
-                                <listitem><para><filename>TCF Remote System Explorer add-in</filename></para></listitem>
-                                <listitem><para><filename>TCF Target Explorer</filename></para></listitem>
-                            </itemizedlist></para></listitem>
-                        <listitem><para>Expand the box next to "Programming
-                            Languages" and select the
-                            <filename>C/C++ Autotools Support</filename>
-                            and <filename>C/C++ Development Tools</filename>
-                            boxes.
-                            For Luna, these items do not appear on the list
-                            as they are already installed.
-                            </para></listitem>
-                        <listitem><para>Complete the installation and restart
-                            the Eclipse IDE.</para></listitem>
-                    </orderedlist>
-                </para>
-            </section>
-
-            <section id='installing-the-eclipse-yocto-plug-in'>
-                <title>Installing or Accessing the Eclipse Yocto Plug-in</title>
-
-                <para>
-                    You can install the Eclipse Yocto Plug-in into the Eclipse
-                    IDE one of two ways:  use the Yocto Project's Eclipse
-                    Update site to install the pre-built plug-in or build and
-                    install the plug-in from the latest source code.
-                </para>
-
-                <section id='new-software'>
-                    <title>Installing the Pre-built Plug-in from the Yocto Project Eclipse Update Site</title>
-
-                    <para>
-                        To install the Eclipse Yocto Plug-in from the update
-                        site, follow these steps:
-                        <orderedlist>
-                            <listitem><para>Start up the Eclipse IDE.
-                                </para></listitem>
-                            <listitem><para>In Eclipse, select "Install New
-                                Software" from the "Help" menu.
-                                </para></listitem>
-                            <listitem><para>Click "Add..." in the "Work with:"
-                                area.</para></listitem>
-                           <listitem><para>Enter
-                                <filename>&ECLIPSE_DL_PLUGIN_URL;/luna</filename>
-                                in the URL field and provide a meaningful name
-                                in the "Name" field.
-                                <note>
-                                    If you are using Kepler, use
-                                    <filename>&ECLIPSE_DL_PLUGIN_URL;/kepler</filename>
-                                    in the URL field.
-                                </note></para></listitem>
-                            <listitem><para>Click "OK" to have the entry added
-                                to the "Work with:" drop-down list.
-                                </para></listitem>
-                            <listitem><para>Select the entry for the plug-in
-                                from the "Work with:" drop-down list.
-                                </para></listitem>
-                            <listitem><para>Check the boxes next to
-                                <filename>Yocto Project ADT Plug-in</filename>,
-                                <filename>Yocto Project Bitbake Commander Plug-in</filename>,
-                                and
-                                <filename>Yocto Project Documentation plug-in</filename>.
-                                </para></listitem>
-                            <listitem><para>Complete the remaining software
-                                installation steps and then restart the Eclipse
-                                IDE to finish the installation of the plug-in.
-                                <note>
-                                    You can click "OK" when prompted about
-                                    installing software that contains unsigned
-                                    content.
-                                </note>
-                                </para></listitem>
-                        </orderedlist>
-                    </para>
-                </section>
-
-               <section id='zip-file-method'>
-                   <title>Installing the Plug-in Using the Latest Source Code</title>
-
-                   <para>
-                        To install the Eclipse Yocto Plug-in from the latest
-                        source code, follow these steps:
-                        <orderedlist>
-                            <listitem><para>Be sure your development system
-                                is not using OpenJDK to build the plug-in
-                                by doing the following:
-                                <orderedlist>
-                                    <listitem><para>Use the Oracle JDK.
-                                        If you don't have that, go to
-                                        <ulink url='http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html'></ulink>
-                                        and download the latest appropriate
-                                        Java SE Development Kit tarball for
-                                        your development system and
-                                        extract it into your home directory.
-                                        </para></listitem>
-                                    <listitem><para>In the shell you are going
-                                        to do your work, export the location of
-                                        the Oracle Java.
-                                        The previous step creates a new folder
-                                        for the extracted software.
-                                        You need to use the following
-                                        <filename>export</filename> command
-                                        and provide the specific location:
-                                        <literallayout class='monospaced'>
-     export PATH=~/<replaceable>extracted_jdk_location</replaceable>/bin:$PATH
-                                        </literallayout>
-                                        </para></listitem>
-                                </orderedlist>
-                                </para></listitem>
-                            <listitem><para>In the same shell, create a Git
-                                repository with:
-                                <literallayout class='monospaced'>
-     $ cd ~
-     $ git clone git://git.yoctoproject.org/eclipse-poky
-                                </literallayout>
-                                </para></listitem>
-                            <listitem><para>Be sure to checkout the correct
-                                tag.
-                                For example, if you are using Luna, do the
-                                following:
-                                <literallayout class='monospaced'>
-     $ git checkout luna/yocto-&DISTRO;
-                                </literallayout>
-                                This puts you in a detached HEAD state, which
-                                is fine since you are only going to be building
-                                and not developing.
-                                <note>
-                                    If you are building kepler, checkout the
-                                    <filename>kepler/yocto-&DISTRO;</filename>
-                                    branch.
-                                </note>
-                                </para></listitem>
-                            <listitem><para>Change to the
-                                <filename>scripts</filename>
-                                directory within the Git repository:
-                                <literallayout class='monospaced'>
-     $ cd scripts
-                                </literallayout>
-                                </para></listitem>
-                            <listitem><para>Set up the local build environment
-                                by running the setup script:
-                                <literallayout class='monospaced'>
-     $ ./setup.sh
-                                </literallayout>
-                                </para></listitem>
-                            <listitem><para>When the script finishes execution,
-                                it prompts you with instructions on how to run
-                                the <filename>build.sh</filename> script, which
-                                is also in the <filename>scripts</filename>
-                                directory of the Git repository created
-                                earlier.
-                                </para></listitem>
-                            <listitem><para>Run the <filename>build.sh</filename>
-                                script as directed.
-                                Be sure to provide the tag name, documentation
-                                branch, and a release name.
-                                Here is an example that uses the
-                                <filename>luna/yocto-&DISTRO;</filename> tag, the
-                                <filename>master</filename> documentation
-                                branch, and
-                                <filename>&DISTRO_NAME;</filename> for the
-                                release name:
-                                <literallayout class='monospaced'>
-     $ ECLIPSE_HOME=/home/scottrif/eclipse-poky/scripts/eclipse ./build.sh luna/yocto-&DISTRO; master &DISTRO_NAME; 2>&amp;1 | tee -a build.log
-                                </literallayout>
-                                After running the script, the file
-                                <filename>org.yocto.sdk-</filename><replaceable>release</replaceable><filename>-</filename><replaceable>date</replaceable><filename>-archive.zip</filename>
-                                is in the current directory.
-                                </para></listitem>
-                            <listitem><para>If necessary, start the Eclipse IDE
-                                and be sure you are in the Workbench.
-                                </para></listitem>
-                            <listitem><para>Select "Install New Software" from
-                                the "Help" pull-down menu.
-                                </para></listitem>
-                            <listitem><para>Click "Add".</para></listitem>
-                            <listitem><para>Provide anything you want in the
-                                "Name" field.
-                                </para></listitem>
-                            <listitem><para>Click "Archive" and browse to the
-                                ZIP file you built in step eight.
-                                This ZIP file should not be "unzipped", and must
-                                be the <filename>*archive.zip</filename> file
-                                created by running the
-                                <filename>build.sh</filename> script.
-                                </para></listitem>
-                            <listitem><para>Click the "OK" button.
-                                </para></listitem>
-                            <listitem><para>Check the boxes that appear in
-                                the installation window to install the
-                                <filename>Yocto Project ADT Plug-in</filename>,
-                                <filename>Yocto Project Bitbake Commander Plug-in</filename>,
-                                and the
-                                <filename>Yocto Project Documentation plug-in</filename>.
-                                </para></listitem>
-                            <listitem><para>Finish the installation by clicking
-                                through the appropriate buttons.
-                                You can click "OK" when prompted about
-                                installing software that contains unsigned
-                                content.
-                                </para></listitem>
-                            <listitem><para>Restart the Eclipse IDE if
-                                necessary.
-                                </para></listitem>
-                        </orderedlist>
-                    </para>
-
-                    <para>
-                        At this point you should be able to configure the
-                        Eclipse Yocto Plug-in as described in the
-                        "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>"
-                        section.</para>
-                </section>
-            </section>
-
-            <section id='configuring-the-eclipse-yocto-plug-in'>
-                <title>Configuring the Eclipse Yocto Plug-in</title>
-
-                <para>
-                    Configuring the Eclipse Yocto Plug-in involves setting the
-                    Cross Compiler options and the Target options.
-                    The configurations you choose become the default settings
-                    for all projects.
-                    You do have opportunities to change them later when
-                    you configure the project (see the following section).
-                </para>
-
-                <para>
-                    To start, you need to do the following from within the
-                    Eclipse IDE:
-                    <itemizedlist>
-                        <listitem><para>Choose "Preferences" from the
-                            "Window" menu to display the Preferences Dialog.
-                            </para></listitem>
-                        <listitem><para>Click "Yocto Project ADT" to display
-                            the configuration screen.
-                            </para></listitem>
-                    </itemizedlist>
-                </para>
-
-                <section id='configuring-the-cross-compiler-options'>
-                    <title>Configuring the Cross-Compiler Options</title>
-
-                    <para>
-                        To configure the Cross Compiler Options, you must select
-                        the type of toolchain, point to the toolchain, specify
-                        the sysroot location, and select the target
-                        architecture.
-                        <itemizedlist>
-                            <listitem><para><emphasis>Selecting the Toolchain Type:</emphasis>
-                                Choose between
-                                <filename>Standalone pre-built toolchain</filename>
-                                and
-                                <filename>Build system derived toolchain</filename>
-                                for Cross Compiler Options.
-                                    <itemizedlist>
-                                        <listitem><para><emphasis>
-                                            <filename>Standalone Pre-built Toolchain:</filename></emphasis>
-                                            Select this mode when you are using
-                                            a stand-alone cross-toolchain.
-                                            For example, suppose you are an
-                                            application developer and do not
-                                            need to build a target image.
-                                            Instead, you just want to use an
-                                            architecture-specific toolchain on
-                                            an existing kernel and target root
-                                            filesystem.</para></listitem>
-                                       <listitem><para><emphasis>
-                                            <filename>Build System Derived Toolchain:</filename></emphasis>
-                                            Select this mode if the
-                                            cross-toolchain has been installed
-                                            and built as part of the
-                                            <link linkend='build-directory'>Build Directory</link>.
-                                            When you select
-                                            <filename>Build system derived toolchain</filename>,
-                                            you are using the toolchain bundled
-                                            inside the Build Directory.
-                                            </para></listitem>
-                                    </itemizedlist>
-                                </para></listitem>
-                            <listitem><para><emphasis>Point to the Toolchain:</emphasis>
-                                If you are using a stand-alone pre-built
-                                toolchain, you should be pointing to where it is
-                                installed.
-                                If you used the ADT Installer script and
-                                accepted the default installation directory, the
-                                toolchain will be installed in the
-                                <filename>&YOCTO_ADTPATH_DIR;</filename>
-                                directory.
-                                Sections "<ulink url='&YOCTO_DOCS_ADT_URL;#configuring-and-running-the-adt-installer-script'>Configuring and Running the ADT Installer Script</ulink>"
-                                and
-                                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
-                                in the Yocto Project Application Developer's
-                                Guide describe how to install a stand-alone
-                                cross-toolchain.</para>
-                                <para>If you are using a system-derived
-                                toolchain, the path you provide for the
-                                <filename>Toolchain Root Location</filename>
-                                field is the
-                                <link linkend='build-directory'>Build Directory</link>.
-                                See the
-                                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Build Directory</ulink>"
-                                section in the Yocto Project Application
-                                Developer's Guide for information on how to
-                                install the toolchain into the Build
-                                Directory.</para></listitem>
-                            <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
-                                This location is where the root filesystem for
-                                the target hardware resides.
-                                If you used the ADT Installer script and
-                                accepted the default installation directory,
-                                then the location in your home directory
-                                in a folder named
-                                <filename>test-yocto/</filename><replaceable>target_arch</replaceable>.
-                                Additionally, when you use the ADT Installer
-                                script, the
-                                <filename>/opt/poky/&DISTRO;/sysroots</filename>
-                                location is used for the QEMU
-                                user-space tools and the NFS boot process.
-                                </para>
-                                <para>If you used either of the other two
-                                methods to install the toolchain or did not
-                                accept the ADT Installer script's default
-                                installation directory, then the location of
-                                the sysroot filesystem depends on where you
-                                separately extracted and installed the
-                                filesystem.</para>
-                                <para>For information on how to install the
-                                toolchain and on how to extract and install the
-                                sysroot filesystem, see the
-                                "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
-                                section in the Yocto Project Application
-                                Developer's Guide.
-                                </para></listitem>
-                            <listitem><para><emphasis>Select the Target Architecture:</emphasis>
-                                The target architecture is the type of hardware
-                                you are going to use or emulate.
-                                Use the pull-down
-                                <filename>Target Architecture</filename> menu
-                                to make your selection.
-                                The pull-down menu should have the supported
-                                architectures.
-                                If the architecture you need is not listed in
-                                the menu, you will need to build the image.
-                                See the
-                                "<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
-                                section of the Yocto Project Quick Start for
-                                more information.</para></listitem>
-                        </itemizedlist>
-                    </para>
-                </section>
-
-                <section id='configuring-the-target-options'>
-                    <title>Configuring the Target Options</title>
-
-                    <para>
-                        You can choose to emulate hardware using the QEMU
-                        emulator, or you can choose to run your image on actual
-                        hardware.
-                        <itemizedlist>
-                            <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 specify any custom
-                                options.</para>
-                                <para>If you selected
-                                <filename>Build system derived toolchain</filename>,
-                                the target kernel you built will be located in
-                                the Build Directory in
-                                <filename>tmp/deploy/images/<replaceable>machine</replaceable></filename>
-                                directory.
-                                If you selected
-                                <filename>Standalone pre-built toolchain</filename>,
-                                the pre-built image 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 as part of the Cross-Compiler Options
-                                configuration in the
-                                <filename>Sysroot Location:</filename> field.
-                                </para></listitem>
-                            <listitem><para><emphasis>External HW:</emphasis>
-                                Select this option if you will be using actual
-                                hardware.</para></listitem>
-                        </itemizedlist>
-                    </para>
-
-                    <para>
-                        Click the "OK" 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 Makefile-based projects in a
-                terminal window, see the section
-                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-command-line'>Using the Command Line</ulink>"
-                in the Yocto Project Application Developer's Guide.
-                <note>
-                    Do not use special characters in project names
-                    (e.g. spaces, underscores, etc.).  Doing so can
-                    cause configuration to fail.
-                </note>
-            </para>
-
-            <para>
-                To create a project based on a Yocto template and then display
-                the source code, follow these steps:
-                <orderedlist>
-                    <listitem><para>Select "Project" from the "File -> New" menu.
-                        </para></listitem>
-                    <listitem><para>Double click <filename>CC++</filename>.
-                        </para></listitem>
-                    <listitem><para>Double click <filename>C Project</filename>
-                        to create the project.</para></listitem>
-                    <listitem><para>Expand <filename>Yocto Project ADT Autotools Project</filename>.
-                        </para></listitem>
-                    <listitem><para>Select <filename>Hello World ANSI C Autotools Project</filename>.
-                        This is an Autotools-based project based on a Yocto
-                        template.</para></listitem>
-                    <listitem><para>Put a name in the <filename>Project name:</filename>
-                        field.
-                        Do not use hyphens as part of the name.
-                        </para></listitem>
-                    <listitem><para>Click "Next".</para></listitem>
-                    <listitem><para>Add information in the
-                        <filename>Author</filename> and
-                        <filename>Copyright notice</filename> fields.
-                        </para></listitem>
-                    <listitem><para>Be sure the <filename>License</filename>
-                        field is correct.</para></listitem>
-                    <listitem><para>Click "Finish".</para></listitem>
-                    <listitem><para>If the "open perspective" prompt appears,
-                        click "Yes" so that you in the C/C++ perspective.
-                        </para></listitem>
-                    <listitem><para>The left-hand navigation pane shows your
-                        project.
-                        You can display your source by double clicking the
-                        project's source file.</para></listitem>
-                </orderedlist>
-            </para>
-        </section>
-
-        <section id='configuring-the-cross-toolchains'>
-            <title>Configuring the Cross-Toolchains</title>
-
-            <para>
-                The earlier section,
-                "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>",
-                sets up the default project configurations.
-                You can override these settings for a given project by following
-                these steps:
-                <orderedlist>
-                    <listitem><para>Select "Change Yocto Project Settings" from
-                        the "Project" menu.
-                        This selection brings up the Yocto Project Settings
-                        Dialog and allows you to make changes specific to an
-                        individual project.</para>
-                        <para>By default, the Cross Compiler Options and Target
-                        Options for a project are inherited from settings you
-                        provided using the Preferences Dialog as described
-                        earlier in the
-                        "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>" section.
-                        The Yocto Project Settings Dialog allows you to override
-                        those default settings for a given project.
-                        </para></listitem>
-                    <listitem><para>Make your configurations for the project
-                        and click "OK".
-                        </para></listitem>
-                    <listitem><para>Right-click in the navigation pane and
-                        select "Reconfigure Project" from the pop-up menu.
-                        This selection reconfigures the project by running
-                        <filename>autogen.sh</filename> in the workspace for
-                        your project.
-                        The script also runs <filename>libtoolize</filename>,
-                        <filename>aclocal</filename>,
-                        <filename>autoconf</filename>,
-                        <filename>autoheader</filename>,
-                        <filename>automake --a</filename>, and
-                        <filename>./configure</filename>.
-                        Click on the "Console" tab beneath your source code to
-                        see the results of reconfiguring your project.
-                        </para></listitem>
-                </orderedlist>
-            </para>
-        </section>
-
-        <section id='building-the-project'>
-            <title>Building the Project</title>
-
-            <para>
-                To build the project select "Build Project" from the
-                "Project" menu.
-                The console should update and you can note the cross-compiler
-                you are using.
-                <note>
-                    When building "Yocto Project ADT Autotools" projects, the Eclipse
-                    IDE might display error messages for Functions/Symbols/Types
-                    that cannot be "resolved", even when the related include file
-                    is listed at the project navigator and when the project is
-                    able to build.
-                    For these cases only, it is recommended to add a new linked
-                    folder to the appropriate sysroot.
-                    Use these steps to add the linked folder:
-                    <orderedlist>
-                        <listitem><para>
-                            Select the project.
-                            </para></listitem>
-                        <listitem><para>
-                            Select "Folder" from the
-                            <filename>File > New</filename> menu.
-                            </para></listitem>
-                        <listitem><para>
-                            In the "New Folder" Dialog, select "Link to alternate
-                            location (linked folder)".
-                            </para></listitem>
-                        <listitem><para>
-                            Click "Browse" to navigate to the include folder inside
-                            the same sysroot location selected in the Yocto Project
-                            configuration preferences.
-                            </para></listitem>
-                        <listitem><para>
-                            Click "OK".
-                            </para></listitem>
-                        <listitem><para>
-                            Click "Finish" to save the linked folder.
-                            </para></listitem>
-                    </orderedlist>
-                </note>
-            </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:
-                <note>
-                    See the
-                    "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
-                    chapter for more information on using QEMU.
-                </note>
-                <orderedlist>
-                    <listitem><para>Expose and select "External Tools" from
-                        the "Run" menu.
-                        Your image should appear as a selectable menu item.
-                        </para></listitem>
-                    <listitem><para>Select your image from the menu to launch
-                        the emulator in a new window.
-                        </para></listitem>
-                    <listitem><para>If needed, enter your host root password in
-                        the shell window at the prompt.
-                        This sets up a <filename>Tap 0</filename> 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 can begin operating
-                        within that environment.
-                        One useful task at this point would be to determine the
-                        IP Address for the user-space NFS by using the
-                       <filename>ifconfig</filename> command.
-                       </para></listitem>
-                </orderedlist>
-            </para>
-        </section>
-
-        <section id='deploying-and-debugging-the-application'>
-            <title>Deploying and Debugging the Application</title>
-
-            <para>
-                Once the QEMU emulator is running the image, you can deploy
-                your application using the Eclipse IDE and then use
-                the emulator to perform debugging.
-                Follow these steps to deploy the application.
-                <orderedlist>
-                    <listitem><para>Select "Debug Configurations..." from the
-                        "Run" menu.</para></listitem>
-                    <listitem><para>In the left area, expand
-                        <filename>C/C++Remote Application</filename>.
-                        </para></listitem>
-                    <listitem><para>Locate your project and select it to bring
-                        up a new tabbed view in the Debug Configurations Dialog.
-                        </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:" field.
-                        For example, enter
-                        <filename>/usr/bin/<replaceable>programname</replaceable></filename>.
-                        </para></listitem>
-                    <listitem><para>Click on the "Debugger" tab to see the
-                        cross-tool debugger you are using.</para></listitem>
-                    <listitem><para>Click on the "Main" tab.</para></listitem>
-                    <listitem><para>Create a new connection to the QEMU instance
-                        by clicking on "new".</para></listitem>
-                    <listitem><para>Select <filename>TCF</filename>, 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 Dialog.</para></listitem>
-                    <listitem><para>Use the drop-down menu now in the
-                        "Connection" field and pick the IP Address you entered.
-                         </para></listitem>
-                    <listitem><para>Click "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 Eclipse
-                IDE through the "YoctoProjectTools" 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><filename>OProfile</filename>:</emphasis>
-                        Selecting this tool causes the
-                        <filename>oprofile-server</filename> on the remote
-                        target to launch on the local host machine.
-                        The <filename>oprofile-viewer</filename> must be
-                        installed on the local host machine and the
-                        <filename>oprofile-server</filename> must be installed
-                        on the remote target, respectively, in order to use.
-                        You must compile and install the
-                        <filename>oprofile-viewer</filename> from the source
-                        code on your local host machine.
-                        Furthermore, in order to convert the target's sample
-                        format data into a form that the host can use, you must
-                        have OProfile version 0.9.4 or greater installed on the
-                        host.</para>
-                        <para>You can locate both the viewer and server from
-                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>.
-                        You can also find more information on setting up and
-                        using this tool in the
-                        "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>oprofile</ulink>"
-                        section of the Yocto Project Profiling and Tracing
-                        Manual.
-                        <note>The <filename>oprofile-server</filename> is
-                        installed by default on the
-                        <filename>core-image-sato-sdk</filename> image.</note>
-                        </para></listitem>
-                    <listitem><para><emphasis><filename>Lttng2.0 trace import</filename>:</emphasis>
-                        Selecting this tool transfers the remote target's
-                        <filename>Lttng</filename> tracing data back to the
-                        local host machine and uses the Lttng Eclipse plug-in
-                        to graphically display the output.
-                        For information on how to use Lttng to trace an
-                        application,
-                        see <ulink url='http://lttng.org/documentation'></ulink>
-                        and the
-                        "<ulink url='&YOCTO_DOCS_PROF_URL;#lttng-linux-trace-toolkit-next-generation'>LTTng (Linux Trace Toolkit, next generation)</ulink>"
-                        section, which is in the Yocto Project Profiling and
-                        Tracing Manual.
-                        <note>Do not use
-                            <filename>Lttng-user space (legacy)</filename> tool.
-                            This tool no longer has any upstream support.</note>
-                        </para>
-                        <para>Before you use the
-                        <filename>Lttng2.0 trace import</filename> tool,
-                        you need to setup the Lttng Eclipse plug-in and create a
-                        Tracing project.
-                        Do the following:
-                        <orderedlist>
-                            <listitem><para>Select "Open Perspective" from the
-                                "Window" menu and then select "Other..." to
-                                bring up a menu of other perspectives.
-                                Choose "Tracing".
-                                </para></listitem>
-                            <listitem><para>Click "OK" to change the Eclipse
-                                perspective into the Tracing perspective.
-                                </para></listitem>
-                            <listitem><para>Create a new Tracing project by
-                                selecting "Project" from the "File -> New" menu.
-                                </para></listitem>
-                            <listitem><para>Choose "Tracing Project" from the
-                                "Tracing" menu and click "Next".
-                                </para></listitem>
-                            <listitem><para>Provide a name for your tracing
-                                project and click "Finish".
-                                </para></listitem>
-                            <listitem><para>Generate your tracing data on the
-                                remote target.</para></listitem>
-                            <listitem><para>Select "Lttng2.0 trace import"
-                                from the "Yocto Project Tools" menu to
-                                start the data import process.</para></listitem>
-                            <listitem><para>Specify your remote connection name.
-                                </para></listitem>
-                            <listitem><para>For the Ust directory path, specify
-                                the location of your remote tracing data.
-                                Make sure the location ends with
-                                <filename>ust</filename> (e.g.
-                                <filename>/usr/mysession/ust</filename>).
-                                </para></listitem>
-                            <listitem><para>Click "OK" to complete the import
-                                process.
-                                The data is now in the local tracing project
-                                you created.</para></listitem>
-                            <listitem><para>Right click on the data and then use
-                                the menu to Select "Generic CTF Trace" from the
-                                "Trace Type... -> Common Trace Format" menu to
-                                map the tracing type.</para></listitem>
-                            <listitem><para>Right click the mouse and select
-                                "Open" to bring up the Eclipse Lttng Trace
-                                Viewer so you view the tracing data.
-                                </para></listitem>
-                        </orderedlist></para></listitem>
-                    <listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis>
-                        Selecting this tool runs PowerTOP on the remote target
-                        machine and displays the results in a new view called
-                        PowerTOP.</para>
-                        <para>The "Time to gather data(sec):" field is the time
-                        passed in seconds before data is gathered from the
-                        remote target for analysis.</para>
-                        <para>The "show pids in wakeups list:" field corresponds
-                        to the <filename>-p</filename> argument passed to
-                        <filename>PowerTOP</filename>.</para></listitem>
-                    <listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
-                        LatencyTOP identifies system latency, while
-                        Perf monitors the system's performance counter
-                        registers.
-                        Selecting either of these tools causes an RSE terminal
-                        view to appear from which you can run the tools.
-                        Both tools refresh the entire screen to display results
-                        while they run.
-                        For more information on setting up and using
-                        <filename>perf</filename>, see the
-                        "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
-                        section in the Yocto Project Profiling and Tracing
-                        Manual.
-                        </para></listitem>
-                    <listitem><para><emphasis><filename>SystemTap</filename>:</emphasis>
-                        Systemtap is a tool that lets you create and reuse
-                        scripts to examine the activities of a live Linux
-                        system.
-                        You can easily extract, filter, and summarize data
-                        that helps you diagnose complex performance or
-                        functional problems.
-                        For more information on setting up and using
-                        <filename>SystemTap</filename>, see the
-                        <ulink url='https://sourceware.org/systemtap/documentation.html'>SystemTap Documentation</ulink>.
-                        </para></listitem>
-                    <listitem><para><emphasis><filename>yocto-bsp</filename>:</emphasis>
-                        The <filename>yocto-bsp</filename> tool lets you
-                        quickly set up a Board Support Package (BSP) layer.
-                        The tool requires a Metadata location, build location,
-                        BSP name, BSP output location, and a kernel
-                        architecture.
-                        For more information on the
-                        <filename>yocto-bsp</filename> tool outside of Eclipse,
-                        see the
-                        "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a new BSP Layer Using the yocto-bsp Script</ulink>"
-                        section in the Yocto Project Board Support Package
-                        (BSP) Developer's Guide.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-        </section>
-    </section>
-
-    <section id='workflow-using-stand-alone-cross-development-toolchains'>
-        <title>Workflow Using Stand-Alone Cross-Development Toolchains</title>
-
-        <para>
-            If you want to develop an application without prior installation
-            of the ADT, you still can employ the
-            <link linkend='cross-development-toolchain'>Cross Development Toolchain</link>,
-            the QEMU emulator, and a number of supported  target image files.
-            You just need to follow these general steps:
-            <orderedlist>
-                <listitem><para><emphasis>Install the cross-development
-                    toolchain for your target hardware:</emphasis>
-                    For information on how to install the toolchain, see the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
-                    section in the Yocto Project Application Developer's
-                    Guide.</para></listitem>
-                <listitem><para><emphasis>Download the Target Image:</emphasis>
-                    The Yocto Project supports several target architectures
-                    and has many pre-built kernel images and root filesystem
-                    images.</para>
-                    <para>If you are going to develop your application on
-                    hardware, go to the
-                    <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
-                    download area and choose a target machine area
-                    from which to download the kernel image and root filesystem.
-                    This download area could have several files in it that
-                    support development using actual hardware.
-                    For example, the area might contain
-                    <filename>.hddimg</filename> files that combine the
-                    kernel image with the filesystem, boot loaders, and
-                    so forth.
-                    Be sure to get the files you need for your particular
-                    development process.</para>
-                    <para>If you are going to develop your application and
-                    then run and test it using the QEMU emulator, go to the
-                    <ulink url='&YOCTO_QEMU_DL_URL;'><filename>machines/qemu</filename></ulink>
-                    download area.
-                    From this area, go down into the directory for your
-                    target architecture (e.g. <filename>qemux86_64</filename>
-                    for an <trademark class='registered'>Intel</trademark>-based
-                    64-bit architecture).
-                    Download kernel, root filesystem, and any other files you
-                    need for your process.
-                    <note>In order to use the root filesystem in QEMU, you
-                    need to extract it.
-                    See the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>"
-                    section for information on how to extract the root
-                    filesystem.</note></para></listitem>
-                <listitem><para><emphasis>Develop and Test your
-                    Application:</emphasis>  At this point, you have the tools
-                    to develop your application.
-                    If you need to separately install and use the QEMU
-                    emulator, you can go to
-                    <ulink url='http://wiki.qemu.org/Main_Page'>QEMU Home Page</ulink>
-                    to download and learn about the emulator.
-                    You can see the
-                    "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
-                    chapter for information on using QEMU within the Yocto
-                    Project.</para></listitem>
-            </orderedlist>
-        </para>
-    </section>
 </section>
 
 <section id="dev-modifying-source-code">
@@ -1719,7 +605,7 @@
                 describes this workflow.
                 If you want more information that showcases the workflow, click
                 <ulink url='https://drive.google.com/a/linaro.org/file/d/0B3KGzY5fW7laTDVxUXo3UDRvd2s/view'>here</ulink>
-                for an excellent presentation by Trevor Woerner that
+                for a presentation by Trevor Woerner that, while somewhat dated,
                 provides detailed background information and a complete
                 working tutorial.
                 </para></listitem>
@@ -1743,212 +629,647 @@
             As mentioned earlier, <filename>devtool</filename> helps
             you easily develop projects whose build output must be part of
             an image built using the OpenEmbedded build system.
-            The remainder of this section presents the workflow you would
-            use that includes <filename>devtool</filename>.
-            <footnote>
-                <para>
-                    Kudos and thanks to
-                    <ulink url='mailto:twoerner@gmail.com'>Trevor Woerner</ulink>
-                    whose
-                    "<ulink url='https://drive.google.com/file/d/0B3KGzY5fW7laTDVxUXo3UDRvd2s/view'>Yocto Project Developer Workflow Tutorial</ulink>"
-                    paper contributed nicely towards the development of this
-                    section.
-                </para>
-            </footnote>
         </para>
 
         <para>
-            The steps in this section assume you have a previously built
-            image that is already either running in QEMU or running on actual
-            hardware.
-            Also, it is assumed that for deployment of the image to the
-            target, SSH is installed in the image and if the image is running
-            on real hardware that you have network access to and from your
-            development machine.
+            Three entry points exist that allow you to develop using
+            <filename>devtool</filename>:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>devtool add</filename></emphasis>
+                    </para></listitem>
+                <listitem><para><emphasis><filename>devtool modify</filename></emphasis>
+                    </para></listitem>
+                <listitem><para><emphasis><filename>devtool upgrade</filename></emphasis>
+                    </para></listitem>
+            </itemizedlist>
         </para>
 
-        <section id='update-your-external-source'>
-            <title>Update Your External Source</title>
+        <para>
+            The remainder of this section presents these workflows.
+        </para>
+
+        <section id='use-devtool-to-integrate-new-code'>
+            <title>Use <filename>devtool add</filename> to Integrate New Code</title>
 
             <para>
-                Part of the development flow using
-                <filename>devtool</filename> of course involves updating
-                your source files.
-                Several opportunities exist in the workflow to extract and
-                work on the files.
-                For now, just realize that you need to be able to have
-                access to and edit files.
-                One obvious solution is to initially extract the code into an
-                isolated area in preparation for modification.
+                The <filename>devtool add</filename> command generates
+                a new recipe based on existing source code.
+                This command takes advantage of the
+                <link linkend='devtool-the-workspace-layer-structure'>workspace</link>
+                layer that many <filename>devtool</filename> commands
+                use.
+                The command is flexible enough to allow you to extract source
+                code into both the workspace or a separate local Git repository
+                and to use existing code that does not need to be extracted.
             </para>
 
             <para>
-                Another option is to use the
-                <filename>devtool modify</filename> command.
-                This command makes use of a "workspace" layer where much of
-                the transitional work occurs, which is needed for setting up
-                Metadata used by the OpenEmbedded build system that lets you
-                build your software.
-                Options (i.e. "-x") exist using <filename>devtool</filename>
-                that enable you to use the tool to extract source code.
+                Depending on your particular scenario, the arguments and options
+                you use with <filename>devtool add</filename> form different
+                combinations.
+                The following diagram shows common development flows
+                you would use with the <filename>devtool add</filename>
+                command:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/devtool-add-flow.png" align="center" />
+            </para>
+
+            <para>
+                <orderedlist>
+                    <listitem><para><emphasis>Generating the New Recipe</emphasis>:
+                        The top part of the flow shows three scenarios by which
+                        you could use <filename>devtool add</filename> to
+                        generate a recipe based on existing source code.</para>
+
+                        <para>In a shared development environment, it is
+                        typical where other developers are responsible for
+                        various areas of source code.
+                        As a developer, you are probably interested in using
+                        that source code as part of your development using
+                        the Yocto Project.
+                        All you need is access to the code, a recipe, and a
+                        controlled area in which to do your work.</para>
+
+                        <para>Within the diagram, three possible scenarios
+                        feed into the <filename>devtool add</filename> workflow:
+                        <itemizedlist>
+                            <listitem><para><emphasis>Left</emphasis>:
+                                The left scenario represents a common situation
+                                where the source code does not exist locally
+                                and needs to be extracted.
+                                In this situation, you just let it get
+                                extracted to the default workspace - you do not
+                                want it in some specific location outside of the
+                                workspace.
+                                Thus, everything you need will be located in the
+                                workspace:
+                                <literallayout class='monospaced'>
+     $ devtool add <replaceable>recipe fetchuri</replaceable>
+                                </literallayout>
+                                With this command, <filename>devtool</filename>
+                                creates a recipe and an append file in the
+                                workspace as well as extracts the upstream
+                                source files into a local Git repository also
+                                within the <filename>sources</filename> folder.
+                                </para></listitem>
+                            <listitem><para><emphasis>Middle</emphasis>:
+                                The middle scenario also represents a situation where
+                                the source code does not exist locally.
+                                In this case, the code is again upstream
+                                and needs to be extracted to some
+                                local area - this time outside of the default
+                                workspace.
+                                As always, if required <filename>devtool</filename> creates
+                                a Git repository locally during the extraction.
+                                Furthermore, the first positional argument
+                                <replaceable>srctree</replaceable> in this case
+                                identifies where the
+                                <filename>devtool add</filename> command
+                                will locate the extracted code outside of the
+                                workspace:
+                                <literallayout class='monospaced'>
+     $ devtool add <replaceable>recipe srctree fetchuri</replaceable>
+                                </literallayout>
+                                In summary, the source code is pulled from
+                                <replaceable>fetchuri</replaceable> and extracted
+                                into the location defined by
+                                <replaceable>srctree</replaceable> as a local
+                                Git repository.</para>
+
+                                <para>Within workspace, <filename>devtool</filename>
+                                creates both the recipe and an append file
+                                for the recipe.
+                                </para></listitem>
+                            <listitem><para><emphasis>Right</emphasis>:
+                                The right scenario represents a situation
+                                where the source tree (srctree) has been
+                                previously prepared outside of the
+                                <filename>devtool</filename> workspace.
+                                </para>
+
+                                <para>The following command names the recipe
+                                and identifies where the existing source tree
+                                is located:
+                                <literallayout class='monospaced'>
+     $ devtool add <replaceable>recipe srctree</replaceable>
+                                </literallayout>
+                                The command examines the source code and creates
+                                a recipe for it placing the recipe into the
+                                workspace.</para>
+
+                                <para>Because the extracted source code already exists,
+                                <filename>devtool</filename> does not try to
+                                relocate it into the workspace - just the new
+                                the recipe is placed in the workspace.</para>
+
+                                <para>Aside from a recipe folder, the command
+                                also creates an append folder and places an initial
+                                <filename>*.bbappend</filename> within.
+                                </para></listitem>
+                        </itemizedlist>
+                        </para></listitem>
+                    <listitem><para><emphasis>Edit the Recipe</emphasis>:
+                        At this point, you can use <filename>devtool edit-recipe</filename>
+                        to open up the editor as defined by the
+                        <filename>$EDITOR</filename> environment variable
+                        and modify the file:
+                        <literallayout class='monospaced'>
+     $ devtool edit-recipe <replaceable>recipe</replaceable>
+                        </literallayout>
+                        From within the editor, you can make modifications to the
+                        recipe that take affect when you build it later.
+                        </para></listitem>
+                    <listitem><para><emphasis>Build the Recipe or Rebuild the Image</emphasis>:
+                        At this point in the flow, the next step you
+                        take depends on what you are going to do with
+                        the new code.</para>
+                        <para>If you need to take the build output and eventually
+                        move it to the target hardware, you would use
+                        <filename>devtool build</filename>:
+                        <note>
+                            You could use <filename>bitbake</filename> to build
+                            the recipe as well.
+                        </note>
+                        <literallayout class='monospaced'>
+     $ devtool build <replaceable>recipe</replaceable>
+                        </literallayout></para>
+                        <para>On the other hand, if you want an image to
+                        contain the recipe's packages for immediate deployment
+                        onto a device (e.g. for testing purposes), you can use
+                        the <filename>devtool build-image</filename> command:
+                        <literallayout class='monospaced'>
+     $ devtool build-image <replaceable>image</replaceable>
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Deploy the Build Output</emphasis>:
+                        When you use the <filename>devtool build</filename>
+                        command to build out your recipe, you probably want to
+                        see if the resulting build output works as expected on target
+                        hardware.
+                        <note>
+                            This step assumes you have a previously built
+                            image that is already either running in QEMU or
+                            running on actual hardware.
+                            Also, it is assumed that for deployment of the image
+                            to the target, SSH is installed in the image and if
+                            the image is running on real hardware that you have
+                            network access to and from your development machine.
+                        </note>
+                        You can deploy your build output to that target hardware by
+                        using the <filename>devtool deploy-target</filename> command:
+                        <literallayout class='monospaced'>
+     $ devtool deploy-target <replaceable>recipe target</replaceable>
+                        </literallayout>
+                        The <replaceable>target</replaceable> is a live target machine
+                        running as an SSH server.</para>
+
+                        <para>You can, of course, also deploy the image you build
+                        using the <filename>devtool build-image</filename> command
+                        to actual hardware.
+                        However, <filename>devtool</filename> does not provide a
+                        specific command that allows you to do this.
+                        </para></listitem>
+                    <listitem><para><emphasis>Optionally Update the Recipe With Patch Files</emphasis>:
+                        Once you are satisfied with the recipe, if you have made
+                        any changes to the source tree that you want to have
+                        applied by the recipe, you need to generate patches
+                        from those changes.
+                        You do this before moving the recipe
+                        to its final layer and cleaning up the workspace area
+                        <filename>devtool</filename> uses.
+                        This optional step is especially relevant if you are
+                        using or adding third-party software.</para>
+                        <para>To convert commits created using Git to patch files,
+                        use the <filename>devtool update-recipe</filename> command.
+                        <note>
+                            Any changes you want to turn into patches must be
+                            committed to the Git repository in the source tree.
+                        </note>
+                        <literallayout class='monospaced'>
+     $ devtool update-recipe <replaceable>recipe</replaceable>
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Move the Recipe to its Permanent Layer</emphasis>:
+                        Before cleaning up the workspace, you need to move the
+                        final recipe to its permanent layer.
+                        You must do this before using the
+                        <filename>devtool reset</filename> command if you want to
+                        retain the recipe.
+                        </para></listitem>
+                    <listitem><para><emphasis>Reset the Recipe</emphasis>:
+                        As a final step, you can restore the state such that
+                        standard layers and the upstream source is used to build
+                        the recipe rather than data in the workspace.
+                        To reset the recipe, use the <filename>devtool reset</filename>
+                        command:
+                        <literallayout class='monospaced'>
+     $ devtool reset <replaceable>recipe</replaceable>
+                        </literallayout>
+                        </para></listitem>
+                </orderedlist>
             </para>
         </section>
 
-        <section id='use-devtool-to-integrate-your-code-with-the-image'>
-            <title>Use <filename>devtool add</filename> to Integrate Your Code with the Image</title>
+        <section id='devtool-use-devtool-modify-to-enable-work-on-code-associated-with-an-existing-recipe'>
+            <title>Use <filename>devtool modify</filename> to Enable Work on Code Associated with an Existing Recipe</title>
 
             <para>
-                The <filename>devtool add</filename> command automatically
-                generates the needed Metadata that allows the OpenEmbedded
-                build system to build your code into the image.
-                <note>
-                    If a package or packages produced by the recipe on which
-                    you are working are not already in
-                    <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
-                    for the image, you must add them.
-                    The <filename>devtool add</filename> command does not
-                    add them for you.
-                </note>
-                Use the following command form:
-                <literallayout class='monospaced'>
-     $ devtool add <replaceable>your-project-name</replaceable>&nbsp;<replaceable>path-to-source</replaceable>
-                </literallayout>
+                The <filename>devtool modify</filename> command prepares the
+                way to work on existing code that already has a recipe in
+                place.
+                The command is flexible enough to allow you to extract code,
+                specify the existing recipe, and keep track of and gather any
+                patch files from other developers that are
+                associated with the code.
             </para>
 
             <para>
-                Running <filename>devtool</filename> for the first time
-                creates a workspace layer through the
-                <filename>bblayers.conf</filename> file that
-                is based on your project's location:
-                <literallayout class='monospaced'>
-     <replaceable>path-to-source</replaceable>/<replaceable>build-directory</replaceable>/<replaceable>workspace-layer</replaceable>
-                </literallayout>
-                By default, the name of the workspace layer is "workspace".
+                Depending on your particular scenario, the arguments and options
+                you use with <filename>devtool modify</filename> form different
+                combinations.
+                The following diagram shows common development flows
+                you would use with the <filename>devtool modify</filename>
+                command:
             </para>
 
             <para>
-                For details on the workspace layer created in the
-                <replaceable>build-directory</replaceable>,
-                see the
-                "<link linkend='devtool-adding-a-new-recipe-to-the-workspace'>Adding a New Recipe to the Workspace Layer</link>"
-                section.
-            </para>
-
-<!--
-            <para>
-                Of course, each layer must have a
-                <filename>layer.conf</filename> configuration file.
-                <filename>devtool</filename> also creates this configuration
-                file:
-                <literallayout class='monospaced'>
-     $ cat workspace/conf/layer.conf
-     # ### workspace layer auto­generated by devtool ###
-     BBPATH =. "${LAYERDIR}:"
-     BBFILES += "${LAYERDIR}/recipes/*/*.bb \
-                 ${LAYERDIR}/appends/*.bbappend"
-     BBFILE_COLLECTIONS += "workspacelayer"
-     BBFILE_PATTERN_workspacelayer = "^${LAYERDIR}/"
-     BBFILE_PATTERN_IGNORE_EMPTY_workspacelayer = "1"
-     BBFILE_PRIORITY_workspacelayer = "99"
-                </literallayout>
-            </para>
--->
-
-            <para>
-                Running <filename>devtool add</filename> automatically
-                generates your recipe:
-                <literallayout class='monospaced'>
-     $ cat workspace/recipes/<replaceable>your-project-name</replaceable>/<replaceable>your-project-name</replaceable>.bb
-     # Recipe created by recipetool
-     # This is the basis of a recipe and may need further editing in order to be fully functional.
-     # (Feel free to remove these comments when editing.)
-     #
-     # Unable to find any files that looked like license statements. Check the accompanying
-     # documentation and source headers and set LICENSE and LIC_FILES_CHKSUM accordingly.
-     LICENSE = "CLOSED"
-     LIC_FILES_CHKSUM = ""
-
-     # No information for SRC_URI yet (only an external source tree was
-     # specified)
-     SRC_URI = ""
-
-     DEPENDS = "libx11"
-     # NOTE: if this software is not capable of being built in a separate build directory
-     # from the source, you should replace autotools with autotools­-brokensep in the
-     # inherit line
-     inherit autotools
-
-     # Specify any options you want to pass to the configure script using EXTRA_OECONF:
-     EXTRA_OECONF = ""
-                </literallayout>
+                <imagedata fileref="figures/devtool-modify-flow.png" align="center" />
             </para>
 
             <para>
-                Lastly, the <filename>devtool add</filename> command creates the
-                <filename>.bbappend</filename> file:
-                <literallayout class='monospaced'>
-     $ cat workspace/appends/<replaceable>your-project-name</replaceable>.bbappend
-     inherit externalsrc
-     EXTERNALSRC = "/<replaceable>path-to-source</replaceable>/<replaceable>your-project-name</replaceable>"
+                <orderedlist>
+                    <listitem><para><emphasis>Preparing to Modify the Code</emphasis>:
+                        The top part of the flow shows three scenarios by which
+                        you could use <filename>devtool modify</filename> to
+                        prepare to work on source files.
+                        Each scenario assumes the following:
+                        <itemizedlist>
+                            <listitem><para>The recipe exists in some layer external
+                                to the <filename>devtool</filename> workspace.
+                                </para></listitem>
+                            <listitem><para>The source files exist upstream in an
+                                un-extracted state or locally in a previously
+                                extracted state.
+                                </para></listitem>
+                        </itemizedlist>
+                        The typical situation is where another developer has
+                        created some layer for use with the Yocto Project and
+                        their recipe already resides in that layer.
+                        Furthermore, their source code is readily available
+                        either upstream or locally.
+                        <itemizedlist>
+                            <listitem><para><emphasis>Left</emphasis>:
+                                The left scenario represents a common situation
+                                where the source code does not exist locally
+                                and needs to be extracted.
+                                In this situation, the source is extracted
+                                into the default workspace location.
+                                The recipe, in this scenario, is in its own
+                                layer outside the workspace
+                                (i.e.
+                                <filename>meta-</filename><replaceable>layername</replaceable>).
+                                </para>
 
-     # initial_rev: <replaceable>commit-ID</replaceable>
-                </literallayout>
+                                <para>The following command identifies the recipe
+                                and by default extracts the source files:
+                                <literallayout class='monospaced'>
+     $ devtool modify <replaceable>recipe</replaceable>
+                                </literallayout>
+                                Once <filename>devtool</filename>locates the recipe,
+                                it uses the
+                                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                                variable to locate the source code and
+                                any local patch files from other developers are
+                                located.
+                                <note>
+                                    You cannot provide an URL for
+                                    <replaceable>srctree</replaceable> when using the
+                                    <filename>devtool modify</filename> command.
+                                </note>
+                                With this scenario, however, since no
+                                <replaceable>srctree</replaceable> argument exists, the
+                                <filename>devtool modify</filename> command by default
+                                extracts the source files to a Git structure.
+                                Furthermore, the location for the extracted source is the
+                                default area within the workspace.
+                                The result is that the command sets up both the source
+                                code and an append file within the workspace with the
+                                recipe remaining in its original location.
+                                </para></listitem>
+                            <listitem><para><emphasis>Middle</emphasis>:
+                                The middle scenario represents a situation where
+                                the source code also does not exist locally.
+                                In this case, the code is again upstream
+                                and needs to be extracted to some
+                                local area as a Git repository.
+                                The recipe, in this scenario, is again in its own
+                                layer outside the workspace.</para>
+
+                                <para>The following command tells
+                                <filename>devtool</filename> what recipe with
+                                which to work and, in this case, identifies a local
+                                area for the extracted source files that is outside
+                                of the default workspace:
+                                <literallayout class='monospaced'>
+     $ devtool modify <replaceable>recipe srctree</replaceable>
+                                </literallayout>
+                                As with all extractions, the command uses
+                                the recipe's <filename>SRC_URI</filename> to locate the
+                                source files.
+                                Once the files are located, the command by default
+                                extracts them.
+                                Providing the <replaceable>srctree</replaceable>
+                                argument instructs <filename>devtool</filename> where
+                                place the extracted source.</para>
+
+                                <para>Within workspace, <filename>devtool</filename>
+                                creates an append file for the recipe.
+                                The recipe remains in its original location but
+                                the source files are extracted to the location you
+                                provided with <replaceable>srctree</replaceable>.
+                                </para></listitem>
+                            <listitem><para><emphasis>Right</emphasis>:
+                                The right scenario represents a situation
+                                where the source tree
+                                (<replaceable>srctree</replaceable>) exists as a
+                                previously extracted Git structure outside of
+                                the <filename>devtool</filename> workspace.
+                                In this example, the recipe also exists
+                                elsewhere in its own layer.
+                                </para>
+
+                                <para>The following command tells
+                                <filename>devtool</filename> the recipe
+                                with which to work, uses the "-n" option to indicate
+                                source does not need to be extracted, and uses
+                                <replaceable>srctree</replaceable> to point to the
+                                previously extracted source files:
+                                <literallayout class='monospaced'>
+     $ devtool modify -n <replaceable>recipe srctree</replaceable>
+                                </literallayout>
+                                </para>
+
+                                <para>Once the command finishes, it creates only
+                                an append file for the recipe in the workspace.
+                                The recipe and the source code remain in their
+                                original locations.
+                                </para></listitem>
+                            </itemizedlist>
+                        </para></listitem>
+                    <listitem><para><emphasis>Edit the Source</emphasis>:
+                        Once you have used the <filename>devtool modify</filename>
+                        command, you are free to make changes to the source
+                        files.
+                        You can use any editor you like to make and save
+                        your source code modifications.
+                        </para></listitem>
+                    <listitem><para><emphasis>Build the Recipe</emphasis>:
+                        Once you have updated the source files, you can build
+                        the recipe.
+                        You can either use <filename>devtool build</filename> or
+                        <filename>bitbake</filename>.
+                        Either method produces build output that is stored
+                        in
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>.
+                        </para></listitem>
+                    <listitem><para><emphasis>Deploy the Build Output</emphasis>:
+                        When you use the <filename>devtool build</filename>
+                        command or <filename>bitbake</filename> to build out your
+                        recipe, you probably want to see if the resulting build
+                        output works as expected on target hardware.
+                        <note>
+                            This step assumes you have a previously built
+                            image that is already either running in QEMU or
+                            running on actual hardware.
+                            Also, it is assumed that for deployment of the image
+                            to the target, SSH is installed in the image and if
+                            the image is running on real hardware that you have
+                            network access to and from your development machine.
+                        </note>
+                        You can deploy your build output to that target hardware by
+                        using the <filename>devtool deploy-target</filename> command:
+                        <literallayout class='monospaced'>
+     $ devtool deploy-target <replaceable>recipe target</replaceable>
+                        </literallayout>
+                        The <replaceable>target</replaceable> is a live target machine
+                        running as an SSH server.</para>
+
+                        <para>You can, of course, also deploy the image you build
+                        using the <filename>devtool build-image</filename> command
+                        to actual hardware.
+                        However, <filename>devtool</filename> does not provide a
+                        specific command that allows you to do this.
+                        </para></listitem>
+                    <listitem><para><emphasis>Optionally Create Patch Files for Your Changes</emphasis>:
+                        After you have debugged your changes, you can
+                        use <filename>devtool update-recipe</filename> to
+                        generate patch files for all the commits you have
+                        made.
+                        <note>
+                            Patch files are generated only for changes
+                            you have committed.
+                        </note>
+                        <literallayout class='monospaced'>
+     $ devtool update-recipe <replaceable>recipe</replaceable>
+                        </literallayout>
+                        By default, the
+                        <filename>devtool update-recipe</filename> command
+                        creates the patch files in a folder named the same
+                        as the recipe beneath the folder in which the recipe
+                        resides, and updates the recipe's
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                        statement to point to the generated patch files.
+                        <note>
+                            You can use the
+                            "--append <replaceable>LAYERDIR</replaceable>"
+                            option to cause the command to create append files
+                            in a specific layer rather than the default
+                            recipe layer.
+                        </note>
+                        </para></listitem>
+                    <listitem><para><emphasis>Restore the Workspace</emphasis>:
+                        The <filename>devtool reset</filename> restores the
+                        state so that standard layers and upstream sources are
+                        used to build the recipe rather than what is in the
+                        workspace.
+                        <literallayout class='monospaced'>
+     $ devtool reset <replaceable>recipe</replaceable>
+                        </literallayout>
+                        </para></listitem>
+                </orderedlist>
             </para>
         </section>
 
-        <section id='build-your-project'>
-            <title>Build Your Project</title>
+        <section id='devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software'>
+            <title>Use <filename>devtool upgrade</filename> to Create a Version of the Recipe that Supports a Newer Version of the Software</title>
 
             <para>
-                You can use BitBake or <filename>devtool build</filename> to
-                build your modified project.
+                The <filename>devtool upgrade</filename> command updates
+                an existing recipe so that you can build it for an updated
+                set of source files.
+                The command is flexible enough to allow you to specify
+                source code revision and versioning schemes, extract code into
+                or out of the <filename>devtool</filename> workspace, and
+                work with any source file forms that the fetchers support.
             </para>
 
             <para>
-                To use BitBake, use the following:
-                <literallayout class='monospaced'>
-     $ bitbake <replaceable>your-project-name</replaceable>
-                </literallayout>
-                Alternatively, you can use
-                <filename>devtool build</filename>, which is equivalent to
-                <filename>bitbake -c populate_sysroot</filename>.
-                For example:
-                <literallayout class='monospaced'>
-     $ devtool build <replaceable>your-project-name</replaceable>
-                </literallayout>
+                Depending on your particular scenario, the arguments and options
+                you use with <filename>devtool upgrade</filename> form different
+                combinations.
+                The following diagram shows a common development flow
+                you would use with the <filename>devtool modify</filename>
+                command:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/devtool-upgrade-flow.png" align="center" />
+            </para>
+
+            <para>
+                <orderedlist>
+                    <listitem><para><emphasis>Initiate the Upgrade</emphasis>:
+                        The top part of the flow shows a typical scenario by which
+                        you could use <filename>devtool upgrade</filename>.
+                        The following conditions exist:
+                        <itemizedlist>
+                            <listitem><para>The recipe exists in some layer external
+                                to the <filename>devtool</filename> workspace.
+                                </para></listitem>
+                            <listitem><para>The source files for the new release
+                                exist adjacent to the same location pointed to by
+                                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                                in the recipe (e.g. a tarball with the new version
+                                number in the name, or as a different revision in
+                                the upstream Git repository).
+                                </para></listitem>
+                        </itemizedlist>
+                        A common situation is where third-party software has
+                        undergone a revision so that it has been upgraded.
+                        The recipe you have access to is likely in your own layer.
+                        Thus, you need to upgrade the recipe to use the
+                        newer version of the software:
+                        <literallayout class='monospaced'>
+     $ devtool upgrade -V <replaceable>version recipe</replaceable>
+                        </literallayout>
+                        By default, the <filename>devtool upgrade</filename> command
+                        extracts source code into the <filename>sources</filename>
+                        directory in the workspace.
+                        If you want the code extracted to any other location, you
+                        need to provide the <replaceable>srctree</replaceable>
+                        positional argument with the command as follows:
+                        <literallayout class='monospaced'>
+     $ devtool upgrade -V <replaceable>version recipe srctree</replaceable>
+                        </literallayout>
+                        Also, in this example, the "-V" option is used to specify
+                        the new version.
+                        If the source files pointed to by the
+                        <filename>SRC_URI</filename> statement in the recipe are
+                        in a Git repository, you must provide the "-S" option and
+                        specify a revision for the software.</para>
+
+                        <para>Once <filename>devtool</filename> locates the recipe,
+                        it uses the <filename>SRC_URI</filename> variable to locate
+                        the source code and any local patch files from other
+                        developers are located.
+                        The result is that the command sets up the source
+                        code, the new version of the recipe, and an append file
+                        all within the workspace.
+                        </para></listitem>
+                    <listitem><para><emphasis>Resolve any Conflicts created by the Upgrade</emphasis>:
+                        At this point, there could be some conflicts due to the
+                        software being upgraded to a new version.
+                        This would occur if your recipe specifies some patch files in
+                        <filename>SRC_URI</filename> that conflict with changes
+                        made in the new version of the software.
+                        If this is the case, you need to resolve the conflicts
+                        by editing the source and following the normal
+                        <filename>git rebase</filename> conflict resolution
+                        process.</para>
+
+                        <para>Before moving onto the next step, be sure to resolve any
+                        such conflicts created through use of a newer or different
+                        version of the software.
+                        </para></listitem>
+                    <listitem><para><emphasis>Build the Recipe</emphasis>:
+                        Once you have your recipe in order, you can build it.
+                        You can either use <filename>devtool build</filename> or
+                        <filename>bitbake</filename>.
+                        Either method produces build output that is stored
+                        in
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>.
+                        </para></listitem>
+                    <listitem><para><emphasis>Deploy the Build Output</emphasis>:
+                        When you use the <filename>devtool build</filename>
+                        command or <filename>bitbake</filename> to build out your
+                        recipe, you probably want to see if the resulting build
+                        output works as expected on target hardware.
+                        <note>
+                            This step assumes you have a previously built
+                            image that is already either running in QEMU or
+                            running on actual hardware.
+                            Also, it is assumed that for deployment of the image
+                            to the target, SSH is installed in the image and if
+                            the image is running on real hardware that you have
+                            network access to and from your development machine.
+                        </note>
+                        You can deploy your build output to that target hardware by
+                        using the <filename>devtool deploy-target</filename> command:
+                        <literallayout class='monospaced'>
+     $ devtool deploy-target <replaceable>recipe target</replaceable>
+                        </literallayout>
+                        The <replaceable>target</replaceable> is a live target machine
+                        running as an SSH server.</para>
+
+                        <para>You can, of course, also deploy the image you build
+                        using the <filename>devtool build-image</filename> command
+                        to actual hardware.
+                        However, <filename>devtool</filename> does not provide a
+                        specific command that allows you to do this.
+                        </para></listitem>
+                    <listitem><para><emphasis>Optionally Create Patch Files for Your Changes</emphasis>:
+                        After you have debugged your changes, you can
+                        use <filename>devtool update-recipe</filename> to
+                        generate patch files for all the commits you have
+                        made.
+                        <note>
+                            Patch files are generated only for changes
+                            you have committed.
+                        </note>
+                        <literallayout class='monospaced'>
+     $ devtool update-recipe <replaceable>recipe</replaceable>
+                        </literallayout>
+                        By default, the
+                        <filename>devtool update-recipe</filename> command
+                        creates the patch files in a folder named the same
+                        as the recipe beneath the folder in which the recipe
+                        resides, and updates the recipe's
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                        statement to point to the generated patch files.
+                        </para></listitem>
+                    <listitem><para><emphasis>Move the Recipe to its Permanent Layer</emphasis>:
+                        Before cleaning up the workspace, you need to move the
+                        final recipe to its permanent layer.
+                        You can either overwrite the original recipe or you can
+                        overlay the upgraded recipe into a separate layer.
+                        You must do this before using the
+                        <filename>devtool reset</filename> command if you want to
+                        retain the upgraded recipe.
+                        </para></listitem>
+                    <listitem><para><emphasis>Restore the Workspace</emphasis>:
+                        The <filename>devtool reset</filename> restores the
+                        state so that standard layers and upstream sources are
+                        used to build the recipe rather than what is in the
+                        workspace.
+                        <literallayout class='monospaced'>
+     $ devtool reset <replaceable>recipe</replaceable>
+                        </literallayout>
+                        </para></listitem>
+                </orderedlist>
             </para>
         </section>
-
-<!--
-        <section id='dev-build-the-image'>
-            <title>Build the Image</title>
-
-            <para>
-                The final step before testing is to rebuild the base image
-                with your project changes as part of the image.
-                Simply run BitBake again on your image.
-                Here is an example:
-                <literallayout class='monospaced'>
-     $ bitbake <replaceable>image</replaceable>
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='dev-testing-the-image'>
-            <title>Testing the Image</title>
-
-            <para>
-                Once you have the image, you can test it using QEMU.
-                Here is an example assuming "qemux86":
-                <literallayout class='monospaced'>
-     $ runqemu qemux86 <replaceable>image</replaceable>
-                </literallayout>
-                For information on how to test an image using QEMU, see the
-                "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
-                section.
-            </para>
-        </section>
--->
     </section>
 
     <section id='devtool-quick-reference'>
@@ -1959,7 +1280,7 @@
             adding a new recipe and the supporting Metadata to a temporary
             workspace layer.
             This section provides a short reference on
-            <filename>devtool</filename> for most of the commands.
+            <filename>devtool</filename> and its commands.
         </para>
 
         <section id='devtool-getting-help'>
@@ -1970,32 +1291,43 @@
                 <filename>devtool</filename> command is using the
                 <filename>--help</filename> option:
                 <literallayout class='monospaced'>
-     $ devtool --help
-     usage: devtool [-h] [--basepath BASEPATH] [-d] [-q] [--color COLOR]
-               &lt;subcommand&gt; ...
+     usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]
+                    [--color COLOR] [-h]
+                    &lt;subcommand&gt; ...
 
      OpenEmbedded development tool
 
      optional arguments:
-       -h, --help           show this help message and exit
        --basepath BASEPATH  Base directory of SDK / build directory
+       --bbpath BBPATH      Explicitly specify the BBPATH, rather than getting it
+                            from the metadata
        -d, --debug          Enable debug output
        -q, --quiet          Print only errors
        --color COLOR        Colorize output (where COLOR is auto, always, never)
+       -h, --help           show this help message and exit
 
      subcommands:
-       &lt;subcommand&gt;
-         create-workspace   Set up a workspace
-         deploy-target      Deploy recipe output files to live target machine
-         undeploy-target    Undeploy recipe output files in live target machine
-         add                Add a new recipe
-         modify             Modify the source for an existing recipe
-         extract            Extract the source for an existing recipe
-         update-recipe      Apply changes from external source tree to recipe
-         status             Show workspace status
-         build              Build a recipe
-         reset              Remove a recipe from your workspace
-
+       Beginning work on a recipe:
+         add                  Add a new recipe
+         modify               Modify the source for an existing recipe
+         upgrade              Upgrade an existing recipe
+       Getting information:
+         status               Show workspace status
+         search               Search available recipes
+       Working on a recipe in the workspace:
+         build                Build a recipe
+         edit-recipe          Edit a recipe file in your workspace
+         configure-help       Get help on configure script options
+         update-recipe        Apply changes from external source tree to recipe
+         reset                Remove a recipe from your workspace
+       Testing changes on target:
+         deploy-target        Deploy recipe output files to live target machine
+         undeploy-target      Undeploy recipe output files in live target machine
+         build-image          Build image including workspace recipe packages
+       Advanced:
+         create-workspace     Set up workspace in an alternative location
+         extract              Extract the source for an existing recipe
+         sync                 Synchronize the source tree for an existing recipe
      Use devtool &lt;subcommand&gt; --help to get help on a specific command
                 </literallayout>
             </para>
@@ -2006,22 +1338,95 @@
                 name and using <filename>--help</filename>:
                 <literallayout class='monospaced'>
      $ devtool add --help
-     usage: devtool add [-h] [--same-dir] [--fetch URI] [--version VERSION]
-                        recipename srctree
+     usage: devtool add [-h] [--same-dir | --no-same-dir] [--fetch URI]
+                        [--version VERSION] [--no-git] [--binary] [--also-native]
+                        [--src-subdir SUBDIR]
+                        [recipename] [srctree] [fetchuri]
 
-     Adds a new recipe
+     Adds a new recipe to the workspace to build a specified source tree. Can
+     optionally fetch a remote URI and unpack it to create the source tree.
 
      positional arguments:
-       recipename            Name for new recipe to add
-       srctree               Path to external source tree
+       recipename            Name for new recipe to add (just name - no version,
+                             path or extension). If not specified, will attempt to
+                             auto-detect it.
+       srctree               Path to external source tree. If not specified, a
+                             subdirectory of
+                             /home/scottrif/poky/build/workspace/sources will be
+                             used.
+       fetchuri              Fetch the specified URI and extract it to create the
+                             source tree
 
      optional arguments:
        -h, --help            show this help message and exit
        --same-dir, -s        Build in same directory as source
+       --no-same-dir         Force build in a separate build directory
        --fetch URI, -f URI   Fetch the specified URI and extract it to create the
-                             source tree
+                             source tree (deprecated - pass as positional argument
+                             instead)
        --version VERSION, -V VERSION
                              Version to use within recipe (PV)
+       --no-git, -g          If fetching source, do not set up source tree as a git
+                             repository
+       --binary, -b          Treat the source tree as something that should be
+                             installed verbatim (no compilation, same directory
+                             structure). Useful with binary packages e.g. RPMs.
+       --also-native         Also add native variant (i.e. support building recipe
+                             for the build host as well as the target machine)
+       --src-subdir SUBDIR   Specify subdirectory within source tree to use
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='devtool-the-workspace-layer-structure'>
+            <title>The Workspace Layer Structure</title>
+
+            <para>
+                <filename>devtool</filename> uses a "Workspace" layer
+                in which to accomplish builds.
+                This layer is not specific to any single
+                <filename>devtool</filename> command but is rather a common
+                working area used across the tool.
+            </para>
+
+            <para>
+                The following figure shows the workspace structure:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/build-workspace-directory.png"
+                    width="6in" depth="5in" align="left" scale="70" />
+            </para>
+
+            <para>
+                <literallayout class='monospaced'>
+     attic - A directory created if devtool believes it preserve
+             anything when you run "devtool reset".  For example, if you
+             run "devtool add", make changes to the recipe, and then
+             run "devtool reset", devtool takes notice that the file has
+             been changed and moves it into the attic should you still
+             want the recipe.
+
+     README - Provides information on what is in workspace layer and how to
+              manage it.
+
+     .devtool_md5 - A checksum file used by devtool.
+
+     appends - A directory that contains *.bbappend files, which point to
+               external source.
+
+     conf - A configuration directory that contains the layer.conf file.
+
+     recipes - A directory containing recipes.  This directory contains a
+               folder for each directory added whose name matches that of the
+               added recipe.  devtool places the <replaceable>recipe</replaceable>.bb file
+               within that sub-directory.
+
+     sources - A directory containing a working copy of the source files used
+               when building the recipe.  This is the default directory used
+               as the location of the source tree when you do not provide a
+               source tree path.  This directory contains a folder for each
+               set of source files matched to a corresponding recipe.
                 </literallayout>
             </para>
         </section>
@@ -2040,54 +1445,72 @@
 
             <para>
                 The following example creates and adds a new recipe named
-                <filename>jackson</filename> to the workspace layer.
+                <filename>jackson</filename> to a workspace layer the tool creates.
                 The source code built by the recipes resides in
                 <filename>/home/scottrif/sources/jackson</filename>:
                 <literallayout class='monospaced'>
      $ devtool add jackson /home/scottrif/sources/jackson
                 </literallayout>
-                <note>
-                    For complete syntax, use the
-                    <filename>devtool add --help</filename> command.
-                </note>
             </para>
 
             <para>
                 If you add a recipe and the workspace layer does not exist,
-                the command creates the layer and populates it as follows:
-            </para>
-
-            <para>
-                <imagedata fileref="figures/build-workspace-directory.png"
-                    width="6in" depth="4in" align="center" scale="100" />
-            </para>
-
-            <para>
-                <literallayout class='monospaced'>
-     README - Provides information on what is in workspace layer and how to
-              manage it.
-
-     appends - A directory that contains *.bbappend files, which point to
-               external source.
-
-     conf - A configuration directory that contains the layer.conf file.
-
-     recipes - A directory containing recipes.  This directory contains a
-               folder for each directory added whose name matches that of the
-               added recipe.  devtool places the <replaceable>recipe</replaceable>.bb file
-               within that sub-directory.
-                </literallayout>
+                the command creates the layer and populates it as
+                described in
+                "<link linkend='devtool-the-workspace-layer-structure'>The Workspace Layer Structure</link>"
+                section.
             </para>
 
             <para>
                 Running <filename>devtool add</filename> when the
-                workspace layer exists causes the tool to add the recipe
-                and append files into the existing workspace layer.
+                workspace layer exists causes the tool to add the recipe,
+                append files, and source files into the existing workspace layer.
                 The <filename>.bbappend</filename> file is created to point
                 to the external source tree.
             </para>
         </section>
 
+        <section id='devtool-extracting-the-source-for-an-existing-recipe'>
+            <title>Extracting the Source for an Existing Recipe</title>
+
+            <para>
+                Use the <filename>devtool extract</filename> command to
+                extract the source for an existing recipe.
+                When you use this command, you must supply the root name
+                of the recipe (i.e. no version, paths, or extensions), and
+                you must supply the directory to which you want the source
+                extracted.
+            </para>
+
+            <para>
+                Additional command options let you control the name of a
+                development branch into which you can checkout the source
+                and whether or not to keep a temporary directory, which is
+                useful for debugging.
+            </para>
+        </section>
+
+        <section id='devtool-synchronizing-a-recipes-extracted-source-tree'>
+            <title>Synchronizing a Recipe's Extracted Source Tree</title>
+
+            <para>
+                Use the <filename>devtool sync</filename> command to
+                synchronize a previously extracted source tree for an
+                existing recipe.
+                When you use this command, you must supply the root name
+                of the recipe (i.e. no version, paths, or extensions), and
+                you must supply the directory to which you want the source
+                extracted.
+            </para>
+
+            <para>
+                Additional command options let you control the name of a
+                development branch into which you can checkout the source
+                and whether or not to keep a temporary directory, which is
+                useful for debugging.
+            </para>
+        </section>
+
         <section id='devtool-modifying-a-recipe'>
             <title>Modifying an Existing Recipe</title>
 
@@ -2110,14 +1533,37 @@
                 You can use the following command to checkout the source
                 files:
                 <literallayout class='monospaced'>
-     $ devtool modify -x <replaceable>recipe</replaceable>&nbsp;<replaceable>path-to-source</replaceable>
+     $ devtool modify <replaceable>recipe</replaceable>
                 </literallayout>
-                Using the above command form, the default development branch
-                would be "devtool".
-                <note>
-                    For complete syntax, use the
-                    <filename>devtool modify --help</filename> command.
-                </note>
+                Using the above command form, <filename>devtool</filename> uses
+                the existing recipe's
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                statement to locate the upstream source, extracts the source
+                into the default sources location in the workspace.
+                The default development branch used is "devtool".
+            </para>
+        </section>
+
+        <section id='devtool-edit-an-existing-recipe'>
+            <title>Edit an Existing Recipe</title>
+
+            <para>
+                Use the <filename>devtool edit-recipe</filename> command
+                to run the default editor, which is identified using the
+                <filename>EDITOR</filename> variable, on the specified recipe.
+            </para>
+
+            <para>
+                When you use the <filename>devtool edit-recipe</filename>
+                command, you must supply the root name of the recipe
+                (i.e. no version, paths, or extensions).
+                Also, the recipe file itself must reside in the workspace
+                as a result of the <filename>devtool add</filename> or
+                <filename>devtool upgrade</filename> commands.
+                However, you can override that requirement by using the
+                "-a" or "--any-recipe" option.
+                Using either of these options allows you to edit any recipe
+                regardless of its location.
             </para>
         </section>
 
@@ -2167,10 +1613,32 @@
                  file.
                  If an append file already exists, the command updates it
                  appropriately.
-                <note>
-                    For complete syntax, use the
-                    <filename>devtool update-recipe --help</filename> command.
-                </note>
+            </para>
+        </section>
+
+        <section id='devtool-upgrading-a-recipe'>
+            <title>Upgrading a Recipe</title>
+
+            <para>
+                Use the <filename>devtool upgrade</filename> command
+                to upgrade an existing recipe to a new upstream version.
+                The command puts the upgraded recipe file into the
+                workspace along with any associated files, and extracts
+                the source tree to a specified location should patches
+                need rebased or added to as a result of the upgrade.
+            </para>
+
+            <para>
+                When you use the <filename>devtool upgrade</filename> command,
+                you must supply the root name of the recipe (i.e. no version,
+                paths, or extensions), and you must supply the directory
+                to which you want the source extracted.
+                Additional command options let you control things such as
+                the version number to which you want to upgrade (i.e. the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>),
+                the source revision to which you want to upgrade (i.e. the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>,
+                whether or not to apply patches, and so forth.
             </para>
         </section>
 
@@ -2195,32 +1663,64 @@
                 the recipe or the append files have been modified, the
                 command preserves the modified files in a separate "attic"
                 subdirectory under the workspace layer.
-                <note>
-                    For complete syntax, use the
-                    <filename>devtool reset --help</filename> command.
-                </note>
+            </para>
+
+            <para>
+                Here is an example that resets the workspace directory that
+                contains the <filename>mtr</filename> recipe:
+                <literallayout class='monospaced'>
+     $ devtool reset mtr
+     NOTE: Cleaning sysroot for recipe mtr...
+     NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/mtr as-is; if you no
+        longer need it then please delete it manually
+     $
+                </literallayout>
             </para>
         </section>
 
-        <section id='devtool-building-your-software'>
-            <title>Building Your Software</title>
+        <section id='devtool-building-your-recipe'>
+            <title>Building Your Recipe</title>
 
             <para>
                 Use the <filename>devtool build</filename> command to cause the
-                OpenEmbedded build system to build your software based
-                on the recipe file.
+                OpenEmbedded build system to build your recipe.
                 The <filename>devtool build</filename> command is equivalent to
                 <filename>bitbake -c populate_sysroot</filename>.
+            </para>
+
+            <para>
+                When you use the <filename>devtool build</filename> command,
+                you must supply the root name of the recipe (i.e. no version,
+                paths, or extensions).
+                You can use either the "-s" or the "--disable-parallel-make"
+                option to disable parallel makes during the build.
                 Here is an example:
                 <literallayout class='monospaced'>
      $ devtool build <replaceable>recipe</replaceable>
                 </literallayout>
-                <note>
-                    For complete syntax, use the
-                    <filename>devtool build --help</filename> command.
-                </note>
-                Building your software using <filename>devtool build</filename>
-                is identical to using BitBake to build the software.
+            </para>
+        </section>
+
+        <section id='devtool-building-your-image'>
+            <title>Building Your Image</title>
+
+            <para>
+                Use the <filename>devtool build-image</filename> command
+                to build an image, extending it to include packages from
+                recipes in the workspace.
+                Using this command is useful when you want an image that
+                ready for immediate deployment onto a device for testing.
+                For proper integration into a final image, you need to
+                edit your custom image recipe appropriately.
+            </para>
+
+            <para>
+                When you use the <filename>devtool build-image</filename>
+                command, you must supply the name of the image.
+                This command has no command line options:
+                <literallayout class='monospaced'>
+     $ devtool build-image <replaceable>image</replaceable>
+                </literallayout>
             </para>
         </section>
 
@@ -2252,12 +1752,6 @@
                         You should never use it to update an image that will be
                         used in production.
                     </para>
-
-                    <para>
-                        For complete syntax, use the
-                        <filename>devtool deploy-target --help</filename>
-                        command.
-                    </para>
                 </note>
             </para>
         </section>
@@ -2278,10 +1772,6 @@
                 The <replaceable>target</replaceable> is the address of the
                 target machine, which must be running an SSH server (i.e.
                 <filename>user@hostname</filename>).
-                <note>
-                    For complete syntax, use the
-                    <filename>devtool undeploy-target --help</filename> command.
-                </note>
             </para>
         </section>
 
@@ -2304,10 +1794,6 @@
                 <literallayout class='monospaced'>
      $ devtool create-workspace
                 </literallayout>
-                <note>
-                    For complete syntax, use the
-                    <filename>devtool create-workspace --help</filename> command.
-                </note>
             </para>
 
             <para>
@@ -2320,6 +1806,54 @@
                 </literallayout>
             </para>
         </section>
+
+        <section id='devtool-get-the-status-of-the-recipes-in-your-workspace'>
+            <title>Get the Status of the Recipes in Your Workspace</title>
+
+            <para>
+                Use the <filename>devtool status</filename> command to
+                list the recipes currently in your workspace.
+                Information includes the paths to their respective
+                external source trees.
+            </para>
+
+            <para>
+                The <filename>devtool status</filename> command has no
+                command-line options:
+                <literallayout class='monospaced'>
+     devtool status
+                </literallayout>
+                Following is sample output after using
+                <link linkend='devtool-adding-a-new-recipe-to-the-workspace'><filename>devtool add</filename></link>
+                to create and add the <filename>mtr_0.86.bb</filename> recipe
+                to the <filename>workspace</filename> directory:
+                <literallayout class='monospaced'>
+     $ devtool status
+     mtr: /home/scottrif/poky/build/workspace/sources/mtr (/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb)
+     $
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='devtool-search-for-available-target-recipes'>
+            <title>Search for Available Target Recipes</title>
+
+            <para>
+                Use the <filename>devtool search</filename> command to
+                search for available target recipes.
+                The command matches the recipe name, package name,
+                description, and installed files.
+                The command displays the recipe name as a result of a
+                match.
+            </para>
+
+            <para>
+                When you use the <filename>devtool search</filename> command,
+                you must supply a <replaceable>keyword</replaceable>.
+                The command uses the <replaceable>keyword</replaceable> when
+                searching for a match.
+            </para>
+        </section>
     </section>
 
     <section id="using-a-quilt-workflow">
@@ -2541,56 +2075,19 @@
     </para>
 </section>
 
-<section id='image-development-using-hob'>
-    <title>Image Development Using Hob</title>
-
-    <para>
-        The <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> is a graphical user interface for the
-        OpenEmbedded build system, which is based on BitBake.
-        You can use the Hob to build custom operating system images within the Yocto Project build environment.
-        Hob simply provides a friendly interface over the build system used during development.
-        In other words, building images with the Hob lets you take care of common build tasks more easily.
-    </para>
-
-    <para>
-        For a better understanding of Hob, see the project page at
-        <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'></ulink>
-        on the Yocto Project website.
-        If you follow the "Documentation" link from the Hob page, you will
-        find a short introductory training video on Hob.
-        The following lists some features of Hob:
-        <itemizedlist>
-            <listitem><para>You can setup and run Hob using these commands:
-            <literallayout class='monospaced'>
-     $ source oe-init-build-env
-     $ hob
-            </literallayout></para></listitem>
-            <listitem><para>You can set the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                for which you are building the image.</para></listitem>
-            <listitem><para>You can modify various policy settings such as the
-                package format with which to build,
-                the parallelism BitBake uses, whether or not to build an
-                external toolchain, and which host to build against.
-                </para></listitem>
-            <listitem><para>You can manage
-                <link linkend='understanding-and-creating-layers'>layers</link>.</para></listitem>
-            <listitem><para>You can select a base image and then add extra packages for your custom build.
-                </para></listitem>
-            <listitem><para>You can launch and monitor the build from within Hob.</para></listitem>
-        </itemizedlist>
-    </para>
-</section>
-
 <section id="platdev-appdev-devshell">
     <title>Using a Development Shell</title>
 
     <para>
         When debugging certain commands or even when just editing packages,
         <filename>devshell</filename> can be a useful tool.
-        When you invoke <filename>devshell</filename>, source files are
-        extracted into your working directory and patches are applied.
-        Then, a new terminal is opened and you are placed in the working directory.
+        When you invoke <filename>devshell</filename>, all tasks up to and
+        including
+        <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-patch'><filename>do_patch</filename></ulink>
+        are run for the specified target.
+        Then, a new terminal is opened and you are placed in
+        <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink><filename>}</filename>,
+        the source directory.
         In the new terminal, all the OpenEmbedded build-related environment variables are
         still defined so you can use commands such as <filename>configure</filename> and
         <filename>make</filename>.
@@ -2634,24 +2131,64 @@
     </para>
 
     <para>
-        When you are finished, you just exit the shell or close the terminal window.
+        To manually run a specific task using <filename>devshell</filename>,
+        run the corresponding <filename>run.*</filename> script in
+        the
+        <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}/temp</filename>
+        directory (e.g.,
+        <filename>run.do_configure.</filename><replaceable>pid</replaceable>).
+        If a task's script does not exist, which would be the case if the task was
+        skipped by way of the sstate cache, you can create the task by first running
+        it outside of the <filename>devshell</filename>:
+        <literallayout class='monospaced'>
+     $ bitbake -c <replaceable>task</replaceable>
+        </literallayout>
+        <note><title>Notes</title>
+            <itemizedlist>
+                <listitem><para>Execution of a task's <filename>run.*</filename>
+                    script and BitBake's execution of a task are identical.
+                    In other words, running the script re-runs the task
+                    just as it would be run using the
+                    <filename>bitbake -c</filename> command.
+                    </para></listitem>
+                <listitem><para>Any <filename>run.*</filename> file that does not
+                    have a <filename>.pid</filename> extension is a
+                    symbolic link (symlink) to the most recent version of that
+                    file.
+                    </para></listitem>
+            </itemizedlist>
+        </note>
     </para>
 
-    <note>
-        <para>
-            It is worth remembering that when using <filename>devshell</filename>
-            you need to use the full compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename>
-            instead of just using <filename>gcc</filename>.
-            The same applies to other applications such as <filename>binutils</filename>,
-            <filename>libtool</filename> and so forth.
-            BitBake sets up environment variables such as <filename>CC</filename>
-            to assist applications, such as <filename>make</filename> to find the correct tools.
-        </para>
+    <para>
+        Remember, that the <filename>devshell</filename> is a mechanism that allows
+        you to get into the BitBake task execution environment.
+        And as such, all commands must be called just as BitBake would call them.
+        That means you need to provide the appropriate options for
+        cross-compilation and so forth as applicable.
+    </para>
 
-        <para>
-            It is also worth noting that <filename>devshell</filename> still works over
-            X11 forwarding and similar situations.
-        </para>
+    <para>
+        When you are finished using <filename>devshell</filename>, exit the shell
+        or close the terminal window.
+    </para>
+
+    <note><title>Notes</title>
+        <itemizedlist>
+            <listitem><para>
+                It is worth remembering that when using <filename>devshell</filename>
+                you need to use the full compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename>
+                instead of just using <filename>gcc</filename>.
+                The same applies to other applications such as <filename>binutils</filename>,
+                <filename>libtool</filename> and so forth.
+                BitBake sets up environment variables such as <filename>CC</filename>
+                to assist applications, such as <filename>make</filename> to find the correct tools.
+                </para></listitem>
+            <listitem><para>
+                It is also worth noting that <filename>devshell</filename> still works over
+                X11 forwarding and similar situations.
+                </para></listitem>
+        </itemizedlist>
     </note>
 </section>
 

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

diff --git a/yocto-poky/documentation/dev-manual/dev-manual-newbie.xml b/yocto-poky/documentation/dev-manual/dev-manual-newbie.xml
index 70fa969..75c992f 100644
--- a/yocto-poky/documentation/dev-manual/dev-manual-newbie.xml
+++ b/yocto-poky/documentation/dev-manual/dev-manual-newbie.xml
@@ -96,7 +96,10 @@
             <para>
                 For developers who mainly do application level work
                 on top of an existing software stack,
-                here are some practices that work best:
+                the following list shows practices that work best.
+                For information on using a Software Development Kit (SDK), see
+                the
+                <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>:
                 <itemizedlist>
                     <listitem><para>Use a pre-built toolchain that
                         contains the software stack itself.
@@ -106,12 +109,9 @@
                         isolated applications.</para></listitem>
                     <listitem><para>When possible, use the Yocto Project
                         plug-in for the <trademark class='trade'>Eclipse</trademark> IDE
-                        and other pieces of Application Development
-                        Technology (ADT).
+                        and SDK development practices.
                         For more information, see the
-                        "<link linkend='application-development-workflow'>Application
-                        Development Workflow</link>" section as well as the
-                        <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
+                        "<ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>".
                         </para></listitem>
                     <listitem><para>Keep your cross-development toolchains
                         updated.
@@ -603,7 +603,7 @@
                 the
                 <link linkend='build-directory'>Build Directory</link>
                 contains user-defined variables that affect every build.
-                The <filename>meta-yocto/conf/distro/poky.conf</filename>
+                The <filename>meta-poky/conf/distro/poky.conf</filename>
                 configuration file defines Yocto "distro" configuration
                 variables used only when building with this policy.
                 Machine configuration files, which
@@ -636,8 +636,6 @@
                         <listitem><para>A relocatable toolchain used outside of
                             BitBake by developers when developing applications
                             that will run on a targeted device.
-                            Sometimes this relocatable cross-development
-                            toolchain is referred to as the meta-toolchain.
                             </para></listitem>
                     </itemizedlist>
                 </para>
@@ -650,8 +648,7 @@
                     section in the Yocto Project Reference Manual.
                     You can also find more information on using the
                     relocatable toolchain in the
-                    <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project
-                    Application Developer's Guide</ulink>.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
                 </para></listitem>
             <listitem><para><emphasis>Image:</emphasis>
                 An image is an artifact of the BitBake build process given
@@ -667,10 +664,6 @@
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
                 section in the Yocto Project Board Support Packages (BSP)
                 Developer's Guide.</para></listitem>
-            <listitem><para id='meta-toolchain'><emphasis>Meta-Toolchain:</emphasis>
-                A term sometimes used for
-                <link linkend='cross-development-toolchain'>Cross-Development Toolchain</link>.
-                </para></listitem>
             <listitem><para id='metadata'><emphasis>Metadata:</emphasis>
                 The files that BitBake parses when building an image.
                 In general, Metadata includes recipes, classes, and
@@ -983,7 +976,7 @@
             Git uses "branches" to organize different development efforts.
             For example, the <filename>poky</filename> repository has
             several branches that include the current
-            <filename>&DISTRO_NAME;</filename> branch, the
+            <filename>&DISTRO_NAME_NO_CAP;</filename> branch, the
             <filename>master</filename> branch, and many branches for past
             Yocto Project releases.
             You can see all the branches by going to
@@ -1015,14 +1008,14 @@
      $ cd ~
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
-     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
             </literallayout>
             In this example, the name of the top-level directory of your local
             <link linkend='source-directory'>Source Directory</link>
             is "poky" and the name of that local working area (local branch)
-            you just created and checked out is "&DISTRO_NAME;".
+            you just created and checked out is "&DISTRO_NAME_NO_CAP;".
             The files in your local repository now reflect the same files that
-            are in the "&DISTRO_NAME;" development branch of the
+            are in the "&DISTRO_NAME_NO_CAP;" development branch of the
             Yocto Project's "poky" upstream repository.
             It is important to understand that when you create and checkout a
             local working branch based on a branch name,
@@ -1030,7 +1023,7 @@
             at the time you created your local branch, which could be
             different from the files at the time of a similarly named release.
             In other words, creating and checking out a local branch based on
-            the "&DISTRO_NAME;" branch name is not the same as
+            the "&DISTRO_NAME_NO_CAP;" branch name is not the same as
             cloning and checking out the "master" branch.
             Keep reading to see how you create a local snapshot of a Yocto
             Project Release.
@@ -1049,10 +1042,11 @@
         </para>
 
         <para>
-            Some key tags are <filename>dylan-9.0.4</filename>,
-            <filename>dora-10.0.4</filename>, <filename>daisy-11.0.2</filename>,
-            <filename>dizzy-12.0.0</filename>, and
-            <filename>&DISTRO_NAME;-&POKYVERSION;</filename>.
+            Some key tags are
+            <filename>dizzy-12.0.0</filename>,
+            <filename>fido-13.0.0</filename>,
+            <filename>jethro-14.0.0</filename>, and
+            <filename>&DISTRO_NAME_NO_CAP;-&POKYVERSION;</filename>.
             These tags represent Yocto Project releases.
         </para>
 
@@ -1070,14 +1064,14 @@
      $ cd ~
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
-     $ git checkout -b my-&DISTRO_NAME;-&POKYVERSION; &DISTRO_NAME;-&POKYVERSION;
+     $ git checkout -b my-&DISTRO_NAME_NO_CAP;-&POKYVERSION; &DISTRO_NAME_NO_CAP;-&POKYVERSION;
             </literallayout>
             In this example, the name of the top-level directory of your local Yocto Project
             Files Git repository is <filename>poky</filename>.
             And, the name of the local branch you have created and checked out is
-            <filename>my-&DISTRO_NAME;-&POKYVERSION;</filename>.
+            <filename>my-&DISTRO_NAME_NO_CAP;-&POKYVERSION;</filename>.
             The files in your repository now exactly match the Yocto Project &DISTRO;
-            Release tag (<filename>&DISTRO_NAME;-&POKYVERSION;</filename>).
+            Release tag (<filename>&DISTRO_NAME_NO_CAP;-&POKYVERSION;</filename>).
             It is important to understand that when you create and checkout a local
             working branch based on a tag, your environment matches a specific point
             in time and not the entire development branch.
@@ -1131,20 +1125,20 @@
                     into the project’s upstream (or master) repository.</para></listitem>
                 <listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that
                     possibly need to be staged and committed.</para></listitem>
-                <listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes
+                <listitem><para><emphasis><filename>git checkout</filename> <replaceable>branch-name</replaceable>:</emphasis> Changes
                     your working branch.
                     This command is analogous to "cd".</para></listitem>
-                <listitem><para><emphasis><filename>git checkout –b &lt;working-branch&gt;</filename>:</emphasis> Creates
+                <listitem><para><emphasis><filename>git checkout –b</filename> <replaceable>working-branch</replaceable>:</emphasis> Creates
                     a working branch on your local machine where you can isolate work.
                     It is a good idea to use local branches when adding specific features or changes.
                     This way if you do not like what you have done you can easily get rid of the work.</para></listitem>
                 <listitem><para><emphasis><filename>git branch</filename>:</emphasis> Reports
                     existing local branches and
                     tells you the branch in which you are currently working.</para></listitem>
-                <listitem><para><emphasis><filename>git branch -D &lt;branch-name&gt;</filename>:</emphasis>
+                <listitem><para><emphasis><filename>git branch -D</filename> <replaceable>branch-name</replaceable>:</emphasis>
                     Deletes an existing local branch.
                     You need to be in a local branch other than the one you are deleting
-                    in order to delete <filename>&lt;branch-name&gt;</filename>.</para></listitem>
+                    in order to delete <replaceable>branch-name</replaceable>.</para></listitem>
                 <listitem><para><emphasis><filename>git pull</filename>:</emphasis> Retrieves information
                     from an upstream Git
                     repository and places it in your local Git repository.
@@ -1410,7 +1404,7 @@
                 Examine the <filename>maintainers.inc</filename> file, which is
                 located in the
                 <link linkend='source-directory'>Source Directory</link>
-                at <filename>meta-yocto/conf/distro/include</filename>, to
+                at <filename>meta-poky/conf/distro/include</filename>, to
                 see who is responsible for code.
                 </para></listitem>
             <listitem><para><emphasis>Board Support Package (BSP) README Files:</emphasis>
@@ -1454,7 +1448,7 @@
             <listitem><para>For changes to BitBake (anything under the <filename>bitbake</filename>
                 directory), send your patch to the
                 <ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'>bitbake-devel</ulink> mailing list.</para></listitem>
-            <listitem><para>For changes to <filename>meta-yocto</filename>, send your patch to the
+            <listitem><para>For changes to <filename>meta-poky</filename>, send your patch to the
                 <ulink url='&YOCTO_LISTS_URL;/listinfo/poky'>poky</ulink> mailing list.</para></listitem>
             <listitem><para>For changes to other layers hosted on
                 <filename>yoctoproject.org</filename> (unless the

yocto-poky/documentation/dev-manual/dev-manual-qemu.xml

diff --git a/yocto-poky/documentation/dev-manual/dev-manual-qemu.xml b/yocto-poky/documentation/dev-manual/dev-manual-qemu.xml
index 903028f..41c1829 100644
--- a/yocto-poky/documentation/dev-manual/dev-manual-qemu.xml
+++ b/yocto-poky/documentation/dev-manual/dev-manual-qemu.xml
@@ -47,11 +47,10 @@
 
     <para>
         QEMU is made available with the Yocto Project a number of ways.
-        The easiest and recommended method for getting QEMU is to run the
-        ADT installer.  For more information on how to make sure you have
+        One method is to install a Software Development Kit (SDK).
+        For more information on how to make sure you have
         QEMU available, see the
-        "<ulink url='&YOCTO_DOCS_ADT_URL;#the-qemu-emulator'>The QEMU Emulator</ulink>"
-        section in the Yocto Project Application Developer's Guide.
+        <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
     </para>
 </section>
 

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

diff --git a/yocto-poky/documentation/dev-manual/dev-manual-start.xml b/yocto-poky/documentation/dev-manual/dev-manual-start.xml
index db989b7..23bf8eb 100644
--- a/yocto-poky/documentation/dev-manual/dev-manual-start.xml
+++ b/yocto-poky/documentation/dev-manual/dev-manual-start.xml
@@ -221,10 +221,8 @@
                 </literallayout>
                 where <replaceable>bsp_name</replaceable> is the recognized
                 BSP name.
-                Here are some examples:
+                Here is an example:
                 <literallayout class='monospaced'>
-     meta-crownbay
-     meta-emenlow
      meta-raspberrypi
                 </literallayout>
                 See the
@@ -263,11 +261,12 @@
      $ cd ~/poky
      $ git clone git://git.yoctoproject.org/meta-intel.git
      Cloning into 'meta-intel'...
-     remote: Counting objects: 8844, done.
-     remote: Compressing objects: 100% (2864/2864), done.
-     remote: Total 8844 (delta 4931), reused 8780 (delta 4867)
-     Receiving objects: 100% (8844/8844), 2.48 MiB | 264 KiB/s, done.
-     Resolving deltas: 100% (4931/4931), done.
+     remote: Counting objects: 11917, done.
+     remote: Compressing objects: 100% (3842/3842), done.
+     remote: Total 11917 (delta 6840), reused 11699 (delta 6622)
+     Receiving objects: 100% (11917/11917), 2.92 MiB | 2.88 MiB/s, done.
+     Resolving deltas: 100% (6840/6840), done.
+     Checking connectivity... done.
                 </literallayout></para>
 
                 <para>The same
@@ -279,8 +278,9 @@
                 applications using the Eclipse Integrated Development Environment (IDE),
                 you will need this plug-in.
                 See the
-                "<link linkend='setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</link>"
-                section for more information.</para></listitem>
+                "<ulink url='&YOCTO_DOCS_SDK_URL;#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
+                section in the Yocto Project Software Development Kit (SDK)
+                Developer's Guide for more information.</para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -341,14 +341,17 @@
     </para>
 
     <para>
-        Using a pre-built binary is ideal for developing software applications to run on your
-        target hardware.
-        To do this, you need to be able to access the appropriate cross-toolchain tarball for
-        the architecture on which you are developing.
-        If you are using an SDK type image, the image ships with the complete toolchain native to
-        the architecture.
-        If you are not using an SDK type image, you need to separately download and
-        install the stand-alone Yocto Project cross-toolchain tarball.
+        Using a pre-built binary is ideal for developing software
+        applications to run on your target hardware.
+        To do this, you need to be able to access the appropriate
+        cross-toolchain tarball for the architecture on which you are
+        developing.
+        If you are using an SDK type image, the image ships with the complete
+        toolchain native to the architecture (i.e. a toolchain designed to
+        run on the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>).
+        If you are not using an SDK type image, you need to separately download
+        and install the stand-alone Yocto Project cross-toolchain tarball.
     </para>
 
     <para>
@@ -363,8 +366,7 @@
         by sourcing an environment setup script.
         Finally, you start the QEMU emulator.
         You can find details on all these steps in the
-        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Example Using Pre-Built Binaries and QEMU</ulink>"
-        section of the Yocto Project Application Developer's Guide.
+        <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
         You can learn more about using QEMU with the Yocto Project in the
         "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
         section.

yocto-poky/documentation/dev-manual/dev-manual.xml

diff --git a/yocto-poky/documentation/dev-manual/dev-manual.xml b/yocto-poky/documentation/dev-manual/dev-manual.xml
index 3ddd01f..791a8cb 100644
--- a/yocto-poky/documentation/dev-manual/dev-manual.xml
+++ b/yocto-poky/documentation/dev-manual/dev-manual.xml
@@ -81,6 +81,11 @@
                 <date>October 2015</date>
                 <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>April 2016</date>
+                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

yocto-poky/documentation/dev-manual/dev-style.css

diff --git a/yocto-poky/documentation/dev-manual/dev-style.css b/yocto-poky/documentation/dev-manual/dev-style.css
index b900ffc..6d0aa8e 100644
--- a/yocto-poky/documentation/dev-manual/dev-style.css
+++ b/yocto-poky/documentation/dev-manual/dev-style.css
@@ -730,6 +730,10 @@
   border-color: black;
 }
 
+.writernotes {
+  color: red;
+}
+
 
   /*********** /
  /  graphics  /

yocto-poky/documentation/dev-manual/figures/app-dev-flow.png

diff --git a/yocto-poky/documentation/dev-manual/figures/app-dev-flow.png b/yocto-poky/documentation/dev-manual/figures/app-dev-flow.png
deleted file mode 100644
index ec93374..0000000
--- a/yocto-poky/documentation/dev-manual/figures/app-dev-flow.png
+++ /dev/null
Binary files differ

yocto-poky/documentation/dev-manual/figures/build-workspace-directory.png

diff --git a/yocto-poky/documentation/dev-manual/figures/build-workspace-directory.png b/yocto-poky/documentation/dev-manual/figures/build-workspace-directory.png
index f561f8f..5387d33 100644
--- a/yocto-poky/documentation/dev-manual/figures/build-workspace-directory.png
+++ b/yocto-poky/documentation/dev-manual/figures/build-workspace-directory.png
Binary files differ

yocto-poky/documentation/dev-manual/figures/devtool-add-flow.png

diff --git a/yocto-poky/documentation/dev-manual/figures/devtool-add-flow.png b/yocto-poky/documentation/dev-manual/figures/devtool-add-flow.png
new file mode 100644
index 0000000..c09e60e
--- /dev/null
+++ b/yocto-poky/documentation/dev-manual/figures/devtool-add-flow.png
Binary files differ

yocto-poky/documentation/dev-manual/figures/devtool-modify-flow.png

diff --git a/yocto-poky/documentation/dev-manual/figures/devtool-modify-flow.png b/yocto-poky/documentation/dev-manual/figures/devtool-modify-flow.png
new file mode 100644
index 0000000..cd7f4d0
--- /dev/null
+++ b/yocto-poky/documentation/dev-manual/figures/devtool-modify-flow.png
Binary files differ

yocto-poky/documentation/dev-manual/figures/devtool-upgrade-flow.png

diff --git a/yocto-poky/documentation/dev-manual/figures/devtool-upgrade-flow.png b/yocto-poky/documentation/dev-manual/figures/devtool-upgrade-flow.png
new file mode 100644
index 0000000..d25168c
--- /dev/null
+++ b/yocto-poky/documentation/dev-manual/figures/devtool-upgrade-flow.png
Binary files differ

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

diff --git a/yocto-poky/documentation/kernel-dev/kernel-dev-advanced.xml b/yocto-poky/documentation/kernel-dev/kernel-dev-advanced.xml
index 4fdb853..9e15f17 100644
--- a/yocto-poky/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/yocto-poky/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -29,8 +29,8 @@
         source Git repositories.
         This Metadata defines Board Support Packages (BSPs) that
         correspond to definitions in linux-yocto recipes for the same BSPs.
-        A BSP consists of an aggregation of kernel policy and hardware-specific
-        feature enablements.
+        A BSP consists of an aggregation of kernel policy and enabled
+        hardware-specific features.
         The BSP can be influenced from within the linux-yocto recipe.
         <note>
             Linux kernel source that contains kernel Metadata is said to be
@@ -171,8 +171,8 @@
     <title>Kernel Metadata Location</title>
 
     <para>
-        Kernel Metadata can be defined in either the kernel recipe
-        (recipe-space) or in the kernel tree (in-tree).
+        Kernel Metadata always exists outside of the kernel tree either
+        defined in a kernel recipe (recipe-space) or outside of the recipe.
         Where you choose to define the Metadata depends on what you want
         to do and how you intend to work.
         Regardless of where you define the kernel Metadata, the syntax used
@@ -195,10 +195,10 @@
     <para>
         Conversely, if you are actively developing a kernel and are already
         maintaining a Linux kernel Git repository of your own, you might find
-        it more convenient to work with the kernel Metadata in the same
-        repository as the Linux kernel sources.
-        This method can make iterative development of the Linux kernel
-        more efficient outside of the BitBake environment.
+        it more convenient to work with kernel Metadata kept outside the
+        recipe-space.
+        Working with Metadata in this area can make iterative development of
+        the Linux kernel more efficient outside of the BitBake environment.
     </para>
 
     <section id='recipe-space-metadata'>
@@ -249,38 +249,52 @@
         </para>
     </section>
 
-    <section id='in-tree-metadata'>
-        <title>In-Tree Metadata</title>
+    <section id='metadata-outside-the-recipe-space'>
+        <title>Metadata Outside the Recipe-Space</title>
 
         <para>
-            When stored in-tree, the kernel Metadata files reside in the
-            <filename>meta</filename> directory of the Linux kernel sources.
-            The <filename>meta</filename> directory can be present in the
-            same repository branch as the sources,
-            such as "master", or <filename>meta</filename> can be its own
-            orphan branch.
-            <note>
-                An orphan branch in Git is a branch with unique history and
-                content to the other branches in the repository.
-                Orphan branches are useful to track Metadata changes
-                independently from the sources of the Linux kernel, while
-                still keeping them together in the same repository.
-            </note>
-            For the purposes of this document, we will discuss all
-            in-tree Metadata as residing below the
-            <filename>meta/cfg/kernel-cache</filename> directory.
+            When stored outside of the recipe-space, the kernel Metadata
+            files reside in a separate repository.
+            The OpenEmbedded build system adds the Metadata to the build as
+            a "ktype=meta" repository through the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+            variable.
+            As an example, consider the following <filename>SRC_URI</filename>
+            statement from the <filename>linux-yocto_4.4.bb</filename>
+            kernel recipe:
+            <literallayout class='monospaced'>
+     SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH}; \
+                git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
+            </literallayout>
+            <filename>${KMETA}</filename>, in this context, is simply used to
+            name the directory into which the Git fetcher places the Metadata.
+            This behavior is no different than any multi-repository
+            <filename>SRC_URI</filename> statement used in a recipe.
         </para>
 
         <para>
+            You can keep kernel Metadata in a "kernel-cache", which is a
+            directory containing configuration fragments.
+            As with any Metadata kept outside the recipe-space, you simply
+            need to use the <filename>SRC_URI</filename> statement with the
+            "type=kmeta" attribute.
+            Doing so makes the kernel Metadata available during the
+            configuration phase.
+        </para>
+
+<!--
+
+
+        <para>
             Following is an example that shows how a trivial tree of Metadata
             is stored in a custom Linux kernel Git repository:
             <literallayout class='monospaced'>
      meta/
-     `-- cfg
-         `-- kernel-cache
-             |-- bsp-standard.scc
-             |-- bsp.cfg
-             `-- standard.cfg
+     `&dash;&dash; cfg
+         `&dash;&dash; kernel-cache
+             |&dash;&dash; bsp-standard.scc
+             |&dash;&dash; bsp.cfg
+             `&dash;&dash; standard.cfg
             </literallayout>
         </para>
 
@@ -301,16 +315,15 @@
             orphan <filename>meta</filename> branch, use these commands
             from within your Linux kernel Git repository:
             <literallayout class='monospaced'>
-     $ git checkout --orphan meta
+     $ git checkout &dash;&dash;orphan meta
      $ git rm -rf .
-     $ git commit --allow-empty -m "Create orphan meta branch"
+     $ git commit &dash;&dash;allow-empty -m "Create orphan meta branch"
             </literallayout>
         </para>
+-->
 
         <para>
-            If you modify the Metadata in the linux-yocto
-            <filename>meta</filename> branch, you must not forget to update
-            the
+            If you modify the Metadata, you must not forget to update the
             <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>
             statements in the kernel's recipe.
             In particular, you need to update the
@@ -437,7 +450,7 @@
         if you are creating Metadata in
         <link linkend='recipe-space-metadata'>recipe-space</link>,
         or <filename>meta/cfg/kernel-cache/</filename> if you are creating
-        Metadata <link linkend='in-tree-metadata'>in-tree</link>.
+        <link linkend='metadata-outside-the-recipe-space'>Metadata outside of the recipe-space</link>.
     </para>
 
     <section id='configuration'>

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

diff --git a/yocto-poky/documentation/kernel-dev/kernel-dev-common.xml b/yocto-poky/documentation/kernel-dev/kernel-dev-common.xml
index ab7f80f..261471c 100644
--- a/yocto-poky/documentation/kernel-dev/kernel-dev-common.xml
+++ b/yocto-poky/documentation/kernel-dev/kernel-dev-common.xml
@@ -270,11 +270,12 @@
                 edit the recipe that builds your kernel so that it has the
                 following command form:
                 <literallayout class='monospaced'>
-     KBUILD_DEFCONFIG_<ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'>KMACHINE</ulink> ?= <replaceable>defconfig_file</replaceable>
+     KBUILD_DEFCONFIG_KMACHINE ?= <replaceable>defconfig_file</replaceable>
                 </literallayout>
                 You need to append the variable with
-                <filename>KMACHINE</filename> and then supply the path to
-                your "in-tree" <filename>defconfig</filename> file.
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>
+                and then supply the path to your "in-tree"
+                <filename>defconfig</filename> file.
             </para>
 
             <para>
@@ -1031,6 +1032,127 @@
             </para>
         </section>
     </section>
+
+    <section id='adding-recipe-space-kernel-features'>
+        <title>Adding Recipe-Space Kernel Features</title>
+
+        <para>
+            You can add kernel features in the
+            <link linkend='recipe-space-metadata'>recipe-space</link> by
+            using the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
+            variable and by specifying the feature's <filename>.scc</filename>
+            file path in the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+            statement.
+            When you add features using this method, the OpenEmbedded build
+            system checks to be sure the features are present.
+            If the features are not present, the build stops.
+            Kernel features are the last elements processed for configuring
+            and patching the kernel.
+            Therefore, adding features in this manner is a way
+            to enforce specific features are present and enabled
+            without needing to do a full audit of any other layer's additions
+            to the <filename>SRC_URI</filename> statement.
+        </para>
+
+        <para>
+            You add a kernel feature by providing the feature as part of the
+            <filename>KERNEL_FEATURES</filename> variable and by providing the
+            path to the feature's <filename>.scc</filename> file, which is
+            relative to the root of the kernel Metadata.
+            The OpenEmbedded build system searches all forms of kernel
+            Metadata on the <filename>SRC_URI</filename> statement regardless
+            of whether the Metadata is in the "kernel-cache", system kernel
+            Metadata, or a recipe-space Metadata.
+            See the
+            "<link linkend='kernel-metadata-location'>Kernel Metadata Location</link>"
+            section for additional information.
+        </para>
+
+        <para>
+            When you specify the feature's <filename>.scc</filename> file
+            on the <filename>SRC_URI</filename> statement, the OpenEmbedded
+            build system adds the directory of that
+            <filename>.scc</filename> file along with all its subdirectories
+            to the kernel feature search path.
+            Because subdirectories are searched, you can reference a single
+            <filename>.scc</filename> file in the
+            <filename>SRC_URI</filename> statement to reference multiple kernel
+            features.
+        </para>
+
+        <para>
+            Consider the following example that adds the "test.scc" feature
+            to the build.
+            <orderedlist>
+                <listitem><para>
+                    Create a <filename>.scc</filename> file and locate it
+                    just as you would any other patch file,
+                    <filename>.cfg</filename> file, or fetcher item
+                    you specify in the <filename>SRC_URI</filename>
+                    statement.
+                    <note><title>Notes</title>
+                        <itemizedlist>
+                            <listitem><para>
+                                You must add the directory of the
+                                <filename>.scc</filename> file to the fetcher's
+                                search path in the same manner as you would
+                                add a <filename>.patch</filename> file.
+                                </para></listitem>
+                            <listitem><para>
+                                You can create additional
+                                <filename>.scc</filename> files beneath the
+                                directory that contains the file you are
+                                adding.
+                                All subdirectories are searched during the
+                                build as potential feature directories.
+                                </para></listitem>
+                        </itemizedlist>
+                    </note>
+                    Continuing with the example, suppose the "test.scc"
+                    feature you are adding has a
+                    <filename>test.scc</filename> file in the following
+                    directory:
+                    <literallayout class='monospaced'>
+     <replaceable>my_recipe</replaceable>
+        |
+        +-linux-yocto
+           |
+           +-test.cfg
+           +-test.scc
+                    </literallayout>
+                    In this example, the <filename>linux-yocto</filename>
+                    directory has both the feature
+                    <filename>test.scc</filename> file and a similarly
+                    named configuration fragment file
+                    <filename>test.cfg</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    Add the <filename>.scc</filename> file to the
+                    recipe's <filename>SRC_URI</filename> statement:
+                    <literallayout class='monospaced'>
+     SRC_URI_append = " file://test.scc"
+                    </literallayout>
+                    The leading space before the path is important as the
+                    path is appended to the existing path.
+                    </para></listitem>
+                <listitem><para>
+                    Specify the feature as a kernel feature:
+                    <literallayout class='monospaced'>
+     KERNEL_FEATURES_append = " test.scc"
+                    </literallayout>
+                    The OpenEmbedded build system processes the kernel feature
+                    when it builds the kernel.
+                    <note>
+                        If other features are contained below "test.scc",
+                        then their directories are relative to the directory
+                        containing the <filename>test.scc</filename> file.
+                    </note>
+                    </para></listitem>
+            </orderedlist>
+        </para>
+    </section>
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

yocto-poky/documentation/kernel-dev/kernel-dev.xml

diff --git a/yocto-poky/documentation/kernel-dev/kernel-dev.xml b/yocto-poky/documentation/kernel-dev/kernel-dev.xml
index 38850fa..fb11dd1 100644
--- a/yocto-poky/documentation/kernel-dev/kernel-dev.xml
+++ b/yocto-poky/documentation/kernel-dev/kernel-dev.xml
@@ -66,6 +66,11 @@
                 <date>October 2015</date>
                 <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>April 2016</date>
+                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

yocto-poky/documentation/mega-manual/figures/adt-title.png

diff --git a/yocto-poky/documentation/mega-manual/figures/adt-title.png b/yocto-poky/documentation/mega-manual/figures/adt-title.png
deleted file mode 100644
index 6e71e41..0000000
--- a/yocto-poky/documentation/mega-manual/figures/adt-title.png
+++ /dev/null
Binary files differ

yocto-poky/documentation/mega-manual/figures/app-dev-flow.png

diff --git a/yocto-poky/documentation/mega-manual/figures/app-dev-flow.png b/yocto-poky/documentation/mega-manual/figures/app-dev-flow.png
deleted file mode 100644
index 4927b93..0000000
--- a/yocto-poky/documentation/mega-manual/figures/app-dev-flow.png
+++ /dev/null
Binary files differ

yocto-poky/documentation/mega-manual/figures/build-workspace-directory.png

diff --git a/yocto-poky/documentation/mega-manual/figures/build-workspace-directory.png b/yocto-poky/documentation/mega-manual/figures/build-workspace-directory.png
index f561f8f..5387d33 100644
--- a/yocto-poky/documentation/mega-manual/figures/build-workspace-directory.png
+++ b/yocto-poky/documentation/mega-manual/figures/build-workspace-directory.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/compatible-layers.png

diff --git a/yocto-poky/documentation/mega-manual/figures/compatible-layers.png b/yocto-poky/documentation/mega-manual/figures/compatible-layers.png
new file mode 100644
index 0000000..38436b0
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/compatible-layers.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/devtool-add-flow.png

diff --git a/yocto-poky/documentation/mega-manual/figures/devtool-add-flow.png b/yocto-poky/documentation/mega-manual/figures/devtool-add-flow.png
new file mode 100644
index 0000000..c09e60e
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/devtool-add-flow.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/devtool-modify-flow.png

diff --git a/yocto-poky/documentation/mega-manual/figures/devtool-modify-flow.png b/yocto-poky/documentation/mega-manual/figures/devtool-modify-flow.png
new file mode 100644
index 0000000..cd7f4d0
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/devtool-modify-flow.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/devtool-upgrade-flow.png

diff --git a/yocto-poky/documentation/mega-manual/figures/devtool-upgrade-flow.png b/yocto-poky/documentation/mega-manual/figures/devtool-upgrade-flow.png
new file mode 100644
index 0000000..d25168c
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/devtool-upgrade-flow.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/image-generation.png

diff --git a/yocto-poky/documentation/mega-manual/figures/image-generation.png b/yocto-poky/documentation/mega-manual/figures/image-generation.png
index ab96258..71a48dc 100644
--- a/yocto-poky/documentation/mega-manual/figures/image-generation.png
+++ b/yocto-poky/documentation/mega-manual/figures/image-generation.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/import-layer.png

diff --git a/yocto-poky/documentation/mega-manual/figures/import-layer.png b/yocto-poky/documentation/mega-manual/figures/import-layer.png
new file mode 100644
index 0000000..436ec7a
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/import-layer.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/new-project.png

diff --git a/yocto-poky/documentation/mega-manual/figures/new-project.png b/yocto-poky/documentation/mega-manual/figures/new-project.png
new file mode 100644
index 0000000..dbc50b9
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/new-project.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/sdk-devtool-add-flow.png

diff --git a/yocto-poky/documentation/mega-manual/figures/sdk-devtool-add-flow.png b/yocto-poky/documentation/mega-manual/figures/sdk-devtool-add-flow.png
new file mode 100644
index 0000000..c09e60e
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/sdk-devtool-add-flow.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/sdk-devtool-modify-flow.png

diff --git a/yocto-poky/documentation/mega-manual/figures/sdk-devtool-modify-flow.png b/yocto-poky/documentation/mega-manual/figures/sdk-devtool-modify-flow.png
new file mode 100644
index 0000000..cd06c01
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/sdk-devtool-modify-flow.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/sdk-eclipse-dev-flow.png

diff --git a/yocto-poky/documentation/mega-manual/figures/sdk-eclipse-dev-flow.png b/yocto-poky/documentation/mega-manual/figures/sdk-eclipse-dev-flow.png
new file mode 100644
index 0000000..9f986e0
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/sdk-eclipse-dev-flow.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/sdk-environment.png

diff --git a/yocto-poky/documentation/mega-manual/figures/sdk-environment.png b/yocto-poky/documentation/mega-manual/figures/sdk-environment.png
new file mode 100644
index 0000000..78b8cad
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/sdk-environment.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/sdk-generation.png

diff --git a/yocto-poky/documentation/mega-manual/figures/sdk-generation.png b/yocto-poky/documentation/mega-manual/figures/sdk-generation.png
old mode 100644
new mode 100755
index c37e274..adbe1f4
--- a/yocto-poky/documentation/mega-manual/figures/sdk-generation.png
+++ b/yocto-poky/documentation/mega-manual/figures/sdk-generation.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/sdk-installed-extensible-sdk-directory.png

diff --git a/yocto-poky/documentation/mega-manual/figures/sdk-installed-extensible-sdk-directory.png b/yocto-poky/documentation/mega-manual/figures/sdk-installed-extensible-sdk-directory.png
new file mode 100644
index 0000000..99e07ce
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/sdk-installed-extensible-sdk-directory.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/sdk-installed-standard-sdk-directory.png

diff --git a/yocto-poky/documentation/mega-manual/figures/sdk-installed-standard-sdk-directory.png b/yocto-poky/documentation/mega-manual/figures/sdk-installed-standard-sdk-directory.png
new file mode 100644
index 0000000..d4af850
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/sdk-installed-standard-sdk-directory.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/sdk-title.png

diff --git a/yocto-poky/documentation/mega-manual/figures/sdk-title.png b/yocto-poky/documentation/mega-manual/figures/sdk-title.png
new file mode 100644
index 0000000..e9d5b34
--- /dev/null
+++ b/yocto-poky/documentation/mega-manual/figures/sdk-title.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/sdk.png

diff --git a/yocto-poky/documentation/mega-manual/figures/sdk.png b/yocto-poky/documentation/mega-manual/figures/sdk.png
index a539cc5..5c36b75 100644
--- a/yocto-poky/documentation/mega-manual/figures/sdk.png
+++ b/yocto-poky/documentation/mega-manual/figures/sdk.png
Binary files differ

yocto-poky/documentation/mega-manual/figures/user-configuration.png

diff --git a/yocto-poky/documentation/mega-manual/figures/user-configuration.png b/yocto-poky/documentation/mega-manual/figures/user-configuration.png
old mode 100644
new mode 100755
index f2b3f8e..c298401
--- a/yocto-poky/documentation/mega-manual/figures/user-configuration.png
+++ b/yocto-poky/documentation/mega-manual/figures/user-configuration.png
Binary files differ

yocto-poky/documentation/mega-manual/mega-manual.xml

diff --git a/yocto-poky/documentation/mega-manual/mega-manual.xml b/yocto-poky/documentation/mega-manual/mega-manual.xml
index 5c1faec..154e369 100644
--- a/yocto-poky/documentation/mega-manual/mega-manual.xml
+++ b/yocto-poky/documentation/mega-manual/mega-manual.xml
@@ -50,6 +50,11 @@
                 <date>October 2015</date>
                 <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>April 2016</date>
+                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>
@@ -97,22 +102,22 @@
     <xi:include
         xmlns:xi="http://www.w3.org/2003/XInclude" href="../dev-manual/dev-manual-qemu.xml"/>
 
-<!-- Includes adt-manual title image and then adt-manual chapters -->
+<!-- Includes sdk-manual title image and then sdk-manual chapters -->
 
     <para>
-        <imagedata fileref="figures/adt-title.png" width="100%" align="left" scalefit="1" />
+        <imagedata fileref="figures/sdk-title.png" width="100%" align="left" scalefit="1" />
     </para>
 
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../adt-manual/adt-manual-intro.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-intro.xml"/>
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../adt-manual/adt-intro.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-using.xml"/>
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../adt-manual/adt-prepare.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-extensible.xml"/>
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../adt-manual/adt-package.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-obtain.xml"/>
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../adt-manual/adt-command.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-customizing.xml"/>
 
 <!-- Includes bsp-guide title image and then bsp-guide chapters -->
 

yocto-poky/documentation/poky.ent

diff --git a/yocto-poky/documentation/poky.ent b/yocto-poky/documentation/poky.ent
index 33d52c0..673ab23 100644
--- a/yocto-poky/documentation/poky.ent
+++ b/yocto-poky/documentation/poky.ent
@@ -1,11 +1,12 @@
-<!ENTITY DISTRO "2.0">
-<!ENTITY DISTRO_COMPRESSED "20">
-<!ENTITY DISTRO_NAME "jethro">
-<!ENTITY YOCTO_DOC_VERSION "2.0">
-<!ENTITY POKYVERSION "14.0.0">
-<!ENTITY POKYVERSION_COMPRESSED "1400">
-<!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2015">
+<!ENTITY DISTRO "2.1">
+<!ENTITY DISTRO_COMPRESSED "21">
+<!ENTITY DISTRO_NAME_NO_CAP "krogoth">
+<!ENTITY DISTRO_NAME "Krogoth">
+<!ENTITY YOCTO_DOC_VERSION "2.1">
+<!ENTITY POKYVERSION "15.0.0">
+<!ENTITY POKYVERSION_COMPRESSED "1500">
+<!ENTITY YOCTO_POKY "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;">
+<!ENTITY COPYRIGHT_YEAR "2010-2016">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
 <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
 <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
@@ -14,7 +15,7 @@
 <!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
 <!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
 <!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
-<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/downloads/core/&DISTRO_NAME;&DISTRO_COMPRESSED;">
+<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/downloads/core/&DISTRO_NAME_NO_CAP;&DISTRO_COMPRESSED;">
 <!ENTITY OE_HOME_URL "http://www.openembedded.org">
 <!ENTITY OE_LISTS_URL "http://lists.openembedded.org/mailman">
 <!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
@@ -54,6 +55,7 @@
 <!ENTITY YOCTO_DOCS_MM_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/mega-manual/mega-manual.html">
 <!ENTITY YOCTO_DOCS_BB_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bitbake-user-manual/bitbake-user-manual.html">
 <!ENTITY YOCTO_DOCS_TOAST_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/toaster-manual/toaster-manual.html">
+<!ENTITY YOCTO_DOCS_SDK_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/sdk-manual/sdk-manual.html">
 <!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;">
 <!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
 <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
@@ -62,7 +64,7 @@
      build-essential chrpath socat">
 <!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
-     ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat \
+     ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \
      findutils which">
 <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
      diffstat makeinfo python-curses patch socat">

yocto-poky/documentation/profile-manual/profile-manual-usage.xml

diff --git a/yocto-poky/documentation/profile-manual/profile-manual-usage.xml b/yocto-poky/documentation/profile-manual/profile-manual-usage.xml
index 95ad739..310e8f0 100644
--- a/yocto-poky/documentation/profile-manual/profile-manual-usage.xml
+++ b/yocto-poky/documentation/profile-manual/profile-manual-usage.xml
@@ -2169,16 +2169,16 @@
 
      ### Shell environment set up for builds. ###
 
-     You can now run 'bitbake <replaceable>target</replaceable>'
+     You can now run 'bitbake &lt;target&gt;'
 
      Common targets are:
-         core-image-minimal
-         core-image-sato
-         meta-toolchain
-         adt-installer
-         meta-ide-support
+              core-image-minimal
+              core-image-sato
+              meta-toolchain
+              meta-ide-support
 
      You can also run generated qemu images with a command like 'runqemu qemux86'
+
             </literallayout>
             Once you've done that, you can cd to whatever directory
             contains your scripts and use 'crosstap' to run the script:
@@ -2228,541 +2228,6 @@
     </section>
 </section>
 
-<section id='profile-manual-oprofile'>
-    <title>oprofile</title>
-
-    <para>
-        oprofile itself is a command-line application that runs on the
-        target system.
-    </para>
-
-    <section id='oprofile-setup'>
-        <title>Setup</title>
-
-        <para>
-            For this section, we'll assume you've already performed the
-            basic setup outlined in the
-            "<link linkend='profile-manual-general-setup'>General Setup</link>"
-            section.
-        </para>
-
-        <para>
-            For the section that deals with running oprofile from the command-line,
-            we assume you've ssh'ed to the host and will be running
-            oprofile on the target.
-        </para>
-
-        <para>
-            oprofileui (oprofile-viewer) is a GUI-based program that runs
-            on the host and interacts remotely with the target.
-            See the oprofileui section for the exact steps needed to
-            install oprofileui on the host.
-        </para>
-    </section>
-
-    <section id='oprofile-basic-usage'>
-        <title>Basic Usage</title>
-
-        <para>
-            Oprofile as configured in Yocto is a system-wide profiler
-            (i.e. the version in Yocto doesn't yet make use of the
-            perf_events interface which would allow it to profile
-            specific processes and workloads). It relies on hardware
-            counter support in the hardware (but can fall back to a
-            timer-based mode), which means that it doesn't take
-            advantage of tracepoints or other event sources for example.
-        </para>
-
-        <para>
-            It consists of a kernel module that collects samples and a
-            userspace daemon that writes the sample data to disk.
-        </para>
-
-        <para>
-            The 'opcontrol' shell script is used for transparently
-            managing these components and starting and stopping
-            profiles, and the 'opreport' command is used to
-            display the results.
-        </para>
-
-        <para>
-            The oprofile daemon should already be running, but before
-            you start profiling, you may need to change some settings
-            and some of these settings may require the daemon to not
-            be running. One of these settings is the path to the
-            vmlinux file, which you'll want to set using the --vmlinux
-            option if you want the kernel profiled:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --vmlinux=/boot/vmlinux-`uname -r`
-     The profiling daemon is currently active, so changes to the configuration
-     will be used the next time you restart oprofile after a --shutdown or --deinit.
-            </literallayout>
-            You can check if vmlinux file: is set using opcontrol --status:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --status
-     Daemon paused: pid 1334
-     Separate options: library
-     vmlinux file: none
-     Image filter: none
-     Call-graph depth: 6
-            </literallayout>
-            If it's not, you need to shutdown the daemon, add the setting
-            and restart the daemon:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --shutdown
-     Killing daemon.
-
-     root@crownbay:~# opcontrol --vmlinux=/boot/vmlinux-`uname -r`
-     root@crownbay:~# opcontrol --start-daemon
-     Using default event: CPU_CLK_UNHALTED:100000:0:1:1
-     Using 2.6+ OProfile kernel interface.
-     Reading module info.
-     Using log file /var/lib/oprofile/samples/oprofiled.log
-     Daemon started.
-            </literallayout>
-            If we check the status again we now see our updated settings:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --status
-     Daemon paused: pid 1649
-     Separate options: library
-     vmlinux file: /boot/vmlinux-3.4.11-yocto-standard
-     Image filter: none
-     Call-graph depth: 6
-            </literallayout>
-            We're now in a position to run a profile. For that we use
-            'opcontrol --start':
-            <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --start
-     Profiler running.
-            </literallayout>
-            In another window, run our wget workload:
-            <literallayout class='monospaced'>
-     root@crownbay:~# rm linux-2.6.19.2.tar.bz2; wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>; sync
-     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
-     linux-2.6.19.2.tar.b 100% |*******************************| 41727k  0:00:00 ETA
-            </literallayout>
-            To stop the profile we use 'opcontrol --shutdown', which not
-            only stops the profile but shuts down the daemon as well:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --shutdown
-     Stopping profiling.
-     Killing daemon.
-            </literallayout>
-            Oprofile writes sample data to /var/lib/oprofile/samples,
-            which you can look at if you're interested in seeing how the
-            samples are structured. This is also interesting because
-            it's related to how you dive down to get further details
-            about specific executables in OProfile.
-        </para>
-
-        <para>
-            To see the default display output for a profile, simply type
-            'opreport', which will show the results using the data in
-            /var/lib/oprofile/samples:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opreport
-
-     WARNING! The OProfile kernel driver reports sample buffer overflows.
-     Such overflows can result in incorrect sample attribution, invalid sample
-     files and other symptoms.  See the oprofiled.log for details.
-     You should adjust your sampling frequency to eliminate (or at least minimize)
-     these overflows.
-     CPU: Intel Architectural Perfmon, speed 1.3e+06 MHz (estimated)
-     Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
-     CPU_CLK_UNHALT...|
-      samples|      %|
-     ------------------
-       464365 79.8156 vmlinux-3.4.11-yocto-standard
-        65108 11.1908 oprofiled
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
- 	     ------------------
- 	         64416 98.9372 oprofiled
- 	           692  1.0628 libc-2.16.so
-        36959  6.3526 no-vmlinux
-         4378  0.7525 busybox
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	          2844 64.9612 libc-2.16.so
-	          1337 30.5391 busybox
-	           193  4.4084 ld-2.16.so
-	             2  0.0457 libnss_compat-2.16.so
-	             1  0.0228 libnsl-2.16.so
-	             1  0.0228 libnss_files-2.16.so
-         4344  0.7467 bash
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	          2657 61.1648 bash
-	          1665 38.3287 libc-2.16.so
-	            18  0.4144 ld-2.16.so
-	             3  0.0691 libtinfo.so.5.9
-	             1  0.0230 libdl-2.16.so
-         3118  0.5359 nf_conntrack
-          686  0.1179 matchbox-terminal
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	           214 31.1953 libglib-2.0.so.0.3200.4
-	           114 16.6181 libc-2.16.so
-	            79 11.5160 libcairo.so.2.11200.2
-	            78 11.3703 libgdk-x11-2.0.so.0.2400.8
-	            51  7.4344 libpthread-2.16.so
-	            45  6.5598 libgobject-2.0.so.0.3200.4
-	            29  4.2274 libvte.so.9.2800.2
-	            25  3.6443 libX11.so.6.3.0
-	            19  2.7697 libxcb.so.1.1.0
-	            17  2.4781 libgtk-x11-2.0.so.0.2400.8
-	            12  1.7493 librt-2.16.so
-	             3  0.4373 libXrender.so.1.3.0
-          671  0.1153 emgd
-          411  0.0706 nf_conntrack_ipv4
-          391  0.0672 iptable_nat
-          378  0.0650 nf_nat
-          263  0.0452 Xorg
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	           106 40.3042 Xorg
-	            53 20.1521 libc-2.16.so
-	            31 11.7871 libpixman-1.so.0.27.2
-	            26  9.8859 emgd_drv.so
-	            16  6.0837 libemgdsrv_um.so.1.5.15.3226
-	            11  4.1825 libEMGD2d.so.1.5.15.3226
-	             9  3.4221 libfb.so
-	             7  2.6616 libpthread-2.16.so
-	             1  0.3802 libudev.so.0.9.3
-	             1  0.3802 libdrm.so.2.4.0
-	             1  0.3802 libextmod.so
-	             1  0.3802 mouse_drv.so
-     .
-     .
-     .
-           9  0.0015 connmand
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	             4 44.4444 libglib-2.0.so.0.3200.4
-	             2 22.2222 libpthread-2.16.so
-	             1 11.1111 connmand
-	             1 11.1111 libc-2.16.so
-	             1 11.1111 librt-2.16.so
-            6  0.0010 oprofile-server
-     	 CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	             3 50.0000 libc-2.16.so
-	             1 16.6667 oprofile-server
-	             1 16.6667 libpthread-2.16.so
-	             1 16.6667 libglib-2.0.so.0.3200.4
-           5 8.6e-04 gconfd-2
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	             2 40.0000 libdbus-1.so.3.7.2
-	             2 40.0000 libglib-2.0.so.0.3200.4
-	             1 20.0000 libc-2.16.so
-            </literallayout>
-            The output above shows the breakdown or samples by both
-            number of samples and percentage for each executable.
-            Within an executable, the sample counts are broken down
-            further into executable and shared libraries (DSOs) used
-            by the executable.
-        </para>
-
-        <para>
-            To get even more detailed breakdowns by function, we need to
-            have the full paths to the DSOs, which we can get by
-            using -f with opreport:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opreport -f
-
-     CPU: Intel Architectural Perfmon, speed 1.3e+06 MHz (estimated)
-     Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
-     CPU_CLK_UNHALT...|
-      samples|      %|
-
-       464365 79.8156 /boot/vmlinux-3.4.11-yocto-standard
-       65108 11.1908 /usr/bin/oprofiled
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	         64416 98.9372 /usr/bin/oprofiled
-	           692  1.0628 /lib/libc-2.16.so
-        36959  6.3526 /no-vmlinux
-         4378  0.7525 /bin/busybox
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	          2844 64.9612 /lib/libc-2.16.so
-	          1337 30.5391 /bin/busybox
-	           193  4.4084 /lib/ld-2.16.so
-	             2  0.0457 /lib/libnss_compat-2.16.so
-	             1  0.0228 /lib/libnsl-2.16.so
-	             1  0.0228 /lib/libnss_files-2.16.so
-         4344  0.7467 /bin/bash
-	     CPU_CLK_UNHALT...|
-	       samples|      %|
-	     ------------------
-	          2657 61.1648 /bin/bash
-	          1665 38.3287 /lib/libc-2.16.so
-	            18  0.4144 /lib/ld-2.16.so
-	             3  0.0691 /lib/libtinfo.so.5.9
-	             1  0.0230 /lib/libdl-2.16.so
-     .
-     .
-     .
-            </literallayout>
-            Using the paths shown in the above output and the -l option to
-            opreport, we can see all the functions that have hits in the
-            profile and their sample counts and percentages. Here's a
-            portion of what we get for the kernel:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opreport -l /boot/vmlinux-3.4.11-yocto-standard
-
-     CPU: Intel Architectural Perfmon, speed 1.3e+06 MHz (estimated)
-     Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
-     samples  %        symbol name
-     233981   50.3873  intel_idle
-     15437     3.3243  rb_get_reader_page
-     14503     3.1232  ring_buffer_consume
-     14092     3.0347  mutex_spin_on_owner
-     13024     2.8047  read_hpet
-     8039      1.7312  sub_preempt_count
-     7096      1.5281  ioread32
-     6997      1.5068  add_preempt_count
-     3985      0.8582  rb_advance_reader
-     3488      0.7511  add_event_entry
-     3303      0.7113  get_parent_ip
-     3104      0.6684  rb_buffer_peek
-     2960      0.6374  op_cpu_buffer_read_entry
-     2614      0.5629  sync_buffer
-     2545      0.5481  debug_smp_processor_id
-     2456      0.5289  ohci_irq
-     2397      0.5162  memset
-     2349      0.5059  __copy_to_user_ll
-     2185      0.4705  ring_buffer_event_length
-     1918      0.4130  in_lock_functions
-     1850      0.3984  __schedule
-     1767      0.3805  __copy_from_user_ll_nozero
-     1575      0.3392  rb_event_data_length
-     1256      0.2705  memcpy
-     1233      0.2655  system_call
-     1213      0.2612  menu_select
-            </literallayout>
-            Notice that above we see an entry for the __copy_to_user_ll()
-            function that we've looked at with other profilers as well.
-        </para>
-
-        <para>
-            Here's what we get when we do the same thing for the
-            busybox executable:
-            <literallayout class='monospaced'>
-     CPU: Intel Architectural Perfmon, speed 1.3e+06 MHz (estimated)
-     Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
-     samples  %        image name               symbol name
-     349       8.4198  busybox                  retrieve_file_data
-     308       7.4306  libc-2.16.so             _IO_file_xsgetn
-     283       6.8275  libc-2.16.so             __read_nocancel
-     235       5.6695  libc-2.16.so             syscall
-     233       5.6212  libc-2.16.so             clearerr
-     215       5.1870  libc-2.16.so             fread
-     181       4.3667  libc-2.16.so             __write_nocancel
-     158       3.8118  libc-2.16.so             __underflow
-     151       3.6429  libc-2.16.so             _dl_addr
-     150       3.6188  busybox                  progress_meter
-     150       3.6188  libc-2.16.so             __poll_nocancel
-     148       3.5706  libc-2.16.so             _IO_file_underflow@@GLIBC_2.1
-     137       3.3052  busybox                  safe_poll
-     125       3.0157  busybox                  bb_progress_update
-     122       2.9433  libc-2.16.so             __x86.get_pc_thunk.bx
-     95        2.2919  busybox                  full_write
-     81        1.9542  busybox                  safe_write
-     77        1.8577  busybox                  xwrite
-     72        1.7370  libc-2.16.so             _IO_file_read
-     71        1.7129  libc-2.16.so             _IO_sgetn
-     67        1.6164  libc-2.16.so             poll
-     52        1.2545  libc-2.16.so             _IO_switch_to_get_mode
-     45        1.0856  libc-2.16.so             read
-     34        0.8203  libc-2.16.so             write
-     32        0.7720  busybox                  monotonic_sec
-     25        0.6031  libc-2.16.so             vfprintf
-     22        0.5308  busybox                  get_mono
-     14        0.3378  ld-2.16.so               strcmp
-     14        0.3378  libc-2.16.so             __x86.get_pc_thunk.cx
-     .
-     .
-     .
-            </literallayout>
-            Since we recorded the profile with a callchain depth of 6, we
-            should be able to see our __copy_to_user_ll() callchains in
-            the output, and indeed we can if we search around a bit in
-            the 'opreport --callgraph' output:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opreport --callgraph /boot/vmlinux-3.4.11-yocto-standard
-
-       392       6.9639  vmlinux-3.4.11-yocto-standard sock_aio_read
-       736      13.0751  vmlinux-3.4.11-yocto-standard __generic_file_aio_write
-       3255     57.8255  vmlinux-3.4.11-yocto-standard inet_recvmsg
-     785       0.1690  vmlinux-3.4.11-yocto-standard tcp_recvmsg
-       1790     31.7940  vmlinux-3.4.11-yocto-standard local_bh_enable
-       1238     21.9893  vmlinux-3.4.11-yocto-standard __kfree_skb
-       992      17.6199  vmlinux-3.4.11-yocto-standard lock_sock_nested
-       785      13.9432  vmlinux-3.4.11-yocto-standard tcp_recvmsg [self]
-       525       9.3250  vmlinux-3.4.11-yocto-standard release_sock
-       112       1.9893  vmlinux-3.4.11-yocto-standard tcp_cleanup_rbuf
-       72        1.2789  vmlinux-3.4.11-yocto-standard skb_copy_datagram_iovec
-
-     170       0.0366  vmlinux-3.4.11-yocto-standard skb_copy_datagram_iovec
-       1491     73.3038  vmlinux-3.4.11-yocto-standard memcpy_toiovec
-       327      16.0767  vmlinux-3.4.11-yocto-standard skb_copy_datagram_iovec
-       170       8.3579  vmlinux-3.4.11-yocto-standard skb_copy_datagram_iovec [self]
-       20        0.9833  vmlinux-3.4.11-yocto-standard copy_to_user
-
-       2588     98.2909  vmlinux-3.4.11-yocto-standard copy_to_user
-     2349      0.5059  vmlinux-3.4.11-yocto-standard __copy_to_user_ll
-       2349     89.2138  vmlinux-3.4.11-yocto-standard __copy_to_user_ll [self]
-       166       6.3046  vmlinux-3.4.11-yocto-standard do_page_fault
-            </literallayout>
-            Remember that by default OProfile sessions are cumulative
-            i.e. if you start and stop a profiling session, then start a
-            new one, the new one will not erase the previous run(s) but
-            will build on it. If you want to restart a profile from scratch,
-            you need to reset:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --reset
-            </literallayout>
-        </para>
-    </section>
-
-    <section id='oprofileui-a-gui-for-oprofile'>
-        <title>OProfileUI - A GUI for OProfile</title>
-
-        <para>
-            Yocto also supports a graphical UI for controlling and viewing
-            OProfile traces, called OProfileUI. To use it, you first need
-            to clone the oprofileui git repo, then configure, build, and
-            install it:
-            <literallayout class='monospaced'>
-     [trz@empanada tmp]$ git clone git://git.yoctoproject.org/oprofileui
-     [trz@empanada tmp]$ cd oprofileui
-     [trz@empanada oprofileui]$ ./autogen.sh
-     [trz@empanada oprofileui]$ sudo make install
-            </literallayout>
-            OprofileUI replaces the 'opreport' functionality with a GUI,
-            and normally doesn't require the user to use 'opcontrol' either.
-            If you want to profile the kernel, however, you need to either
-            use the UI to specify a vmlinux or use 'opcontrol' to specify
-            it on the target:
-        </para>
-
-        <para>
-            First, on the target, check if vmlinux file: is set:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --status
-            </literallayout>
-            If not:
-            <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --shutdown
-     root@crownbay:~# opcontrol --vmlinux=/boot/vmlinux-`uname -r`
-     root@crownbay:~# opcontrol --start-daemon
-            </literallayout>
-            Now, start the oprofile UI on the host system:
-            <literallayout class='monospaced'>
-     [trz@empanada oprofileui]$ oprofile-viewer
-            </literallayout>
-            To run a profile on the remote system, first connect to the
-            remote system by pressing the 'Connect' button and supplying
-            the IP address and port of the remote system (the default
-            port is 4224).
-        </para>
-
-        <para>
-            The oprofile server should automatically be started already.
-            If not, the connection will fail and you either typed in the
-            wrong IP address and port (see below), or you need to start
-            the server yourself:
-            <literallayout class='monospaced'>
-     root@crownbay:~# oprofile-server
-            </literallayout>
-            Or, to specify a specific port:
-            <literallayout class='monospaced'>
-     root@crownbay:~# oprofile-server --port 8888
-            </literallayout>
-            Once connected, press the 'Start' button and then run the
-            wget workload on the remote system:
-            <literallayout class='monospaced'>
-     root@crownbay:~# rm linux-2.6.19.2.tar.bz2; wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>; sync
-     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
-     linux-2.6.19.2.tar.b 100% |*******************************| 41727k  0:00:00 ETA
-            </literallayout>
-            Once the workload completes, press the 'Stop' button. At that
-            point the OProfile viewer will download the profile files it's
-            collected (this may take some time, especially if the kernel
-            was profiled). While it downloads the files, you should see
-            something like the following:
-        </para>
-
-        <para>
-            <imagedata fileref="figures/oprofileui-downloading.png" width="6in" depth="7in" align="center" scalefit="1" />
-        </para>
-
-        <para>
-            Once the profile files have been retrieved, you should see a
-            list of the processes that were profiled:
-        </para>
-
-        <para>
-            <imagedata fileref="figures/oprofileui-processes.png" width="6in" depth="7in" align="center" scalefit="1" />
-        </para>
-
-        <para>
-            If you select one of them, you should see all the symbols that
-            were hit during the profile. Selecting one of them will show a
-            list of callers and callees of the chosen function in two
-            panes below the top pane. For example, here's what we see
-            when we select __copy_to_user_ll():
-        </para>
-
-        <para>
-            <imagedata fileref="figures/oprofileui-copy-to-user.png" width="6in" depth="7in" align="center" scalefit="1" />
-        </para>
-
-        <para>
-            As another example, we can look at the busybox process and see
-            that the progress meter made a system call:
-        </para>
-
-        <para>
-            <imagedata fileref="figures/oprofileui-busybox.png" width="6in" depth="7in" align="center" scalefit="1" />
-        </para>
-    </section>
-
-    <section id='oprofile-documentation'>
-        <title>Documentation</title>
-
-        <para>
-            Yocto already has some information on setting up and using
-            OProfile and oprofileui. As this document doesn't cover
-            everything in detail, it may be worth taking a look at the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-oprofile'>Profiling with OProfile</ulink>"
-            section in the Yocto Project Development Manual
-        </para>
-
-        <para>
-            The OProfile manual can be found here:
-            <ulink url='http://oprofile.sourceforge.net/doc/index.html'>OProfile manual</ulink>
-        </para>
-
-        <para>
-            The OProfile website contains links to the above manual and
-            bunch of other items including an extensive set of examples:
-            <ulink url='http://oprofile.sourceforge.net/about/'>About OProfile</ulink>
-        </para>
-    </section>
-</section>
-
 <section id='profile-manual-sysprof'>
     <title>Sysprof</title>
 

yocto-poky/documentation/profile-manual/profile-manual.xml

diff --git a/yocto-poky/documentation/profile-manual/profile-manual.xml b/yocto-poky/documentation/profile-manual/profile-manual.xml
index 7f9b2c4..1e0ccc1 100644
--- a/yocto-poky/documentation/profile-manual/profile-manual.xml
+++ b/yocto-poky/documentation/profile-manual/profile-manual.xml
@@ -66,6 +66,11 @@
                 <date>October 2015</date>
                 <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>April 2016</date>
+                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

yocto-poky/documentation/ref-manual/closer-look.xml

diff --git a/yocto-poky/documentation/ref-manual/closer-look.xml b/yocto-poky/documentation/ref-manual/closer-look.xml
index 45dcd9b..84ff584 100644
--- a/yocto-poky/documentation/ref-manual/closer-look.xml
+++ b/yocto-poky/documentation/ref-manual/closer-look.xml
@@ -73,7 +73,7 @@
         </para>
 
         <para>
-            <imagedata fileref="figures/user-configuration.png" align="center" width="5.5in" depth="3.5in" />
+            <imagedata fileref="figures/user-configuration.png" align="center" />
         </para>
 
         <para>
@@ -100,7 +100,7 @@
         </para>
 
         <para>
-            The <filename>meta-yocto</filename> layer inside Poky contains
+            The <filename>meta-poky</filename> layer inside Poky contains
             a <filename>conf</filename> directory that has example
             configuration files.
             These example files are used as a basis for creating actual
@@ -158,7 +158,7 @@
             To see the default configurations in a <filename>local.conf</filename>
             file created by the build environment script, see the
             <filename>local.conf.sample</filename> in the
-            <filename>meta-yocto</filename> layer:
+            <filename>meta-poky</filename> layer:
             <itemizedlist>
                 <listitem><para><emphasis>Parallelism Options:</emphasis>
                     Controlled by the
@@ -208,8 +208,10 @@
             The files <filename>site.conf</filename> and
             <filename>auto.conf</filename> are not created by the environment
             initialization script.
-            If you want these configuration files, you must create them
-            yourself:
+            If you want the <filename>site.conf</filename> file, you need to
+            create that yourself.
+            The <filename>auto.conf</filename> file is typically created by
+            an autobuilder:
             <itemizedlist>
                 <listitem><para><emphasis><filename>site.conf</filename>:</emphasis>
                     You can use the <filename>conf/site.conf</filename>
@@ -235,8 +237,7 @@
                     directory's <filename>conf/local.conf</filename> file.
                     </para></listitem>
                 <listitem><para><emphasis><filename>auto.conf</filename>:</emphasis>
-                    This file is not hand-created.
-                    Rather, the file is usually created and written to by
+                    The file is usually created and written to by
                     an autobuilder.
                     The settings put into the file are typically the same as
                     you would find in the <filename>conf/local.conf</filename>
@@ -254,9 +255,24 @@
 
         <para>
             When you launch your build with the
-            <filename>bitbake <replaceable>target</replaceable></filename> command, BitBake
-            sorts out the configurations to ultimately define your build
-            environment.
+            <filename>bitbake <replaceable>target</replaceable></filename>
+            command, BitBake sorts out the configurations to ultimately
+            define your build environment.
+            It is important to understand that the OpenEmbedded build system
+            reads the configuration files in a specific order:
+            <filename>site.conf</filename>, <filename>auto.conf</filename>,
+            and <filename>local.conf</filename>.
+            And, the build system applies the normal assignment statement
+            rules.
+            Because the files are parsed in a specific order, variable
+            assignments for the same variable could be affected.
+            For example, if the <filename>auto.conf</filename> file and
+            the <filename>local.conf</filename> set
+            <replaceable>variable1</replaceable> to different values, because
+            the build system parses <filename>local.conf</filename> after
+            <filename>auto.conf</filename>,
+            <replaceable>variable1</replaceable> is assigned the value from
+            the <filename>local.conf</filename> file.
         </para>
     </section>
 
@@ -992,11 +1008,13 @@
 
             <para>
                 The image generation process consists of several stages and
-                depends on many variables.
+                depends on several tasks and variables.
                 The
                 <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
-                task uses these key variables
-                to help create the list of packages to actually install:
+                task creates the root filesystem (file and directory structure)
+                for an image.
+                This task uses several key variables to help create the list
+                of packages to actually install:
                 <itemizedlist>
                     <listitem><para><link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>:
                         Lists out the base set of packages to install from
@@ -1016,23 +1034,34 @@
                         Determines the language(s) for which additional
                         language support packages are installed.
                         </para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>:
+                        The final list of packages passed to the package manager
+                        for installation into the image.
+                        </para></listitem>
                 </itemizedlist>
             </para>
 
             <para>
+                With
+                <link linkend='var-IMAGE_ROOTFS'><filename>IMAGE_ROOTFS</filename></link>
+                pointing to the location of the filesystem under construction and
+                the <filename>PACKAGE_INSTALL</filename> variable providing the
+                final list of packages to install, the root file system is
+                created.
+            </para>
+
+            <para>
                 Package installation is under control of the package manager
                 (e.g. smart/rpm, opkg, or apt/dpkg) regardless of whether or
                 not package management is enabled for the target.
                 At the end of the process, if package management is not
                 enabled for the target, the package manager's data files
                 are deleted from the root filesystem.
-            </para>
-
-            <para>
-                During image generation, the build system attempts to run
-                all post-installation scripts.
-                Any that fail to run on the build host are run on the
-                target when the target system is first booted.
+                As part of the final stage of package installation, postinstall
+                scripts that are part of the packages are run.
+                Any scripts that fail to run
+                on the build host are run on the target when the target system
+                is first booted.
                 If you are using a
                 <ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>read-only root filesystem</ulink>,
                 all the post installation scripts must succeed during the
@@ -1041,24 +1070,17 @@
             </para>
 
             <para>
-                During Optimization, optimizing processes are run across
-                the image.
-                These processes include <filename>mklibs</filename> and
-                <filename>prelink</filename>.
-                The <filename>mklibs</filename> process optimizes the size
-                of the libraries.
-                A <filename>prelink</filename> process optimizes the dynamic
-                linking of shared libraries to reduce start up time of
-                executables.
+                The final stages of the <filename>do_rootfs</filename> task
+                handle post processing.
+                Post processing includes creation of a manifest file and
+                optimizations.
             </para>
 
             <para>
-                Along with writing out the root filesystem image, the
-                <filename>do_rootfs</filename> task creates a manifest file
-                (<filename>.manifest</filename>) in the same directory as
-                the root filesystem image that lists out, line-by-line, the
-                installed packages.
-                This manifest file is useful for the
+                The manifest file (<filename>.manifest</filename>) resides
+                in the same directory as the root filesystem image.
+                This file lists out, line-by-line, the installed packages.
+                The manifest file is useful for the
                 <link linkend='ref-classes-testimage*'><filename>testimage</filename></link>
                 class, for example, to determine whether or not to run
                 specific tests.
@@ -1068,21 +1090,54 @@
             </para>
 
             <para>
-                Part of the image generation process includes compressing the
-                root filesystem image.
-                Compression is accomplished through several optimization
-                routines designed to reduce the overall size of the image.
+                Optimizing processes run across the image include
+                <filename>mklibs</filename>, <filename>prelink</filename>,
+                and any other post-processing commands as defined by the
+                <link linkend='var-ROOTFS_POSTPROCESS_COMMAND'><filename>ROOTFS_POSTPROCESS_COMMAND</filename></link>
+                variable.
+                The <filename>mklibs</filename> process optimizes the size
+                of the libraries, while the
+                <filename>prelink</filename> process optimizes the dynamic
+                linking of shared libraries to reduce start up time of
+                executables.
             </para>
 
             <para>
-                After the root filesystem has been constructed, the image
-                generation process turns everything into an image file or
-                a set of image files.
+                After the root filesystem is built, processing begins on
+                the image through the <filename>do_image</filename> task.
+                The build system runs any pre-processing commands as defined
+                by the
+                <link linkend='var-IMAGE_PREPROCESS_COMMAND'><filename>IMAGE_PREPROCESS_COMMAND</filename></link>
+                variable.
+                This variable specifies a list of functions to call before
+                the OpenEmbedded build system creates the final image output
+                files.
+            </para>
+
+            <para>
+                The <filename>do_image</filename> task dynamically creates
+                other <filename>do_image_*</filename> tasks as needed, which
+                include compressing the root filesystem image to reduce the
+                overall size of the image.
+                The process turns everything into an image file or a set of
+                image files.
                 The formats used for the root filesystem depend on the
                 <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
                 variable.
             </para>
 
+            <para>
+                The final task involved in image creation is the
+                <filename>do_image_complete</filename> task.
+                This task completes the image by applying any image
+                post processing as defined through the
+                <link linkend='var-IMAGE_POSTPROCESS_COMMAND'><filename>IMAGE_POSTPROCESS_COMMAND</filename></link>
+                variable.
+                The variable specifies a list of functions to call once the
+                OpenEmbedded build system has created the final image output
+                files.
+            </para>
+
             <note>
                 The entire image generation process is run under Pseudo.
                 Running under Pseudo ensures that the files in the root
@@ -1095,8 +1150,9 @@
 
             <para>
                 The OpenEmbedded build system uses BitBake to generate the
-                Software Development Kit (SDK) installer script:
-                <imagedata fileref="figures/sdk-generation.png" align="center" width="6in" depth="7in" />
+                Software Development Kit (SDK) installer script for both the
+                standard and extensible SDKs:
+                <imagedata fileref="figures/sdk-generation.png" align="center" />
             </para>
 
             <note>
@@ -1108,14 +1164,16 @@
                 cross-development toolchain using the
                 <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
                 task, see the
-                "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-                section in the Yocto Project Application Developer's Guide.
+                "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+                section in the Yocto Project Software Development Kit (SDK)
+                Developer's Guide.
             </note>
 
             <para>
                 Like image generation, the SDK script process consists of
                 several stages and depends on many variables.
-                The <filename>do_populate_sdk</filename> task uses these
+                The <filename>do_populate_sdk</filename> and
+                <filename>do_populate_sdk_ext</filename> tasks use these
                 key variables to help create the list of packages to actually
                 install.
                 For information on the variables listed in the figure, see the
@@ -1124,8 +1182,9 @@
             </para>
 
             <para>
-                The <filename>do_populate_sdk</filename> task handles two
-                parts: a target part and a host part.
+                The <filename>do_populate_sdk</filename> task helps create
+                the standard SDK and handles two parts: a target part and a
+                host part.
                 The target part is the part built for the target hardware and
                 includes libraries and headers.
                 The host part is the part of the SDK that runs on the
@@ -1133,16 +1192,19 @@
             </para>
 
             <para>
-                Once both parts are constructed, the
-                <filename>do_populate_sdk</filename> task performs some cleanup
-                on both parts.
-                After the cleanup, the task creates a cross-development
-                environment setup script and any configuration files that
-                might be needed.
+                The <filename>do_populate_sdk_ext</filename> task helps create
+                the extensible SDK and handles host and target parts
+                differently than its counter part does for the standard SDK.
+                For the extensible SDK, the task encapsulates the build system,
+                which includes everything needed (host and target) for the SDK.
             </para>
 
             <para>
-                The final output of the task is the Cross-development
+                Regardless of the type of SDK being constructed, the
+                tasks perform some cleanup after which a cross-development
+                environment setup script and any needed configuration files
+                are created.
+                The final output is the Cross-development
                 toolchain installation script (<filename>.sh</filename> file),
                 which includes the environment setup script.
             </para>
@@ -1239,8 +1301,13 @@
             <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
             the output labeled "Application Development SDK" represents an
             SDK.
+            The SDK generation process differs depending on whether you build
+            a standard SDK
+            (e.g. <filename>bitbake -c populate_sdk</filename> <replaceable>imagename</replaceable>)
+            or an extensible SDK
+            (e.g. <filename>bitbake -c populate_sdk_ext</filename> <replaceable>imagename</replaceable>).
             This section is going to take a closer look at this output:
-            <imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" />
+            <imagedata fileref="figures/sdk.png" align="center" width="9in" depth="7.25in" />
         </para>
 
         <para>
@@ -1255,20 +1322,16 @@
             part because it runs on the SDK machine.
             You can think of the libraries and headers as the "target"
             part because they are built for the target hardware.
-            The setup script is added so that you can initialize the
-            environment before using the tools.
+            The environment setup script is added so that you can initialize
+            the environment before using the tools.
         </para>
 
         <note>
             <para>
                 The Yocto Project supports several methods by which you can
                 set up this cross-development environment.
-                These methods include downloading pre-built SDK installers,
-                building and installing your own SDK installer, or running
-                an Application Development Toolkit (ADT) installer to
-                install not just cross-development toolchains
-                but also additional tools to help in this type of
-                development.
+                These methods include downloading pre-built SDK installers
+                or building and installing your own SDK installer.
             </para>
 
             <para>
@@ -1278,8 +1341,7 @@
                 section.
                 For information on setting up a cross-development
                 environment, see the
-                "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
-                section in the Yocto Project Application Developer's Guide.
+                <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
             </para>
         </note>
 
@@ -1288,7 +1350,10 @@
             <filename>deploy/sdk</filename> folder inside the
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             as shown in the figure at the beginning of this section.
-            Several variables exist that help configure these files:
+            Depending on the type of SDK, several variables exist that help
+            configure these files.
+            The following list shows the variables associated with a standard
+            SDK:
             <itemizedlist>
                 <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
                     Points to the <filename>deploy</filename>
@@ -1322,6 +1387,36 @@
                     installation script.
                     </para></listitem>
             </itemizedlist>
+            This next list, shows the variables associated with an extensible
+            SDK:
+            <itemizedlist>
+                <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
+                    Points to the <filename>deploy</filename> directory.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_EXT_TYPE'><filename>SDK_EXT_TYPE</filename></link>:
+                    Controls whether or not shared state artifacts are copied
+                    into the extensible SDK.
+                    By default, all required shared state artifacts are copied
+                    into the SDK.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_INCLUDE_PKGDATA'><filename>SDK_INCLUDE_PKGDATA</filename></link>:
+                    Specifies whether or not packagedata will be included in
+                    the extensible SDK for all recipes in the "world" target.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_LOCAL_CONF_WHITELIST'><filename>SDK_LOCAL_CONF_WHITELIST</filename></link>:
+                    A list of variables allowed through from the build system
+                    configuration into the extensible SDK configuration.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></link>:
+                    A list of variables not allowed through from the build
+                    system configuration into the extensible SDK configuration.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></link>:
+                    A list of classes to remove from the
+                    <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
+                    value globally within the extensible SDK configuration.
+                    </para></listitem>
+            </itemizedlist>
         </para>
     </section>
 

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

diff --git a/yocto-poky/documentation/ref-manual/faq.xml b/yocto-poky/documentation/ref-manual/faq.xml
index 197d490..d2e4e8e 100644
--- a/yocto-poky/documentation/ref-manual/faq.xml
+++ b/yocto-poky/documentation/ref-manual/faq.xml
@@ -280,23 +280,42 @@
 
     <qandaentry>
         <question>
-            <para>
+            <para id='i-am-behind-a-firewall-and-need-to-use-a-proxy-server'>
                 I'm behind a firewall and need to use a proxy server. How do I do that?
             </para>
         </question>
         <answer>
             <para>
-                Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
-                and you therefore need to specify the proxy settings in a
-                <filename>.wgetrc</filename> file in your home directory.
-                Here are some example settings:
+                Most source fetching by the OpenEmbedded build system is done
+                by <filename>wget</filename> and you therefore need to specify
+                the proxy settings in a <filename>.wgetrc</filename> file,
+                which can be in your home directory if you are a single user
+                or can be in <filename>/usr/local/etc/wgetrc</filename> as
+                a global user file.
+            </para>
+
+            <para>
+                Following is the applicable code for setting various proxy
+                types in the <filename>.wgetrc</filename> file.
+                By default, these settings are disabled with comments.
+                To use them, remove the comments:
                 <literallayout class='monospaced'>
-     http_proxy = http://proxy.yoyodyne.com:18023/
-     ftp_proxy = http://proxy.yoyodyne.com:18023/
+     # You can set the default proxies for Wget to use for http, https, and ftp.
+     # They will override the value in the environment.
+     #https_proxy = http://proxy.yoyodyne.com:18023/
+     #http_proxy = http://proxy.yoyodyne.com:18023/
+     #ftp_proxy = http://proxy.yoyodyne.com:18023/
+
+     # If you do not want to use proxy at all, set this to off.
+     #use_proxy = on
                 </literallayout>
                 The Yocto Project also includes a
-                <filename>site.conf.sample</filename> file that shows how to
-                configure CVS and Git proxy servers if needed.
+                <filename>meta-poky/conf/site.conf.sample</filename> file that
+                shows how to configure CVS and Git proxy servers if needed.
+                For more information on setting up various proxy types and
+                configuring proxy servers, see the
+                "<ulink url='&YOCTO_WIKI_URL;/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
+                Wiki page.
             </para>
         </answer>
     </qandaentry>
@@ -367,7 +386,7 @@
 
             <para>
                 This issue is just a single manifestation of "system
-                leakage" issues caused when the OpenEbedded build system
+                leakage" issues caused when the OpenEmbedded build system
                 finds and uses previously installed files during a native
                 build.
                 This type of issue might not be limited to
@@ -782,7 +801,7 @@
     <qandaentry>
         <question>
             <para>
-                The files provided by my <filename>-native</filename> recipe do
+                The files provided by my <filename>*-native</filename> recipe do
                 not appear to be available to other recipes.
                 Files are missing from the native sysroot, my recipe is
                 installing to the wrong place, or I am getting permissions

yocto-poky/documentation/ref-manual/figures/image-generation.png

diff --git a/yocto-poky/documentation/ref-manual/figures/image-generation.png b/yocto-poky/documentation/ref-manual/figures/image-generation.png
index ab96258..71a48dc 100644
--- a/yocto-poky/documentation/ref-manual/figures/image-generation.png
+++ b/yocto-poky/documentation/ref-manual/figures/image-generation.png
Binary files differ

yocto-poky/documentation/ref-manual/figures/sdk-generation.png

diff --git a/yocto-poky/documentation/ref-manual/figures/sdk-generation.png b/yocto-poky/documentation/ref-manual/figures/sdk-generation.png
old mode 100644
new mode 100755
index c37e274..adbe1f4
--- a/yocto-poky/documentation/ref-manual/figures/sdk-generation.png
+++ b/yocto-poky/documentation/ref-manual/figures/sdk-generation.png
Binary files differ

yocto-poky/documentation/ref-manual/figures/sdk.png

diff --git a/yocto-poky/documentation/ref-manual/figures/sdk.png b/yocto-poky/documentation/ref-manual/figures/sdk.png
index a539cc5..5c36b75 100644
--- a/yocto-poky/documentation/ref-manual/figures/sdk.png
+++ b/yocto-poky/documentation/ref-manual/figures/sdk.png
Binary files differ

yocto-poky/documentation/ref-manual/figures/user-configuration.png

diff --git a/yocto-poky/documentation/ref-manual/figures/user-configuration.png b/yocto-poky/documentation/ref-manual/figures/user-configuration.png
old mode 100644
new mode 100755
index f2b3f8e..c298401
--- a/yocto-poky/documentation/ref-manual/figures/user-configuration.png
+++ b/yocto-poky/documentation/ref-manual/figures/user-configuration.png
Binary files differ

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

diff --git a/yocto-poky/documentation/ref-manual/introduction.xml b/yocto-poky/documentation/ref-manual/introduction.xml
index 0b16544..ce8fa5c 100644
--- a/yocto-poky/documentation/ref-manual/introduction.xml
+++ b/yocto-poky/documentation/ref-manual/introduction.xml
@@ -9,19 +9,26 @@
     <title>Introduction</title>
 
     <para>
-        This manual provides reference information for the current release of the Yocto Project.
-        The Yocto Project is an open-source collaboration project focused on embedded Linux
-        developers.
-        Amongst other things, the Yocto Project uses the OpenEmbedded build system, which
-        is based on the Poky project, to construct complete Linux images.
-        You can find complete introductory and getting started information on the Yocto Project
-        by reading the
+        This manual provides reference information for the current release
+        of the Yocto Project.
+        The Yocto Project is an open-source collaboration project focused
+        on embedded Linux developers.
+        Amongst other things, the Yocto Project uses the OpenEmbedded build
+        system, which is based on the Poky project, to construct complete
+        Linux images.
+        You can find complete introductory and getting started information
+        on the Yocto Project by reading the
         <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
+    </para>
+
+    <para>
         For task-based information using the Yocto Project, see the
         <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
         and the <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
         For Board Support Package (BSP) structure information, see the
         <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+        For information on how to use a Software Development Kit, (SDK), see the
+        <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
         You can find information on tracing and profiling in the
         <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>.
         For information on BitBake, which is the task execution tool the
@@ -40,7 +47,7 @@
             <listitem><para><emphasis>
                 <link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis>
                 Provides an overview of the components that make up the Yocto Project
-                followed by information about debugging images created in the Yocto Project.
+                followed by information about debugng images created in the Yocto Project.
                 </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='closer-look'>A Closer Look at the Yocto Project Development Environment</link>:</emphasis>
@@ -192,10 +199,6 @@
             supported Linux distribution, instances might exist where you
             encounter a problem while using the Yocto Project on a specific
             distribution.
-            For example, the CentOS 6.4 distribution does not include the
-            Gtk+ 2.20.0 and PyGtk 2.21.0 (or higher) packages, which are
-            required to run
-            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>.
         </note>
     </section>
 
@@ -249,9 +252,9 @@
                         <literallayout class='monospaced'>
      $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
                         Packages needed if you are going to be using the
-                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        the standard or extensible SDK:
                         <literallayout class='monospaced'>
      $ sudo apt-get install autoconf automake libtool libglib2.0-dev libarchive-dev
                         </literallayout></para></listitem>
@@ -293,9 +296,9 @@
      $ sudo dnf install make docbook-style-dsssl docbook-style-xsl \
      docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
                         Packages needed if you are going to be using the
-                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        standard or extensible SDK:
                         <literallayout class='monospaced'>
      $ sudo dnf install autoconf automake libtool glib2-devel libarchive-devel
                         </literallayout></para></listitem>
@@ -336,9 +339,9 @@
                         <literallayout class='monospaced'>
      $ sudo zypper install make fop xsltproc dblatex xmlto
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
                         Packages needed if you are going to be using the
-                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        standard or extensible SDK:
                         <literallayout class='monospaced'>
      $ sudo zypper install autoconf automake libtool glib2-devel libarchive-devel
                         </literallayout></para></listitem>
@@ -359,14 +362,14 @@
                 The following list shows the required packages by function
                 given a supported CentOS Linux distribution:
                 <note>
-                    For CentOS 6.x, some of the versions
-                    of the components provided by the distribution are
-                    too old (e.g. Git, Python, and tar).
-                    It is recommended that you install the buildtools
-                    in order to provide versions that will work with
-                    the OpenEmbedded build system.
-                    For information on how to install the buildtools
-                    tarball, see the
+                    For CentOS 6.x, some of the versions of the components
+                    provided by the distribution are too old (e.g. Git, Python,
+                    and tar).
+                    It is recommended that you install the buildtools in order
+                    to provide versions that will work with the OpenEmbedded
+                    build system.
+                    For information on how to install the buildtools tarball,
+                    see the
                     "<link linkend='required-git-tar-and-python-versions'>Required Git, Tar, and Python Versions</link>"
                     section.
                 </note>
@@ -391,21 +394,12 @@
      $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
      docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
                         Packages needed if you are going to be using the
-                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        standard or extensible SDK:
                         <literallayout class='monospaced'>
      $ sudo yum install autoconf automake libtool glib2-devel libarchive-devel
-                        </literallayout>
-                        <note>
-                            For CentOS 6.x, in order for the
-                            ADT installer script to work, you must have
-                            installed the <filename>liblzma5</filename>,
-                            <filename>libarchive3.x</filename>, and
-                            <filename>libarchive-devel-3.1.3</filename>
-                            (or older) packages, in that order.
-                        </note>
-                        </para></listitem>
+                        </literallayout></para></listitem>
                     <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
                         Packages needed if you are going to run
                         <filename>oe-selftest</filename>:
@@ -426,7 +420,7 @@
             must meet the following version requirements for Git, tar, and
             Python:
             <itemizedlist>
-                <listitem><para>Git 1.7.8 or greater</para></listitem>
+                <listitem><para>Git 1.8.3.1 or greater</para></listitem>
                 <listitem><para>tar 1.24 or greater</para></listitem>
                 <listitem><para>Python 2.7.3 or greater not including
                     Python 3.x, which is not supported.</para></listitem>
@@ -597,8 +591,8 @@
             <listitem><para><emphasis>Nightly Builds:</emphasis> These
                 tarball releases are available at
                 <ulink url='&YOCTO_AB_NIGHTLY_URL;'/>.
-                These builds include Yocto Project releases, meta-toolchain
-                tarball installation scripts, and experimental builds.
+                These builds include Yocto Project releases, SDK installation
+                scripts, and experimental builds.
                 </para></listitem>
             <listitem><para><emphasis>Yocto Project Website:</emphasis> You can
                 find tarball releases of the Yocto Project and supported BSPs

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

diff --git a/yocto-poky/documentation/ref-manual/migration.xml b/yocto-poky/documentation/ref-manual/migration.xml
index 21763e3..e6c0aa3 100644
--- a/yocto-poky/documentation/ref-manual/migration.xml
+++ b/yocto-poky/documentation/ref-manual/migration.xml
@@ -97,13 +97,14 @@
 
             <para>
                 The shared state cache (sstate-cache), as pointed to by
-                <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>, by default
-                now has two-character subdirectories to prevent issues arising
-                from too many files in the same directory.
-                Also, native sstate-cache packages will go into a subdirectory named using
+                <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
+                by default now has two-character subdirectories to prevent
+                issues arising from too many files in the same directory.
+                Also, native sstate-cache packages, which are built to run
+                on the host system, will go into a subdirectory named using
                 the distro ID string.
-                If you copy the newly structured sstate-cache to a mirror location
-                (either local or remote) and then point to it in
+                If you copy the newly structured sstate-cache to a mirror
+                location (either local or remote) and then point to it in
                 <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>,
                 you need to append "PATH" to the end of the mirror URL so that
                 the path used by BitBake before the mirror substitution is
@@ -124,7 +125,7 @@
                 reference hardware Board Support Packages (BSPs), respectively:
                 <filename>meta-yocto</filename> and
                 <filename>meta-yocto-bsp</filename>.
-                When running BitBake or Hob for the first time after upgrading,
+                When running BitBake for the first time after upgrading,
                 your <filename>conf/bblayers.conf</filename> file will be
                 updated to handle this change and you will be asked to
                 re-run or restart for the changes to take effect.
@@ -191,8 +192,10 @@
                 The suffix <filename>nativesdk</filename> is now implemented
                 as a prefix, which simplifies a lot of the packaging code for
                 <filename>nativesdk</filename> recipes.
-                All custom <filename>nativesdk</filename> recipes and any
-                references need to be updated to use
+                All custom <filename>nativesdk</filename> recipes, which are
+                relocatable packages that are native to
+                <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>,
+                and any references need to be updated to use
                 <filename>nativesdk-*</filename> instead of
                 <filename>*-nativesdk</filename>.
             </para>
@@ -1443,18 +1446,6 @@
         </section>
     </section>
 
-    <section id='migration-1.6-directory-layout-changes'>
-        <title>Directory Layout Changes</title>
-
-        <para>
-            The <filename>meta-hob</filename> layer has been removed from
-            the top-level of the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-            The contents of this layer are no longer needed by the Hob
-            user interface for building images and toolchains.
-        </para>
-    </section>
-
     <section id='migration-1.6-package-test-ptest'>
         <title>Package Test (ptest)</title>
 
@@ -2456,9 +2447,10 @@
                     </literallayout>
                     </para></listitem>
                 <listitem><para>
-                    <filename>d.delVar('VARNAME')</filename> and
-                    <filename>d.setVar('VARNAME', None)</filename> result
-                    in the variable and all of its overrides being cleared out.
+                    <filename>d.delVar('</filename><replaceable>varname</replaceable><filename>')</filename> and
+                    <filename>d.setVar('</filename><replaceable>varname</replaceable><filename>', None)</filename>
+                    result in the variable and all of its overrides being
+                    cleared out.
                     Before the change, only the non-overridden values
                     were cleared.
                     </para></listitem>
@@ -2735,6 +2727,558 @@
     </section>
 </section>
 
+<section id='moving-to-the-yocto-project-2.1-release'>
+    <title>Moving to the Yocto Project 2.1 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 2.1 Release from the prior release.
+    </para>
+
+    <section id='migration-2.1-variable-expansion-in-python-functions'>
+        <title>Variable Expansion in Python Functions</title>
+
+        <para>
+            Variable expressions, such as
+            <filename>${</filename><replaceable>varname</replaceable><filename>}</filename>
+            no longer expand automatically within Python functions.
+            Suppressing expansion was done to allow Python functions to
+            construct shell scripts or other code for situations in which you
+            do not want such expressions expanded.
+            For any existing code that relies on these expansions, you need to
+            change the expansions to either expand the value of individual
+            variables through <filename>d.getVar()</filename>.
+            To alternatively expand more complex expressions,
+            use <filename>d.expand()</filename>.
+        </para>
+    </section>
+
+    <section id='migration-2.1-overrides-must-now-be-lower-case'>
+        <title>Overrides Must Now be Lower-Case</title>
+
+        <para>
+            The convention for overrides has always been for them to be
+            lower-case characters.
+            This practice is now a requirement as BitBake's datastore now
+            assumes lower-case characters in order to give a slight performance
+            boost during parsing.
+            In practical terms, this requirement means that anything that ends
+            up in
+            <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+            must now appear in lower-case characters (e.g. values for
+            <filename>MACHINE</filename>, <filename>TARGET_ARCH</filename>,
+            <filename>DISTRO</filename>, and also recipe names if
+            <filename>_pn-</filename><replaceable>recipename</replaceable>
+            overrides are to be effective).
+        </para>
+    </section>
+
+    <section id='migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory'>
+        <title>Expand Parameter to <filename>getVar()</filename> and
+            <filename>getVarFlag()</filename> is Now Mandatory</title>
+
+        <para>
+            The expand parameter to <filename>getVar()</filename> and
+            <filename>getVarFlag()</filename> previously defaulted to
+            False if not specified.
+            Now, however, no default exists so one must be specified.
+            You must change any <filename>getVar()</filename> calls that
+            do not specify the final expand parameter to calls that do specify
+            the parameter.
+            You can run the following <filename>sed</filename> command at the
+            base of a layer to make this change:
+            <literallayout class='monospaced'>
+     sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *`
+     sed -e 's:\(\.getVarFlag([^,()]*, [^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *`
+            </literallayout>
+            <note>
+                The reason for this change is that it prepares the way for
+                changing the default to True in a future Yocto Project release.
+                This future change is a much more sensible default than False.
+                However, the change needs to be made gradually as a sudden
+                change of the default would potentially cause side-effects
+                that would be difficult to detect.
+            </note>
+        </para>
+    </section>
+
+    <section id='migration-2.1-makefile-environment-changes'>
+        <title>Makefile Environment Changes</title>
+
+        <para>
+            <link linkend='var-EXTRA_OEMAKE'><filename>EXTRA_OEMAKE</filename></link>
+            now defaults to "" instead of "-e MAKEFLAGS=".
+            Setting <filename>EXTRA_OEMAKE</filename> to "-e MAKEFLAGS=" by
+            default was a historical accident that has required many classes
+            (e.g. <filename>autotools</filename>, <filename>module</filename>)
+            and recipes to override this default in order to work with
+            sensible build systems.
+            When upgrading to the release, you must edit any recipe that
+            relies upon this old default by either setting
+            <filename>EXTRA_OEMAKE</filename> back to "-e MAKEFLAGS=" or by
+            explicitly setting any required variable value overrides using
+            <filename>EXTRA_OEMAKE</filename>, which is typically only needed
+            when a Makefile sets a default value for a variable that is
+            inappropriate for cross-compilation using the "=" operator rather
+            than the "?=" operator.
+        </para>
+    </section>
+
+    <section id='migration-2.1-libexecdir-reverted-to-prefix-libexec'>
+        <title><filename>libexecdir</filename> Reverted to <filename>${prefix}/libexec</filename></title>
+
+        <para>
+            The use of <filename>${libdir}/${BPN}</filename> as
+            <filename>libexecdir</filename> is different as compared to all
+            other mainstream distributions, which either uses
+            <filename>${prefix}/libexec</filename> or
+            <filename>${libdir}</filename>.
+            The use is also contrary to the GNU Coding Standards
+            (i.e. <ulink url='https://www.gnu.org/prep/standards/html_node/Directory-Variables.html'></ulink>)
+            that suggest <filename>${prefix}/libexec</filename> and also
+            notes that any package-specific nesting should be done by the
+            package itself.
+            Finally, having <filename>libexecdir</filename> change between
+            recipes makes it very difficult for different recipes to invoke
+            binaries that have been installed into
+            <filename>libexecdir</filename>.
+            The Filesystem Hierarchy Standard
+            (i.e. <ulink url='http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html'></ulink>)
+            now recognizes the use of <filename>${prefix}/libexec/</filename>,
+            giving distributions the choice between
+            <filename>${prefix}/lib</filename> or
+            <filename>${prefix}/libexec</filename> without breaking FHS.
+        </para>
+    </section>
+
+    <section id='migration-2.1-ac-cv-sizeof-off-t-no-longer-cached-in-site-files'>
+        <title><filename>ac_cv_sizeof_off_t</filename> is No Longer Cached in Site Files</title>
+
+        <para>
+            For recipes inheriting the
+            <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+            class, <filename>ac_cv_sizeof_off_t</filename> is no longer cached
+            in the site files for <filename>autoconf</filename>.
+            The reason for this change is because the
+            <filename>ac_cv_sizeof_off_t</filename> value is not necessarily
+            static per architecture as was previously assumed.
+            Rather, the value changes based on whether large file support is
+            enabled.
+            For most software that uses <filename>autoconf</filename>, this
+            change should not be a problem.
+            However, if you have a recipe that bypasses the standard
+            <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+            task from the <filename>autotools</filename> class and the software
+            the recipe is building uses a very old version of
+            <filename>autoconf</filename>, the recipe might be incapable of
+            determining the correct size of <filename>off_t</filename> during
+            <filename>do_configure</filename>.
+        </para>
+
+        <para>
+            The best course of action is to patch the software as necessary
+            to allow the default implementation from the
+            <filename>autotools</filename> class to work such that
+            <filename>autoreconf</filename> succeeds and produces a working
+            configure script), and to remove the
+            overridden <filename>do_configure</filename> task such that the
+            default implementation does get used.
+        </para>
+    </section>
+
+    <section id='migration-2.1-image-generation-split-out-from-filesystem-generation'>
+        <title>Image Generation is Now Split Out from Filesystem Generation</title>
+
+        <para>
+            Previously, for image recipes the
+            <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+            task assembled the filesystem and then from that filesystem
+            generated images.
+            With this Yocto Project release, image generation is split into
+            separate
+            <link linkend='ref-tasks-image'><filename>do_image_*</filename></link>
+            tasks for clarity both in operation and in the code.
+        </para>
+
+        <para>
+            For most cases, this change does not present any problems.
+            However, if you have made customizations that directly modify the
+            <filename>do_rootfs</filename> task or that mention
+            <filename>do_rootfs</filename>, you might need to update those
+            changes.
+            In particular, if you had added any tasks after
+            <filename>do_rootfs</filename>, you should make edits so that
+            those tasks are after the
+            <link linkend='ref-tasks-image-complete'><filename>do_image_complete</filename></link>
+            task rather than before the task so that the your added tasks
+            run at the correct time.
+        </para>
+
+        <para>
+            A minor part of this restructuring is that the post-processing
+            definitions and functions have been moved from the
+            <link linkend='ref-classes-image'><filename>image</filename></link>
+            class to the
+            <link linkend='ref-classes-rootfs*'><filename>rootfs-postcommands</filename></link>
+            class.
+            Functionally, however, they remain unchanged.
+        </para>
+    </section>
+
+    <section id='migration-2.1-removed-recipes'>
+        <title>Removed Recipes</title>
+
+        <para>
+            The following recipes have been removed in the 2.1 release:
+            <itemizedlist>
+                <listitem><para><filename>gcc</filename> version 4.8:
+                    Versions 4.9 and 5.3 remain.
+                    </para></listitem>
+                <listitem><para><filename>qt4</filename>:
+                    All support for Qt 4.x has been moved out to a separate
+                    <filename>meta-qt4</filename> layer because Qt 4 is no
+                    longer supported upstream.
+                    </para></listitem>
+                <listitem><para><filename>x11vnc</filename>:
+                    Moved to the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>linux-yocto-3.14</filename>:
+                    No longer supported.
+                    </para></listitem>
+                <listitem><para><filename>linux-yocto-3.19</filename>:
+                    No longer supported.
+                    </para></listitem>
+                <listitem><para><filename>libjpeg</filename>:
+                    Replaced by the <filename>libjpeg-turbo</filename> recipe.
+                    </para></listitem>
+                <listitem><para><filename>pth</filename>:
+                    Became obsolete.
+                    </para></listitem>
+                <listitem><para><filename>liboil</filename>:
+                    Recipe is no longer needed and has been moved to the
+                    <filename>meta-multimedia</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>gtk-theme-torturer</filename>:
+                    Recipe is no longer needed and has been moved to the
+                    <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>gnome-mime-data</filename>:
+                    Recipe is no longer needed and has been moved to the
+                    <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>udev</filename>:
+                    Replaced by the <filename>eudev</filename> recipe for
+                    compatibility when using <filename>sysvinit</filename>
+                    with newer kernels.
+                    </para></listitem>
+                <listitem><para><filename>python-pygtk</filename>:
+                    Recipe became obsolete.
+                    </para></listitem>
+                <listitem><para><filename>adt-installer</filename>:
+                    Recipe became obsolete.
+                    See the
+                    "<link linkend='migration-2.1-adt-removed'>ADT Removed</link>"
+                    section for more information.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-class-changes'>
+        <title>Class Changes</title>
+
+        <para>
+            The following classes have changed:
+            <itemizedlist>
+                <listitem><para><filename>autotools_stage</filename>:
+                    Removed because the
+                    <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+                    class now provides its functionality.
+                    Recipes that inherited from
+                    <filename>autotools_stage</filename> should now inherit
+                    from <filename>autotools</filename> instead.
+                    </para></listitem>
+                <listitem><para><filename>boot-directdisk</filename>:
+                    Merged into the
+                    <link linkend='ref-classes-image-vm'><filename>image-vm</filename></link>
+                    class.
+                    The <filename>boot-directdisk</filename> class was rarely
+                    directly used.
+                    Consequently, this change should not cause any issues.
+                    </para></listitem>
+                <listitem><para><filename>bootimg</filename>:
+                    Merged into the
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
+                    class.
+                    The <filename>bootimg</filename> class was rarely
+                    directly used.
+                    Consequently, this change should not cause any issues.
+                    </para></listitem>
+                <listitem><para><filename>packageinfo</filename>:
+                    Removed due to its limited use by the Hob UI, which has
+                    itself been removed.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-build-system-ui-changes'>
+        <title>Build System User Interface Changes</title>
+
+        <para>
+            The following changes have been made to the build system user
+            interface:
+            <itemizedlist>
+                <listitem><para><emphasis>Hob GTK+-based UI</emphasis>:
+                    Removed because it is unmaintained and based on the
+                    outdated GTK+ 2 library.
+                    The Toaster web-based UI is much more capable and is
+                    actively maintained.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_TOAST_URL;#using-the-toaster-web-interface'>Using the Toaster Web Interface</ulink>"
+                    section in the Yocto Project Toaster User Manual for more
+                    information on this interface.
+                    </para></listitem>
+                <listitem><para><emphasis>"puccho" BitBake UI</emphasis>:
+                    Removed because is unmaintained and no longer useful.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-adt-removed'>
+        <title>ADT Removed</title>
+
+        <para>
+            The Application Development Toolkit (ADT) has been removed
+            because its functionality almost completely overlapped with the
+            <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-using-the-standard-sdk'>standard SDK</ulink>
+            and the
+            <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>extensible SDK</ulink>.
+            For information on these SDKs and how to build and use them, see the
+            <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+        </para>
+    </section>
+
+    <section id='migration-2.1-poky-reference-distribution-changes'>
+        <title>Poky Reference Distribution Changes</title>
+
+        <para>
+            The following changes have been made for the Poky distribution:
+            <itemizedlist>
+                <listitem><para>
+                    The <filename>meta-yocto</filename> layer has been renamed
+                    to <filename>meta-poky</filename> to better match its
+                    purpose, which is to provide the Poky reference
+                    distribution.
+                    The <filename>meta-yocto-bsp</filename> layer retains its
+                    original name since it provides reference machines for
+                    the Yocto Project and it is otherwise unrelated to Poky.
+                    References to <filename>meta-yocto</filename> in your
+                    <filename>conf/bblayers.conf</filename> should
+                    automatically be updated, so you should not need to change
+                    anything unless you are relying on this naming elsewhere.
+                    </para></listitem>
+                <listitem><para>
+                    The
+                    <link linkend='ref-classes-uninative'><filename>uninative</filename></link>
+                    class is now enabled by default in Poky.
+                    This class attempts to isolate the build system from the
+                    host distribution's C library and makes re-use of native
+                    shared state artifacts across different host distributions
+                    practical.
+                    With this class enabled, a tarball containing a pre-built
+                    C library is downloaded at the start of the build.</para>
+
+                    <para>The <filename>uninative</filename> class is enabled
+                    through the
+                    <filename>meta/conf/distro/include/yocto-uninative.inc</filename>
+                    file, which for those not using the Poky distribution, can
+                    include to easily enable the same functionality.</para>
+
+                    <para>Alternatively, if you wish to build your own
+                    <filename>uninative</filename> tarball, you can do so by
+                    building the <filename>uninative-tarball</filename> recipe,
+                    making it available to your build machines
+                    (e.g. over HTTP/HTTPS) and setting a similar configuration
+                    as the one set by <filename>yocto-uninative.inc</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    Static library generation, for most cases, is now disabled
+                    by default in the Poky distribution.
+                    Disabling this generation saves some build time as well
+                    as the size used for build output artifacts.</para>
+
+                    <para>Disabling this library generation is accomplished
+                    through a
+                    <filename>meta/conf/distro/include/no-static-libs.inc</filename>,
+                    which for those not using the Poky distribution can
+                    easily include to enable the same functionality.</para>
+
+                    <para>Any recipe that needs to opt-out of having the
+                    "--disable-static" option specified on the configure
+                    command line either because it is not a supported option
+                    for the configure script or because static libraries are
+                    needed should set the following variable:
+                    <literallayout class='monospaced'>
+     DISABLE_STATIC = ""
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    The separate <filename>poky-tiny</filename> distribution
+                    now uses the musl C library instead of a heavily pared
+                    down <filename>glibc</filename>.
+                    Using <filename>glibc</filename> results in a smaller
+                    distribution and facilitates much greater maintainability
+                    because musl is designed to have a small footprint.</para>
+
+                    <para>If you have used <filename>poky-tiny</filename> and
+                    have customized the <filename>glibc</filename>
+                    configuration you will need to redo those customizations
+                    with musl when upgrading to the new release.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-packaging-changes'>
+        <title>Packaging Changes</title>
+
+        <para>
+            The following changes have been made to packaging:
+            <itemizedlist>
+                <listitem><para>
+                    The <filename>runuser</filename> and
+                    <filename>mountpoint</filename> binaries, which were
+                    previously in the main <filename>util-linux</filename>
+                    package, have been split out into the
+                    <filename>util-linux-runuser</filename> and
+                    <filename>util-linux-mountpoint</filename> packages,
+                    respectively.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>python-elementtree</filename> package has
+                    been merged into the <filename>python-xml</filename>
+                    package.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-tuning-file-changes'>
+        <title>Tuning File Changes</title>
+
+        <para>
+            The following changes have been made to the tuning files:
+            <itemizedlist>
+                <listitem><para>
+                    The "no-thumb-interwork" tuning feature has been dropped
+                    from the ARM tune include files.
+                    Because interworking is required for ARM EABI, attempting
+                    to disable it through a tuning feature no longer makes
+                    sense.
+                    <note>
+                        Support for ARM OABI was deprecated in gcc 4.7.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>tune-cortexm*.inc</filename> and
+                    <filename>tune-cortexr4.inc</filename> files have been
+                    removed because they are poorly tested.
+                    Until the OpenEmbedded build system officially gains
+                    support for CPUs without an MMU, these tuning files would
+                    probably be better maintained in a separate layer
+                    if needed.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-miscellaneous-changes'>
+        <title>Miscellaneous Changes</title>
+
+        <para>
+            These additional changes exist:
+            <itemizedlist>
+                <listitem><para>
+                    The minimum Git version has been increased to 1.8.3.1.
+                    If your host distribution does not provide a sufficiently
+                    recent version, you can install the buildtools, which
+                    will provide it.
+                    </para></listitem>
+                <listitem><para>
+                    The buggy and incomplete support for the RPM version 4
+                    package manager has been removed.
+                    The well-tested and maintained support for RPM version 5
+                    remains.
+                    </para></listitem>
+                <listitem><para>
+                    The
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component'><filename>devtool modify</filename></ulink>
+                    command now defaults to extracting the source since that
+                    is most commonly expected.
+                    The "-x" or "--extract" options are now no-ops.
+                    If you wish to provide your own existing source tree, you
+                    will now need to specify either the "-n" or
+                    "--no-extract" option when running
+                    <filename>devtool modify</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    If the formfactor for a machine is either not supplied
+                    or does not specify whether a keyboard is attached, then
+                    the default is to assume a keyboard is attached rather
+                    than assume no keyboard.
+                    <note>
+                        This change primarily affects the Sato UI.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>.debug</filename> directory packaging is
+                    now automatic.
+                    If your recipe builds software that installs binaries into
+                    directories other than the standard ones, you no longer
+                    need to take care of setting
+                    <filename>FILES_${PN}-dbg</filename> to pick up the
+                    resulting <filename>.debug</filename> directories as these
+                    directories are automatically found and added.
+                    </para></listitem>
+                <listitem><para>
+                    Inaccurate disk and CPU percentage data has been dropped
+                    from <filename>buildstats</filename> output.
+                    This data has been replaced with
+                    <filename>getrusage()</filename> data and corrected IO
+                    statistics.
+                    You will probably need to update code that reads the
+                    <filename>buildstats</filename> data.
+                    </para></listitem>
+                <listitem><para>
+                    The
+                    <filename>meta/conf/distro/include/package_regex.inc</filename>
+                    is now deprecated.
+                    The contents of this file have been moved to individual
+                    recipes.
+                    <note><title>Tip</title>
+                        Because this file will likely be removed in a future
+                        Yocto Project release, it is suggested that you remove
+                        any references to the file that might be in your
+                        configuration.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>v86d/uvesafb</filename> has been removed from
+                    the <filename>genericx86</filename> and
+                    <filename>genericx86-64</filename> reference machines,
+                    which are provided by the
+                    <filename>meta-yocto-bsp</filename> layer.
+                    Most modern x86 boards do not rely on this file and it only
+                    adds kernel error messages during startup.
+                    If you do still need the file, you can simply add
+                    <filename>v86d</filename> to your image.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
 
 </chapter>
 <!--

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

diff --git a/yocto-poky/documentation/ref-manual/ref-bitbake.xml b/yocto-poky/documentation/ref-manual/ref-bitbake.xml
index dc402db..1de1148 100644
--- a/yocto-poky/documentation/ref-manual/ref-bitbake.xml
+++ b/yocto-poky/documentation/ref-manual/ref-bitbake.xml
@@ -414,7 +414,7 @@
   -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
                         Show debug logging for the specified logging domains
   -P, --profile         Profile the command and save reports.
-  -u UI, --ui=UI        The user interface to use (e.g. knotty, hob, depexp).
+  -u UI, --ui=UI        The user interface to use (e.g. knotty and depexp).
   -t SERVERTYPE, --servertype=SERVERTYPE
                         Choose which server to use, process or xmlrpc.
   --revisions-changed   Set the exit code depending on whether upstream

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

diff --git a/yocto-poky/documentation/ref-manual/ref-classes.xml b/yocto-poky/documentation/ref-manual/ref-classes.xml
index b2941b8..e919bd7 100644
--- a/yocto-poky/documentation/ref-manual/ref-classes.xml
+++ b/yocto-poky/documentation/ref-manual/ref-classes.xml
@@ -128,8 +128,7 @@
     <para>
         By default, the <filename>autotools*</filename> classes
         use out-of-tree builds (i.e.
-        <filename>autotools.bbclass</filename> and
-        <filename>autotools_stage.bbclass</filename>).
+        <filename>autotools.bbclass</filename>).
         (<link linkend='var-B'><filename>B</filename></link> <filename>!=</filename>
         <link linkend='var-S'><filename>S</filename></link>).
     </para>
@@ -139,8 +138,7 @@
         using out-of-tree builds, you should have the recipe inherit the
         <filename>autotools-brokensep</filename> class.
         The <filename>autotools-brokensep</filename> class behaves the same
-        as the <filename>autotools</filename> and
-        <filename>autotools_stage</filename> classes but builds with
+        as the <filename>autotools</filename> class but builds with
         <link linkend='var-B'><filename>B</filename></link> ==
         <link linkend='var-S'><filename>S</filename></link>.
         This method is useful when out-of-tree build support is either not
@@ -201,6 +199,15 @@
     </para>
 </section>
 
+<section id='ref-classes-bash-completion'>
+    <title><filename>bash-completion.bbclass</filename></title>
+
+    <para>
+        Sets up packaging and dependencies appropriate for recipes that
+        build software that includes bash-completion data.
+    </para>
+</section>
+
 <section id='ref-classes-bin-package'>
     <title><filename>bin_package.bbclass</filename></title>
 
@@ -319,64 +326,6 @@
     </para>
 </section>
 
-<section id='ref-classes-boot-directdisk'>
-    <title><filename>boot-directdisk.bbclass</filename></title>
-
-    <para>
-        The <filename>boot-directdisk</filename> class
-        creates an image that can be placed directly onto a hard disk using
-        <filename>dd</filename> and then booted.
-        The image uses SYSLINUX.
-    </para>
-
-    <para>
-        The end result is a 512 boot sector populated with a
-        Master Boot Record (MBR) and partition table followed by an MSDOS
-        FAT16 partition containing SYSLINUX and a Linux kernel completed by
-        the <filename>ext2</filename> and <filename>ext3</filename>
-        root filesystems.
-    </para>
-</section>
-
-<section id='ref-classes-bootimg'>
-    <title><filename>bootimg.bbclass</filename></title>
-
-    <para>
-        The <filename>bootimg</filename> class creates a bootable
-        image using SYSLINUX, your kernel, and an optional initial RAM disk
-        (<filename>initrd</filename>).
-    </para>
-
-    <para>
-        When you use this class, two things happen:
-        <itemizedlist>
-            <listitem><para>
-                A <filename>.hddimg</filename> file is created.
-                This file is an MSDOS filesystem that contains SYSLINUX,
-                a kernel, an <filename>initrd</filename>, and a root filesystem
-                image.
-                All three of these can be written to hard drives directly and
-                also booted on a USB flash disks using <filename>dd</filename>.
-                </para></listitem>
-            <listitem><para>
-                A CD <filename>.iso</filename> image is created.
-                When this file is booted, the <filename>initrd</filename>
-                boots and processes the label selected in SYSLINUX.
-                Actions based on the label are then performed (e.g. installing
-                to a hard drive).</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        The <filename>bootimg</filename> class supports the
-        <link linkend='var-INITRD'><filename>INITRD</filename></link>,
-        <link linkend='var-NOISO'><filename>NOISO</filename></link>,
-        <link linkend='var-NOHDD'><filename>NOHDD</filename></link>, and
-        <link linkend='var-ROOTFS'><filename>ROOTFS</filename></link>
-        variables.
-    </para>
-</section>
-
 <section id='ref-classes-bugzilla'>
     <title><filename>bugzilla.bbclass</filename></title>
 
@@ -714,7 +663,9 @@
         provides for automatic checking for upstream recipe updates.
         The class creates a comma-separated value (CSV) spreadsheet that
         contains information about the recipes.
-        The information provides the <filename>do_distrodata</filename> and
+        The information provides the
+        <link linkend='ref-tasks-distrodata'><filename>do_distrodata</filename></link>
+        and
         <filename>do_distro_check</filename> tasks, which do upstream checking
         and also verify if a package is used in multiple major distributions.
     </para>
@@ -728,6 +679,13 @@
      INHERIT+= "distrodata"
         </literallayout>
     </para>
+
+    <para>
+        The <filename>distrodata</filename> class also provides the
+        <link linkend='ref-tasks-checkpkg'><filename>do_checkpkg</filename></link>
+        task, which can be used against a simple recipe or against an
+        image to get all its recipe information.
+    </para>
 </section>
 
 <section id='ref-classes-distutils'>
@@ -999,6 +957,28 @@
     </para>
 </section>
 
+<section id='ref-classes-gobject-introspection'>
+    <title><filename>gobject-introspection.bbclass</filename></title>
+
+    <para>
+        Provides support for recipes building software that
+        supports GObject introspection.
+        This functionality is only enabled if the
+        "gobject-introspection-data" feature is in
+        <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+        as well as "qemu-usermode" being in
+        <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>.
+        <note>
+            This functionality is backfilled by default and,
+            if not applicable, should be disabled through
+            <link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link>
+            or
+            <link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename></link>,
+            respectively.
+        </note>
+    </para>
+</section>
+
 <section id='ref-classes-grub-efi'>
     <title><filename>grub-efi.bbclass</filename></title>
 
@@ -1146,8 +1126,8 @@
     <title><filename>gzipnative.bbclass</filename></title>
 
     <para>
-        The <filename>gzipnative</filename>
-        class enables the use of native versions of <filename>gzip</filename>
+        The <filename>gzipnative</filename> class enables the use of
+        different native versions of <filename>gzip</filename>
         and <filename>pigz</filename> rather than the versions of these tools
         from the build host.
     </para>
@@ -2284,6 +2264,29 @@
     </para>
 </section>
 
+<section id='ref-classes-nopackages'>
+    <title><filename>nopackages.bbclass</filename></title>
+
+    <para>
+        Disables packaging tasks for those recipes and classes where
+        packaging is not needed.
+    </para>
+</section>
+
+<section id='ref-classes-npm'>
+    <title><filename>npm.bbclass</filename></title>
+
+    <para>
+        Provides support for building Node.js software fetched using the npm
+        package manager.
+        <note>
+            Currently, recipes inheriting this class must use the
+            <filename>npm://</filename> fetcher to have dependencies fetched
+            and packaged automatically.
+        </note>
+    </para>
+</section>
+
 <section id='ref-classes-oelint'>
     <title><filename>oelint.bbclass</filename></title>
 
@@ -2558,22 +2561,6 @@
     </para>
 </section>
 
-<section id='ref-classes-packageinfo'>
-    <title><filename>packageinfo.bbclass</filename></title>
-
-    <para>
-        The <filename>packageinfo</filename> class
-        gives a BitBake user interface the ability to retrieve information
-        about output packages from the <filename>pkgdata</filename> files.
-    </para>
-
-    <para>
-        This class is enabled automatically when using the
-        <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>
-        user interface.
-    </para>
-</section>
-
 <section id='ref-classes-patch'>
     <title><filename>patch.bbclass</filename></title>
 
@@ -2654,8 +2641,8 @@
         toolchain using the
         <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
         task, see the
-        "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-        section in the Yocto Project Application Developer's Guide.
+        "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+        section in the Yocto Project Software Development Kit (SDK) Developer's Guide.
     </para>
 </section>
 
@@ -2734,8 +2721,9 @@
         cross-development toolchain using the
         <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
         task, see the
-        "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-        section in the Yocto Project Application Developer's Guide.
+        "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+        section in the Yocto Project Software Development Kit (SDK) Developer's
+        Guide.
     </para>
 </section>
 
@@ -2869,66 +2857,6 @@
     </para>
 </section>
 
-<section id='ref-classes-qmake*'>
-    <title><filename>qmake*.bbclass</filename></title>
-
-    <para>
-        The <filename>qmake*</filename> classes support recipes that
-        need to build software that uses Qt's <filename>qmake</filename>
-        build system and are comprised of the following:
-        <itemizedlist>
-            <listitem><para><emphasis><filename>qmake_base</filename>:</emphasis>
-                Provides base functionality for all versions of
-                <filename>qmake</filename>.</para></listitem>
-            <listitem><para><emphasis><filename>qmake2</filename>:</emphasis>
-                Extends base functionality for <filename>qmake</filename> 2.x as
-                used by Qt 4.x.</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        If you need to set any configuration variables or pass any options to
-        <filename>qmake</filename>, you can add these to the
-        <link linkend='var-EXTRA_QMAKEVARS_PRE'><filename>EXTRA_QMAKEVARS_PRE</filename></link>
-        or
-        <link linkend='var-EXTRA_QMAKEVARS_POST'><filename>EXTRA_QMAKEVARS_POST</filename></link>
-        variables, depending on whether the arguments need to be before or
-        after the <filename>.pro</filename> file list on the command line,
-        respectively.
-    </para>
-
-    <para>
-        By default, all <filename>.pro</filename> files are built.
-        If you want to specify your own subset of <filename>.pro</filename>
-        files to be built, specify them in the
-        <link linkend='var-QMAKE_PROFILES'><filename>QMAKE_PROFILES</filename></link>
-        variable.
-    </para>
-</section>
-
-<section id='ref-classes-qt4*'>
-    <title><filename>qt4*.bbclass</filename></title>
-
-    <para>
-        The <filename>qt4*</filename> classes support recipes that need to
-        build software that uses the Qt development framework version 4.x
-        and consist of the following:
-        <itemizedlist>
-            <listitem><para><emphasis><filename>qt4e</filename>:</emphasis>
-                Supports building against Qt/Embedded, which uses the
-                framebuffer for graphical output.</para></listitem>
-            <listitem><para><emphasis><filename>qt4x11</filename>:</emphasis>
-                Supports building against Qt/X11.</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        The classes inherit the
-        <link linkend='ref-classes-qmake*'><filename>qmake2</filename></link>
-        class.
-    </para>
-</section>
-
 <section id='ref-classes-recipe_sanity'>
     <title><filename>recipe_sanity.bbclass</filename></title>
 
@@ -2958,6 +2886,33 @@
     </para>
 </section>
 
+<section id='ref-classes-remove-libtool'>
+    <title><filename>remove-libtool.bbclass</filename></title>
+
+    <para>
+        The <filename>remove-libtool</filename> class adds a post function
+        to the
+        <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+        task to remove all <filename>.la</filename> files installed by
+        <filename>libtool</filename>.
+        Removing these files results in them being absent from both the
+        sysroot and target packages.
+    </para>
+
+    <para>
+        If a recipe needs the <filename>.la</filename> files to be installed,
+        then the recipe can override the removal by setting
+        <filename>REMOVE_LIBTOOL_LA</filename> to "0" as follows:
+        <literallayout class='monospaced'>
+     REMOVE_LIBTOOL_LA = "0"
+        </literallayout>
+        <note>
+            The <filename>remove-libtool</filename> class is not enabled by
+            default.
+        </note>
+    </para>
+</section>
+
 <section id='ref-classes-report-error'>
     <title><filename>report-error.bbclass</filename></title>
 
@@ -3026,6 +2981,10 @@
         the root filesystem for an image and consist of the following classes:
         <itemizedlist>
             <listitem><para>
+                The <filename>rootfs-postcommands</filename> class, which
+                defines filesystem post-processing functions for image recipes.
+                </para></listitem>
+            <listitem><para>
                 The <filename>rootfs_deb</filename> class, which supports
                 creation of root filesystems for images built using
                 <filename>.deb</filename> packages.</para></listitem>
@@ -3225,10 +3184,10 @@
     <title><filename>staging.bbclass</filename></title>
 
     <para>
-        The <filename>staging</filename> class provides support for staging
-        files into the sysroot during the
+        The <filename>staging</filename> class provides the
         <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
-        task.
+        task, which stages files into the sysroot to make them available to
+        other recipes at build time.
         The class is enabled by default because it is inherited by the
         <link linkend='ref-classes-base'><filename>base</filename></link>
         class.
@@ -3398,6 +3357,20 @@
     </para>
 </section>
 
+<section id='ref-classes-testsdk'>
+    <title><filename>testsdk.bbclass</filename></title>
+
+    <para>
+        This class supports running automated tests against
+        software development kits (SDKs).
+        The <filename>testsdk</filename> class runs tests on an SDK when
+        called using the following:
+        <literallayout class='monospaced'>
+     $ bitbake -c testsdk image
+        </literallayout>
+    </para>
+</section>
+
 <section id='ref-classes-texinfo'>
     <title><filename>texinfo.bbclass</filename></title>
 
@@ -3498,14 +3471,23 @@
     <title><filename>uninative.bbclass</filename></title>
 
     <para>
-        Provides a means of reusing <filename>native/cross</filename> over
-        multiple distros.
-        <note>
-            Currently, the method used by the <filename>uninative</filename>
-            class is experimental.
-        </note>
-        For more information, see the commit message
-        <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=e66c96ae9c7ba21ebd04a4807390f0031238a85a'>here</ulink>.
+        Attempts to isolate the build system from the host
+        distribution's C library in order to make re-use of native shared state
+        artifacts across different host distributions practical.
+        With this class enabled, a tarball containing a pre-built C library
+        is downloaded at the start of the build.
+        In the Poky reference distribution this is enabled by default
+        through
+        <filename>meta/conf/distro/include/yocto-uninative.inc</filename>.
+        Other distributions that do not derive from poky can also
+        "<filename>require conf/distro/include/yocto-uninative.inc</filename>"
+        to use this.
+        Alternatively if you prefer, you can build the uninative-tarball recipe
+        yourself, publish the resulting tarball (e.g. via HTTP) and set
+        <filename>UNINATIVE_URL</filename> and
+        <filename>UNINATIVE_CHECKSUM</filename> appropriately.
+        For an example, see the
+        <filename>meta/conf/distro/include/yocto-uninative.inc</filename>.
     </para>
 </section>
 

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

diff --git a/yocto-poky/documentation/ref-manual/ref-features.xml b/yocto-poky/documentation/ref-manual/ref-features.xml
index 798e0a2..fd76935 100644
--- a/yocto-poky/documentation/ref-manual/ref-features.xml
+++ b/yocto-poky/documentation/ref-manual/ref-features.xml
@@ -308,8 +308,12 @@
                 <listitem><para><emphasis>nfs-server:</emphasis>
                     Installs an NFS server.
                     </para></listitem>
-                <listitem><para><emphasis>qt4-pkgs:</emphasis>
-                    Supports Qt4/X11 and demo applications.
+                <listitem><para><emphasis>perf:</emphasis>
+                    Installs profiling tools such as
+                    <filename>perf</filename>, <filename>systemtap</filename>,
+                    and <filename>LTTng</filename>.
+                    For general information on user-space tools, see the
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
                     </para></listitem>
                 <listitem><para><emphasis>ssh-server-dropbear:</emphasis>
                     Installs the Dropbear minimal SSH server.
@@ -331,15 +335,6 @@
                     For information on tracing and profiling, see the
                     <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>.
                     </para></listitem>
-                <listitem><para><emphasis>tools-profile:</emphasis>
-                    Installs profiling tools such as
-                    <filename>oprofile</filename>, <filename>exmap</filename>,
-                    and <filename>LTTng</filename>.
-                    For general information on user-space tools, see the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#user-space-tools'>User-Space Tools</ulink>"
-                    section in the Yocto Project Application Developer's
-                    Guide.
-                    </para></listitem>
                 <listitem><para><emphasis>tools-sdk:</emphasis>
                     Installs a full SDK that runs on the device.
                     </para></listitem>

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

diff --git a/yocto-poky/documentation/ref-manual/ref-images.xml b/yocto-poky/documentation/ref-manual/ref-images.xml
index d15ca5b..69b58f6 100644
--- a/yocto-poky/documentation/ref-manual/ref-images.xml
+++ b/yocto-poky/documentation/ref-manual/ref-images.xml
@@ -80,7 +80,7 @@
                 </para></listitem>
             <listitem><para><filename>core-image-lsb-sdk</filename>:
                 A <filename>core-image-lsb</filename> that includes everything in
-                meta-toolchain but also includes development headers and libraries
+                the cross-toolchain but also includes development headers and libraries
                 to form a complete standalone SDK.
                 This image requires a distribution configuration that
                 enables LSB compliance (e.g. <filename>poky-lsb</filename>).
@@ -114,7 +114,7 @@
                 tools appropriate for real-time use.</para></listitem>
             <listitem><para><filename>core-image-rt-sdk</filename>:
                 A <filename>core-image-rt</filename> image that includes everything in
-                <filename>meta-toolchain</filename>.
+                the cross-toolchain.
                 The image also includes development headers and libraries to form a complete
                 stand-alone SDK and is suitable for development using the target.
                 </para></listitem>
@@ -132,7 +132,8 @@
                 This image was formerly <filename>core-image-sdk</filename>.
                 </para></listitem>
             <listitem><para><filename>core-image-sato-sdk</filename>:
-                A <filename>core-image-sato</filename> image that includes everything in meta-toolchain.
+                A <filename>core-image-sato</filename> image that includes everything in
+                the cross-toolchain.
                 The image also includes development headers and libraries to form a complete standalone SDK
                 and is suitable for development using the target.</para></listitem>
             <listitem><para><filename>core-image-testmaster</filename>:
@@ -158,9 +159,6 @@
             <listitem><para><filename>core-image-x11</filename>:
                 A very basic X11 image with a terminal.
                 </para></listitem>
-            <listitem><para><filename>qt4e-demo-image</filename>:
-                An image that launches into the demo application for the embedded
-                (not based on X11) version of Qt.</para></listitem>
         </itemizedlist>
     </para>
 </chapter>

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

diff --git a/yocto-poky/documentation/ref-manual/ref-manual.xml b/yocto-poky/documentation/ref-manual/ref-manual.xml
index a296b9b..6834d5f 100644
--- a/yocto-poky/documentation/ref-manual/ref-manual.xml
+++ b/yocto-poky/documentation/ref-manual/ref-manual.xml
@@ -97,6 +97,11 @@
                 <date>October 2015</date>
                 <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>April 2016</date>
+                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

yocto-poky/documentation/ref-manual/ref-qa-checks.xml

diff --git a/yocto-poky/documentation/ref-manual/ref-qa-checks.xml b/yocto-poky/documentation/ref-manual/ref-qa-checks.xml
index 38689b9..4fcf1db 100644
--- a/yocto-poky/documentation/ref-manual/ref-qa-checks.xml
+++ b/yocto-poky/documentation/ref-manual/ref-qa-checks.xml
@@ -81,11 +81,13 @@
 
                 <para>
                     The specified package contains files in
-                    <filename>/usr/libexec</filename>.
-                    By default, <filename>libexecdir</filename> is set to
-                    "${libdir}/${BPN}" rather than to "/usr/libexec".
-                    Thus, installing to <filename>/usr/libexec</filename>
-                    is likely not desirable.
+                    <filename>/usr/libexec</filename> when the distro
+                    configuration uses a different path for
+                    <filename>&lt;libexecdir&gt;</filename>
+                    By default, <filename>&lt;libexecdir&gt;</filename> is
+                    <filename>$prefix/libexec</filename>.
+                    However, this default can be changed (e.g.
+                    <filename>${libdir}</filename>).
                 </para>
 
                 <para>

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

diff --git a/yocto-poky/documentation/ref-manual/ref-structure.xml b/yocto-poky/documentation/ref-manual/ref-structure.xml
index 48e3921..e51ceb1 100644
--- a/yocto-poky/documentation/ref-manual/ref-structure.xml
+++ b/yocto-poky/documentation/ref-manual/ref-structure.xml
@@ -123,8 +123,8 @@
         </para>
     </section>
 
-    <section id='structure-core-meta-yocto'>
-        <title><filename>meta-yocto/</filename></title>
+    <section id='structure-core-meta-poky'>
+        <title><filename>meta-poky/</filename></title>
 
         <para>
             This directory contains the configuration for the Poky
@@ -227,14 +227,13 @@
          core-image-minimal
          core-image-sato
          meta-toolchain
-         adt-installer
          meta-ide-support
 
      You can also run generated qemu images with a command like 'runqemu qemux86'
             </literallayout>
             The script gets its default list of common targets from the
             <filename>conf-notes.txt</filename> file, which is found in the
-            <filename>meta-yocto</filename> directory within the
+            <filename>meta-poky</filename> directory within the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             Should you have custom distributions, it is very easy to modify
             this configuration file to include your targets for your
@@ -261,7 +260,7 @@
             </literallayout>
             The OpenEmbedded build system uses the template configuration
             files, which are found by default in the
-            <filename>meta-yocto/conf</filename> directory in the
+            <filename>meta-poky/conf</filename> directory in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
@@ -366,7 +365,6 @@
          core-image-minimal
          core-image-sato
          meta-toolchain
-         adt-installer
          meta-ide-support
 
      You can also run generated qemu images with a command like 'runqemu qemux86'
@@ -375,7 +373,7 @@
             </literallayout>
             The script gets its default list of common targets from the
             <filename>conf-notes.txt</filename> file, which is found in the
-            <filename>meta-yocto</filename> directory within the
+            <filename>meta-poky</filename> directory within the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             Should you have custom distributions, it is very easy to modify
             this configuration file to include your targets for your
@@ -411,7 +409,7 @@
         <para>
             The OpenEmbedded build system uses the template configuration
             files, which are found by default in the
-            <filename>meta-yocto/conf</filename> directory in the
+            <filename>meta-poky/conf</filename> directory in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
@@ -515,7 +513,7 @@
         <para>
             The source <filename>local.conf.sample</filename> file used
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>meta-yocto/conf</filename>
+            which defaults to <filename>meta-poky/conf</filename>
             when you are building from the Yocto Project development
             environment and defaults to <filename>meta/conf</filename> when
             you are building from the OpenEmbedded Core environment.
@@ -538,7 +536,7 @@
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 You can find the Yocto Project version of the
                 <filename>local.conf.sample</filename> file in the
-                <filename>meta-yocto/conf</filename> directory.
+                <filename>meta-poky/conf</filename> directory.
             </note>
         </para>
     </section>
@@ -569,7 +567,7 @@
         <para>
             The source <filename>bblayers.conf.sample</filename> file used
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>meta-yocto/conf</filename>
+            which defaults to <filename>meta-poky/conf</filename>
             when you are building from the Yocto Project development
             environment and defaults to <filename>meta/conf</filename> when
             you are building from the OpenEmbedded Core environment.
@@ -590,7 +588,7 @@
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 You can find the Yocto Project version of the
                 <filename>bblayers.conf.sample</filename> file in the
-                <filename>meta-yocto/conf</filename> directory.
+                <filename>meta-poky/conf</filename> directory.
             </note>
         </para>
     </section>
@@ -738,8 +736,7 @@
         <para>
             Be careful when deleting files in this directory.
             You can safely delete old images from this directory (e.g.
-            <filename>core-image-*</filename>, <filename>hob-image-*</filename>,
-            etc.).
+            <filename>core-image-*</filename>).
             However, the kernel (<filename>*zImage*</filename>, <filename>*uImage*</filename>, etc.),
             bootloader and other supplementary files might be deployed here prior to building an
             image.
@@ -767,8 +764,8 @@
             toolchain installer scripts, which when executed, install the
             sysroot that matches your target hardware.
             You can find out more about these installers in the
-            "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-            section in the Yocto Project Application Developer's Guide.
+            "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+            section in the Yocto Project Software Development Kit (SDK) Developer's Guide.
         </para>
     </section>
 
@@ -1091,14 +1088,6 @@
         </para>
     </section>
 
-    <section id='structure-meta-recipes-qt'>
-        <title><filename>meta/recipes-qt/</filename></title>
-
-        <para>
-            This directory contains all things related to the Qt application framework.
-        </para>
-    </section>
-
     <section id='structure-meta-recipes-rt'>
         <title><filename>meta/recipes-rt/</filename></title>
 

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

diff --git a/yocto-poky/documentation/ref-manual/ref-tasks.xml b/yocto-poky/documentation/ref-manual/ref-tasks.xml
index 21403c0..c46debb 100644
--- a/yocto-poky/documentation/ref-manual/ref-tasks.xml
+++ b/yocto-poky/documentation/ref-manual/ref-tasks.xml
@@ -31,6 +31,36 @@
         </para>
     </section>
 
+    <section id='ref-tasks-checkpkg'>
+        <title><filename>do_checkpkg</filename></title>
+
+        <para>
+            Provides information about the recipe including its upstream
+            version and status.
+            The upstream version and status reveals whether or not a version
+            of the recipe exists upstream and a status of not updated, updated,
+            or unknown.
+        </para>
+
+        <para>
+            The <filename>checkpkg</filename> task is included as part of the
+            <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
+            class.
+        </para>
+
+        <para>
+            To build the <filename>checkpkg</filename> task, use the
+            <filename>bitbake</filename> command with the "-c" option and
+            task name:
+            <literallayout class='monospaced'>
+     $ bitbake core-image-minimal -c checkpkg
+            </literallayout>
+            By default, the results are stored in
+            <link linkend='var-LOG_DIR'><filename>$LOG_DIR</filename></link>
+            (e.g. <filename>$BUILD_DIR/tmp/log</filename>).
+        </para>
+    </section>
+
     <section id='ref-tasks-compile'>
         <title><filename>do_compile</filename></title>
 
@@ -87,6 +117,32 @@
         </para>
     </section>
 
+    <section id='ref-tasks-distrodata'>
+        <title><filename>do_distrodata</filename></title>
+
+        <para>
+            Provides information about the recipe.
+        </para>
+
+        <para>
+            The <filename>distrodata</filename> task is included as part of the
+            <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
+            class.
+        </para>
+
+        <para>
+            To build the <filename>distrodata</filename> task, use the
+            <filename>bitbake</filename> command with the "-c" option and
+            task name:
+            <literallayout class='monospaced'>
+     $ bitbake core-image-minimal -c distrodata
+            </literallayout>
+            By default, the results are stored in
+            <link linkend='var-LOG_DIR'><filename>$LOG_DIR</filename></link>
+            (e.g. <filename>$BUILD_DIR/tmp/log</filename>).
+        </para>
+    </section>
+
     <section id='ref-tasks-fetch'>
         <title><filename>do_fetch</filename></title>
 
@@ -99,6 +155,60 @@
         </para>
     </section>
 
+    <section id='ref-tasks-image'>
+        <title><filename>do_image</filename></title>
+
+        <para>
+            Starts the image generation process.
+            The <filename>do_image</filename> task runs after the
+            OpenEmbedded build system has run the
+            <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+            task during which packages are identified for installation into
+            the image and the root filesystem is created, complete with
+            post-processing.
+        </para>
+
+        <para>
+            The <filename>do_image</filename> task performs pre-processing
+            on the image through the
+            <link linkend='var-IMAGE_PREPROCESS_COMMAND'><filename>IMAGE_PREPROCESS_COMMAND</filename></link>
+            and dynamically generates supporting
+            <filename>do_image_*</filename> tasks as needed.
+        </para>
+
+        <para>
+            For more information on image creation, see the
+            "<link linkend='image-generation-dev-environment'>Image Generation</link>"
+            section.
+        </para>
+    </section>
+
+    <section id='ref-tasks-image-complete'>
+        <title><filename>do_image_complete</filename></title>
+
+        <para>
+            Completes the image generation process.
+            The <filename>do_image_complete</filename> task runs after the
+            OpenEmbedded build system has run the
+            <link linkend='ref-tasks-rootfs'><filename>do_image</filename></link>
+            task during which image pre-processing occurs and through
+            dynamically generated <filename>do_image_*</filename> tasks the
+            image is constructed.
+        </para>
+
+        <para>
+            The <filename>do_image_complete</filename> task performs
+            post-processing on the image through the
+            <link linkend='var-IMAGE_POSTPROCESS_COMMAND'><filename>IMAGE_POSTPROCESS_COMMAND</filename></link>.
+        </para>
+
+        <para>
+            For more information on image creation, see the
+            "<link linkend='image-generation-dev-environment'>Image Generation</link>"
+            section.
+        </para>
+    </section>
+
     <section id='ref-tasks-install'>
         <title><filename>do_install</filename></title>
 
@@ -239,10 +349,16 @@
         <title><filename>do_populate_sysroot</filename></title>
 
         <para>
-            Copies a subset of files installed by the
+            Copies a subset of the files installed by the
             <link linkend='ref-tasks-install'><filename>do_install</filename></link>
-            task into the sysroot in order to make them available to other
-            recipes.
+            task into the sysroot to make them available to other recipes.
+            Files that would typically not be needed by other recipes at build
+            time are skipped.
+            Skipped files include files installed into
+            <filename>/etc.</filename>
+            For information on what files are copied, see the
+            <link linkend='ref-classes-staging'><filename>staging</filename></link>
+            class.
         </para>
 
         <para>
@@ -700,15 +816,6 @@
         The following sections describe miscellaneous tasks.
     </para>
 
-    <section id='ref-tasks-generate_qt_config_file'>
-        <title><filename>do_generate_qt_config_file</filename></title>
-
-        <para>
-            Writes a <filename>qt.conf</filename> configuration
-            file used for building a Qt-based application.
-        </para>
-    </section>
-
     <section id='ref-tasks-spdx'>
         <title><filename>do_spdx</filename></title>
 

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

diff --git a/yocto-poky/documentation/ref-manual/ref-variables.xml b/yocto-poky/documentation/ref-manual/ref-variables.xml
index 0b2c426..d55bccd 100644
--- a/yocto-poky/documentation/ref-manual/ref-variables.xml
+++ b/yocto-poky/documentation/ref-manual/ref-variables.xml
@@ -32,7 +32,7 @@
 <!--               <link linkend='var-glossary-n'>N</link> -->
        <link linkend='var-OBJCOPY'>O</link>
        <link linkend='var-P'>P</link>
-       <link linkend='var-QMAKE_PROFILES'>Q</link>
+<!--               <link linkend='var-glossary-q'>Q</link> -->
        <link linkend='var-RANLIB'>R</link>
        <link linkend='var-S'>S</link>
        <link linkend='var-T'>T</link>
@@ -1130,24 +1130,11 @@
                     <literallayout class='monospaced'>
      BBLAYERS = " \
        /home/scottrif/poky/meta \
-       /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-poky \
        /home/scottrif/poky/meta-yocto-bsp \
        /home/scottrif/poky/meta-mykernel \
        "
-
-     BBLAYERS_NON_REMOVABLE ?= " \
-       /home/scottrif/poky/meta \
-       /home/scottrif/poky/meta-yocto \
-       "
                     </literallayout>
-                    <note>
-                        The
-                        <link linkend='var-BBLAYERS_NON_REMOVABLE'><filename>BBLAYERS_NON_REMOVABLE</filename></link>
-                        variable exists only for
-                        <ulink url='https://www.yoctoproject.org/tools-resources/projects/hob'>Hob</ulink>.
-                        The OpenEmbedded build system does not use this
-                        variable.
-                    </note>
                 </para>
 
                 <para>
@@ -1157,60 +1144,15 @@
             </glossdef>
         </glossentry>
 
-        <glossentry id='var-BBLAYERS_NON_REMOVABLE'><glossterm>BBLAYERS_NON_REMOVABLE</glossterm>
-            <info>
-                BBLAYERS_NON_REMOVABLE[doc] = "Lists core layers that cannot be removed from the bblayers.conf file."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Lists core layers that cannot be removed from the
-                    <filename>bblayers.conf</filename> file during a build
-                    using the
-                    <ulink url='https://www.yoctoproject.org/tools-resources/projects/hob'>Hob</ulink>.
-                    <note>
-                        When building an image outside of Hob, the OpenEmbedded
-                        build system ignores this variable.
-                    </note>
-                </para>
-
-                <para>
-                    In order for BitBake to build your image using Hob, your
-                    <filename>bblayers.conf</filename> file must include the
-                    <filename>meta</filename> and <filename>meta-yocto</filename>
-                    core layers.
-                    Here is an example that shows these two layers listed in
-                    the <filename>BBLAYERS_NON_REMOVABLE</filename> statement:
-                    <literallayout class='monospaced'>
-     BBLAYERS = " \
-       /home/scottrif/poky/meta \
-       /home/scottrif/poky/meta-yocto \
-       /home/scottrif/poky/meta-yocto-bsp \
-       /home/scottrif/poky/meta-mykernel \
-       "
-
-     BBLAYERS_NON_REMOVABLE ?= " \
-       /home/scottrif/poky/meta \
-       /home/scottrif/poky/meta-yocto \
-       "
-                    </literallayout>
-                </para>
-            </glossdef>
-        </glossentry>
-
         <glossentry id='var-BBMASK'><glossterm>BBMASK</glossterm>
             <info>
-                BBMASK[doc] = "Prevents BitBake from processing specific recipes or recipe append files. Use the BBMASK variable from within conf/local.conf."
+                BBMASK[doc] = "Prevents BitBake from processing specific recipes or recipe append files."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Prevents BitBake from processing recipes and recipe
                     append files.
-                    Use the <filename>BBMASK</filename> variable from within the
-                    <filename>conf/local.conf</filename> file found
-                    in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
                 </para>
 
                 <para>
@@ -1218,14 +1160,14 @@
                     to "hide" these <filename>.bb</filename> and
                     <filename>.bbappend</filename> files.
                     BitBake ignores any recipe or recipe append files that
-                    match the expression.
+                    match any of the expressions.
                     It is as if BitBake does not see them at all.
                     Consequently, matching files are not parsed or otherwise
                     used by BitBake.</para>
                 <para>
-                    The value you provide is passed to Python's regular
+                    The values you provide are passed to Python's regular
                     expression compiler.
-                    The expression is compared against the full paths to
+                    The expressions are compared against the full paths to
                     the files.
                     For complete syntax information, see Python's
                     documentation at
@@ -1241,18 +1183,16 @@
      BBMASK = "meta-ti/recipes-misc/"
                     </literallayout>
                     If you want to mask out multiple directories or recipes,
-                    use the vertical bar to separate the regular expression
-                    fragments.
+                    you can specify multiple regular expression fragments.
                     This next example masks out multiple directories and
                     individual recipes:
                     <literallayout class='monospaced'>
-     BBMASK = "meta-ti/recipes-misc/|meta-ti/recipes-ti/packagegroup/"
-     BBMASK .= "|.*meta-oe/recipes-support/"
-     BBMASK .= "|.*openldap"
-     BBMASK .= "|.*opencv"
-     BBMASK .= "|.*lzma"
+     BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
+     BBMASK += "/meta-oe/recipes-support/"
+     BBMASK += "/meta-foo/.*/openldap"
+     BBMASK += "opencv.*\.bbappend"
+     BBMASK += "lzma"
                     </literallayout>
-                    Notice how the vertical bar is used to append the fragments.
                     <note>
                         When specifying a directory name, use the trailing
                         slash character to ensure you match just that directory
@@ -1402,15 +1342,22 @@
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     The bare name of the recipe.
-                    This variable is a version of the <link linkend='var-PN'><filename>PN</filename></link> variable
-                    but removes common suffixes such as "-native" and "-cross" as well
-                    as removes common prefixes such as multilib's "lib64-" and "lib32-".
+                    This variable is a version of the
+                    <link linkend='var-PN'><filename>PN</filename></link>
+                    variable but removes common suffixes such as
+                    <filename>-native</filename> and
+                    <filename>-cross</filename> as well
+                    as removes common prefixes such as multilib's
+                    <filename>lib64-</filename> and
+                    <filename>lib32-</filename>.
                     The exact list of suffixes removed is specified by the
-                    <link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link> variable.
+                    <link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link>
+                    variable.
                     The exact list of prefixes removed is specified by the
-                    <link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link> variable.
+                    <link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link>
+                    variable.
                     Prefixes are removed for <filename>multilib</filename>
-                    and <filename>nativesdk</filename> cases.
+                    and <filename>nativesdk-</filename> cases.
                 </para>
             </glossdef>
         </glossentry>
@@ -1473,7 +1420,7 @@
                     Specifies the flags to pass to the C pre-processor
                     (i.e. to both the C and the C++ compilers) when building
                     for the build host.
-                    When building in the <filename>native</filename> context,
+                    When building in the <filename>-native</filename> context,
                     <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
                     is set to the value of this variable by default.
                 </para>
@@ -1489,7 +1436,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the flags to pass to the C++ compiler when
                     building for the build host.
-                    When building in the <filename>native</filename> context,
+                    When building in the <filename>-native</filename> context,
                     <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
                     is set to the value of this variable by default.
                 </para>
@@ -1564,7 +1511,7 @@
                     The OpenEmbedded build system uses the
                     <filename>BUILD_PREFIX</filename> value to set the
                     <link linkend='var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></link>
-                    when building for native recipes.
+                    when building for <filename>native</filename> recipes.
                 </para>
             </glossdef>
         </glossentry>
@@ -1845,7 +1792,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the flags to pass to the C compiler when building
                     for the SDK.
-                    When building in the <filename>nativesdk</filename>
+                    When building in the <filename>nativesdk-</filename>
                     context,
                     <link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
                     is set to the value of this variable by default.
@@ -1863,7 +1810,7 @@
                     Specifies the flags to pass to the C pre-processor
                     (i.e. to both the C and the C++ compilers) when building
                     for the SDK.
-                    When building in the <filename>nativesdk</filename>
+                    When building in the <filename>nativesdk-</filename>
                     context,
                     <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
                     is set to the value of this variable by default.
@@ -1880,7 +1827,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the flags to pass to the C++ compiler when
                     building for the SDK.
-                    When building in the <filename>nativesdk</filename>
+                    When building in the <filename>nativesdk-</filename>
                     context,
                     <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
                     is set to the value of this variable by default.
@@ -2037,7 +1984,7 @@
                     and then can be used as an override.
                     Here is an example where "python-native" is added to
                     <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
-                    only when building for the native case:
+                    only when building for the <filename>-native</filename> case:
                     <literallayout class='monospaced'>
      DEPENDS_append_class-native = " python-native"
                     </literallayout>
@@ -2354,7 +2301,20 @@
                     <filename>/usr/share/common-licenses</filename>,
                     for each package.
                     The license files are placed
-                    in directories within the image itself.
+                    in directories within the image itself during build time.
+                    <note>
+                        The <filename>COPY_LIC_DIRS</filename> does not
+                        offer a path for adding licenses for newly installed
+                        packages to an image, which might be most suitable
+                        for read-only filesystems that cannot be upgraded.
+                        See the
+                        <link linkend='var-LICENSE_CREATE_PACKAGE'><filename>LICENSE_CREATE_PACKAGE</filename></link>
+                        variable for additional information.
+                        You can also reference the
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
+                        section in the Yocto Project Development Manual for
+                        information on providing license text.
+                    </note>
                 </para>
             </glossdef>
         </glossentry>
@@ -2369,7 +2329,20 @@
                     If set to "1", the OpenEmbedded build system copies
                     the license manifest for the image to
                     <filename>/usr/share/common-licenses/license.manifest</filename>
-                    within the image itself.
+                    within the image itself during build time.
+                    <note>
+                        The <filename>COPY_LIC_MANIFEST</filename> does not
+                        offer a path for adding licenses for newly installed
+                        packages to an image, which might be most suitable
+                        for read-only filesystems that cannot be upgraded.
+                        See the
+                        <link linkend='var-LICENSE_CREATE_PACKAGE'><filename>LICENSE_CREATE_PACKAGE</filename></link>
+                        variable for additional information.
+                        You can also reference the
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
+                        section in the Yocto Project Development Manual for
+                        information on providing license text.
+                    </note>
                 </para>
             </glossdef>
         </glossentry>
@@ -2420,6 +2393,35 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-COREBASE_FILES'><glossterm>COREBASE_FILES</glossterm>
+            <info>
+                COREBASE_FILES[doc] = "Lists files from the COREBASE directory that should be copied other than the layers listed in the bblayers.conf file."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Lists files from the
+                    <link linkend='var-COREBASE'><filename>COREBASE</filename></link>
+                    directory that should be copied other than the layers
+                    listed in the <filename>bblayers.conf</filename> file.
+                    The <filename>COREBASE_FILES</filename> variable exists
+                    for the purpose of copying metadata from the
+                    OpenEmbedded build system into the extensible
+                    SDK.
+                </para>
+
+                <para>
+                    Explicitly listing files in <filename>COREBASE</filename>
+                    is needed because it typically contains build
+                    directories and other files that should not normally
+                    be copied into the extensible SDK.
+                    Consequently, the value of
+                    <filename>COREBASE_FILES</filename> is used in order to
+                    only copy the files that are actually needed.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-CPP'><glossterm>CPP</glossterm>
             <info>
                 CPP[doc] = "Minimum command and arguments to run the C preprocessor."
@@ -2547,7 +2549,7 @@
                         <listitem><para>
                             <link linkend='var-BUILDSDK_CXXFLAGS'><filename>BUILDSDK_CXXFLAGS</filename></link>
                             when building for an SDK (i.e.
-                            <filename>nativesdk</filename>)
+                            <filename>nativesdk-</filename>)
                             </para></listitem>
                     </itemizedlist>
                 </para>
@@ -3110,7 +3112,7 @@
                     For example, the distribution configuration file for the
                     Poky distribution is named <filename>poky.conf</filename>
                     and resides in the
-                    <filename>meta-yocto/conf/distro</filename> directory of
+                    <filename>meta-poky/conf/distro</filename> directory of
                     the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para>
@@ -3413,6 +3415,9 @@
                     see this specific question in the
                     "<link linkend='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</link>"
                     chapter.
+                    You can also refer to the
+                    "<ulink url='&YOCTO_WIKI_URL;/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
+                    Wiki page.
                 </para>
             </glossdef>
         </glossentry>
@@ -3814,9 +3819,6 @@
 "tools-debug" - Adds debugging tools such as gdb and
                 strace.
 
-"tools-profile" - Adds profiling tools such as oprofile,
-                  exmap, lttng and valgrind (x86 only).
-
 "tools-sdk" - Adds development tools such as gcc, make,
               pkgconfig and so forth.
 
@@ -3924,6 +3926,12 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Additional GNU <filename>make</filename> options.
                 </para>
+
+                <para>
+                    Because the <filename>EXTRA_OEMAKE</filename> defaults to
+                    "", you need to set the variable to specify any required
+                    GNU options.
+                </para>
             </glossdef>
         </glossentry>
 
@@ -3943,50 +3951,6 @@
             </glossdef>
         </glossentry>
 
-        <glossentry id='var-EXTRA_QMAKEVARS_POST'><glossterm>EXTRA_QMAKEVARS_POST</glossterm>
-            <info>
-                EXTRA_QMAKEVARS_POST[doc] = "Configuration variables or options you want to pass to qmake when the arguments need to be after the .pro file list on the command line."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Configuration variables or options you want to pass to
-                    <filename>qmake</filename>.
-                    Use this variable when the arguments need to be after the
-                    <filename>.pro</filename> file list on the command line.
-                </para>
-
-                <para>
-                    This variable is used with recipes that inherit the
-                    <link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
-                    class or other classes that inherit
-                    <filename>qmake_base</filename>.
-                </para>
-            </glossdef>
-        </glossentry>
-
-       <glossentry id='var-EXTRA_QMAKEVARS_PRE'><glossterm>EXTRA_QMAKEVARS_PRE</glossterm>
-            <info>
-                EXTRA_QMAKEVARS_PRE[doc] = "Configuration variables or options you want to pass to qmake when the arguments need to be before the .pro file list on the command line."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Configuration variables or options you want to pass to
-                    <filename>qmake</filename>.
-                    Use this variable when the arguments need to be before the
-                    <filename>.pro</filename> file list on the command line.
-                </para>
-
-                <para>
-                    This variable is used with recipes that inherit the
-                    <link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
-                    class or other classes that inherit
-                    <filename>qmake_base</filename>.
-                </para>
-            </glossdef>
-        </glossentry>
-
         <glossentry id='var-EXTRA_USERS_PARAMS'><glossterm>EXTRA_USERS_PARAMS</glossterm>
             <info>
                 EXTRA_USERS_PARAMS[doc] = "When a recipe inherits the extrausers class, this variable provides image level user and group operations."
@@ -4760,12 +4724,12 @@
                         <listitem><para>
                             <filename>BUILD_CC_ARCH</filename>
                             when building for the build host (i.e.
-                            <filename>native</filename>)
+                            <filename>-native</filename>)
                             </para></listitem>
                         <listitem><para>
                             <filename>BUILDSDK_CC_ARCH</filename>
                             when building for an SDK (i.e.
-                            <filename>nativesdk</filename>)
+                            <filename>nativesdk-</filename>)
                             </para></listitem>
                     </itemizedlist>
                 </para>
@@ -5523,7 +5487,7 @@
 
                 <para>
                     The
-                    <link linkend='ref-classes-populate-sdk-*'><filename>package_sdk_base</filename></link>
+                    <link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_*</filename></link>
                     and
                     <link linkend='ref-classes-image'><filename>image</filename></link>
                     classes use the <filename>IMAGE_PKGTYPE</filename> for
@@ -5916,6 +5880,43 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
+            <info>
+                INHERIT[doc] = "Causes the named class to be inherited at this point during parsing. The variable is only valid in configuration files."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Causes the named class to be inherited at
+                    this point during parsing.
+                    The variable is only valid in configuration files.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHERIT_DISTRO'><glossterm>INHERIT_DISTRO</glossterm>
+            <info>
+                INHERIT_DISTRO[doc] = "Lists classes that will be inherited at the distribution level. It is unlikely that you want to edit this variable."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Lists classes that will be inherited at the
+                    distribution level.
+                    It is unlikely that you want to edit this variable.
+                </para>
+
+                <para>
+                    The default value of the variable is set as follows in the
+                    <filename>meta/conf/distro/defaultsetup.conf</filename>
+                    file:
+                    <literallayout class='monospaced'>
+     INHERIT_DISTRO ?= "debian devshell sstate license"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-INHIBIT_DEFAULT_DEPS'><glossterm>INHIBIT_DEFAULT_DEPS</glossterm>
             <info>
                 INHIBIT_DEFAULT_DEPS[doc] = "Prevents the default dependencies, namely the C compiler and standard C library (libc), from being added to DEPENDS."
@@ -5980,43 +5981,6 @@
             </glossdef>
         </glossentry>
 
-        <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
-            <info>
-                INHERIT[doc] = "Causes the named class to be inherited at this point during parsing. The variable is only valid in configuration files."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Causes the named class to be inherited at
-                    this point during parsing.
-                    The variable is only valid in configuration files.
-                </para>
-            </glossdef>
-        </glossentry>
-
-        <glossentry id='var-INHERIT_DISTRO'><glossterm>INHERIT_DISTRO</glossterm>
-            <info>
-                INHERIT_DISTRO[doc] = "Lists classes that will be inherited at the distribution level. It is unlikely that you want to edit this variable."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Lists classes that will be inherited at the
-                    distribution level.
-                    It is unlikely that you want to edit this variable.
-                </para>
-
-                <para>
-                    The default value of the variable is set as follows in the
-                    <filename>meta/conf/distro/defaultsetup.conf</filename>
-                    file:
-                    <literallayout class='monospaced'>
-     INHERIT_DISTRO ?= "debian devshell sstate license"
-                    </literallayout>
-                </para>
-            </glossdef>
-        </glossentry>
-
         <glossentry id='var-INITRAMFS_FSTYPES'><glossterm>INITRAMFS_FSTYPES</glossterm>
             <info>
                 INITRAMFS_FSTYPES[doc] = "Defines the format for the output image of an initial RAM disk (initramfs), which is used during boot."
@@ -6071,7 +6035,7 @@
 
                 <para>
                     See the
-                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
+                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
                     file for additional information.
                     You can also reference the
                     <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass'><filename>kernel.bbclass</filename></ulink>
@@ -6125,7 +6089,7 @@
                         You cannot set the variable in a recipe file.
                     </note>
                     See the
-                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
+                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
                     file for additional information.
                 </para>
             </glossdef>
@@ -6145,7 +6109,7 @@
                 <para>
                     The <filename>INITRD</filename> variable is an optional
                     variable used with the
-                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
                     class.
                 </para>
             </glossdef>
@@ -6277,6 +6241,22 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-INSTALL_TIMEZONE_FILE'><glossterm>INSTALL_TIMEZONE_FILE</glossterm>
+            <info>
+                INSTALL_TIMEZONE_FILE[doc] = "Enables installation of the /etc/timezone file."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    By default, the <filename>tzdata</filename> recipe packages
+                    an <filename>/etc/timezone</filename> file.
+                    Set the <filename>INSTALL_TIMEZONE_FILE</filename>
+                    variable to "0" at the configuration level to disable this
+                    behavior.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-IPK_FEED_URIS'><glossterm>IPK_FEED_URIS</glossterm>
             <info>
                 IPK_FEED_URIS[doc] = "List of ipkg feed records to put into generated image."
@@ -7179,6 +7159,49 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-LICENSE_CREATE_PACKAGE'><glossterm>LICENSE_CREATE_PACKAGE</glossterm>
+            <info>
+                LICENSE_CREATE_PACKAGE[doc] = "Creates an extra package (i.e. ${PN}-lic) for each recipe and adds that package to the RRECOMMENDS+${PN}."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                        Setting <filename>LICENSE_CREATE_PACKAGE</filename>
+                        to "1" causes the OpenEmbedded build system to create
+                        an extra package (i.e.
+                        <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}-lic</filename>)
+                        for each recipe and to add those packages to the
+                        <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link><filename>_${PN}</filename>.
+                </para>
+
+                <para>
+                    The <filename>${PN}-lic</filename> package installs a
+                    directory in <filename>/usr/share/licenses</filename>
+                    named <filename>${PN}</filename>, which is the recipe's
+                    base name, and installs files in that directory that
+                    contain license and copyright information (i.e. copies of
+                    the appropriate license files from
+                    <filename>meta/common-licenses</filename> that match the
+                    licenses specified in the
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>
+                    variable of the recipe metadata and copies of files marked
+                    in
+                    <link linkend='var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></link>
+                    as containing license text).
+                </para>
+
+                <para>
+                    For related information on providing license text, see the
+                    <link linkend='var-COPY_LIC_DIRS'><filename>COPY_LIC_DIRS</filename></link>
+                    variable, the
+                    <link linkend='var-COPY_LIC_MANIFEST'><filename>COPY_LIC_MANIFEST</filename></link>
+                    variable, and the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-LICENSE_FLAGS'><glossterm>LICENSE_FLAGS</glossterm>
             <info>
                 LICENSE_FLAGS[doc] = "Specifies additional flags for a recipe you must whitelist through LICENSE_FLAGS_WHITELIST in order to allow the recipe to be built."
@@ -7774,7 +7797,7 @@
                     is "poky", the default value for
                     <filename>MIRRORS</filename> is defined in the
                     <filename>conf/distro/poky.conf</filename> file in the
-                    <filename>meta-yocto</filename> Git repository.
+                    <filename>meta-poky</filename> Git repository.
                 </para>
             </glossdef>
         </glossentry>
@@ -8066,7 +8089,7 @@
                     Causes the OpenEmbedded build system to skip building the
                     <filename>.hddimg</filename> image.
                     The <filename>NOHDD</filename> variable is used with the
-                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
                     class.
                     Set the variable to "1" to prevent the
                     <filename>.hddimg</filename> image from being built.
@@ -8084,7 +8107,7 @@
                     Causes the OpenEmbedded build system to skip building the
                     ISO image.
                     The <filename>NOISO</filename> variable is used with the
-                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
                     class.
                     Set the variable to "1" to prevent the ISO image from
                     being built.
@@ -8176,6 +8199,28 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-OE_INIT_ENV_SCRIPT'><glossterm>OE_INIT_ENV_SCRIPT</glossterm>
+            <info>
+                OE_INIT_ENV_SCRIPT[doc] = "The name of the build environment setup script for the purposes of setting up the environment within the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    The name of the build environment setup script for the
+                    purposes of setting up the environment within the
+                    extensible SDK.
+                    The default value is "oe-init-build-env".
+                </para>
+
+                <para>
+                    If you use a custom script to set up your build
+                    environment, set the
+                    <filename>OE_INIT_ENV_SCRIPT</filename> variable to its
+                    name.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-OE_TERMINAL'><glossterm>OE_TERMINAL</glossterm>
             <info>
                 OE_TERMINAL[doc] = "Controls how the OpenEmbedded build system spawns interactive terminals on the host development system."
@@ -9539,6 +9584,17 @@
      PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
      PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
                     </literallayout>
+                    <note>
+                        If you set <filename>PREFERRED_PROVIDER</filename>
+                        for a <filename>virtual/*</filename> item, then any
+                        recipe that
+                        <link linkend='var-PROVIDES'><filename>PROVIDES</filename></link>
+                        that item that is not selected by
+                        <filename>PREFERRED_PROVIDER</filename> is prevented
+                        from building, which is usually desirable since this
+                        mechanism is designed to select between mutually
+                        exclusive alternative providers.
+                    </note>
                 </para>
             </glossdef>
         </glossentry>
@@ -9566,6 +9622,23 @@
      PREFERRED_VERSION_python = "2.7.3"
      PREFERRED_VERSION_linux-yocto = "3.19%"
                     </literallayout>
+                    Sometimes the <filename>PREFERRED_VERSION</filename>
+                    variable can be set by configuration files in a way that
+                    is hard to change.
+                    You can use
+                    <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+                    to set a machine-specific override.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     PREFERRED_VERSION_linux-yocto_qemux86 = "3.4%"
+                    </literallayout>
+                    Although not recommended, worst case, you can also use the
+                    "forcevariable" override, which is the strongest override
+                    possible.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     PREFERRED_VERSION_linux-yocto_forcevariable = "3.4%"
+                    </literallayout>
                 </para>
             </glossdef>
         </glossentry>
@@ -9594,7 +9667,7 @@
                     is "poky", the default value for
                     <filename>PREMIRRORS</filename> is defined in the
                     <filename>conf/distro/poky.conf</filename> file in the
-                    <filename>meta-yocto</filename> Git repository.
+                    <filename>meta-poky</filename> Git repository.
                 </para>
 
                 <para>
@@ -9854,35 +9927,6 @@
 
     </glossdiv>
 
-    <glossdiv id='var-glossary-q'><title>Q</title>
-
-        <glossentry id='var-QMAKE_PROFILES'><glossterm>QMAKE_PROFILES</glossterm>
-            <info>
-                QMAKE_PROFILES[doc] = "Specifies your own subset of .pro files to be built for use with qmake."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Specifies your own subset of <filename>.pro</filename>
-                    files to be built for use with
-                    <filename>qmake</filename>.
-                    If you do not set this variable, all
-                    <filename>.pro</filename> files in the directory pointed to
-                    by <link linkend='var-S'><filename>S</filename></link>
-                    will be built by default.
-                </para>
-
-                <para>
-                    This variable is used with recipes that inherit the
-                    <link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
-                    class or other classes that inherit
-                    <filename>qmake_base</filename>.
-                </para>
-            </glossdef>
-        </glossentry>
-
-    </glossdiv>
-
     <glossdiv id='var-glossary-r'><title>R</title>
 
         <glossentry id='var-RANLIB'><glossterm>RANLIB</glossterm>
@@ -10195,7 +10239,7 @@
                 <para>
                     The <filename>ROOTFS</filename> variable is an optional
                     variable used with the
-                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
                     class.
                 </para>
             </glossdef>
@@ -10532,17 +10576,16 @@
                     The location in the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
                     where unpacked recipe source code resides.
-                    This location is within the work directory
-                    (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>),
-                    which is not static.
-                    The unpacked source location depends on the recipe name
-                    (<filename><link linkend='var-PN'>PN</link></filename>) and
-                    recipe version
-                    (<filename><link linkend='var-PV'>PV</link></filename>) as
-                    follows:
-                    <literallayout class='monospaced'>
-     ${WORKDIR}/${PN}-${PV}
-                    </literallayout>
+                    By default, this directory is
+                    <filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}/${</filename><link linkend='var-BPN'><filename>BPN</filename></link><filename>}-${</filename><link linkend='var-PV'><filename>PV</filename></link><filename>}</filename>,
+                    where <filename>${BPN}</filename> is the base recipe name
+                    and <filename>${PV}</filename> is the recipe version.
+                    If the source tarball extracts the code to a directory
+                    named anything other than <filename>${BPN}-${PV}</filename>,
+                    or if the source code if fetched from an SCM such as
+                    Git or Subversion, then you must set <filename>S</filename>
+                    in the recipe so that the OpenEmbedded build system
+                    knows where to find the unpacked source.
                 </para>
 
                 <para>
@@ -10556,6 +10599,22 @@
                     <literallayout class='monospaced'>
      poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
                     </literallayout>
+                    The unpacked source code resides in the
+                    <filename>db-5.1.19</filename> folder.
+                </para>
+
+                <para>
+                    This next example assumes a Git repository.
+                    By default, Git repositories are cloned to
+                    <filename>${WORKDIR}/git</filename> during
+                    <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>.
+                    Since this path is different from the default value of
+                    <filename>S</filename>, you must set it specifically
+                    so the source can be located:
+                    <literallayout class='monospaced'>
+     SRC_URI = "git://path/to/repo.git"
+     S = "${WORKDIR}/git"
+                    </literallayout>
                 </para>
             </glossdef>
         </glossentry>
@@ -10661,6 +10720,30 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SDK_EXT_TYPE'><glossterm>SDK_EXT_TYPE</glossterm>
+            <info>
+                SDK_EXT_TYPE[doc] = "Controls whether or not shared state artifacts are copied into the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Controls whether or not shared state artifacts are copied
+                    into the extensible SDK.
+                    The default value of "full" copies all of the required
+                    shared state artifacts into the extensible SDK.
+                    The value "minimal" leaves these artifacts out of the
+                    SDK.
+                    <note>
+                        If you set the variable to "minimal", you need to
+                        ensure
+                        <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+                        is set in the SDK's configuration to enable the
+                        artifacts to be fetched as needed.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDK_HOST_MANIFEST'><glossterm>SDK_HOST_MANIFEST</glossterm>
             <info>
                 SDK_HOST_MANIFEST[doc] = "The manifest file for the host part of the SDK. This file lists all the installed packages that make up the host part of the SDK."
@@ -10694,6 +10777,88 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SDK_INCLUDE_PKGDATA'><glossterm>SDK_INCLUDE_PKGDATA</glossterm>
+            <info>
+                SDK_INCLUDE_PKGDATA[doc] = "When set to "1", specifies to include the packagedata for all recipes in the "world" target in the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    When set to "1", specifies to include the packagedata for
+                    all recipes in the "world" target in the extensible SDK.
+                    Including this data allows the
+                    <filename>devtool search</filename> command to find these
+                    recipes in search results, as well as allows the
+                    <filename>devtool add</filename> command to map
+                    dependencies more effectively.
+                    <note>
+                        Enabling the <filename>SDK_INCLUDE_PKGDATA</filename>
+                        variable significantly increases build time because
+                        all of world needs to be built.
+                        Enabling the variable also slightly increases the size
+                        of the extensible SDK.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_INHERIT_BLACKLIST'><glossterm>SDK_INHERIT_BLACKLIST</glossterm>
+            <info>
+                SDK_INHERIT_BLACKLIST[doc] = "A list of classes to remove from the INHERIT value globally within the extensible SDK configuration."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of classes to remove from the
+                    <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
+                    value globally within the extensible SDK configuration.
+                    The default value is "buildhistory icecc".
+                </para>
+
+                <para>
+                    Some classes are not generally applicable within
+                    the extensible SDK context and you can use this variable
+                    to disable them.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_LOCAL_CONF_BLACKLIST'><glossterm>SDK_LOCAL_CONF_BLACKLIST</glossterm>
+            <info>
+                SDK_LOCAL_CONF_BLACKLIST[doc] = "A list of variables not allowed through from the build system configuration into the extensible SDK configuration."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of variables not allowed through from the build
+                    system configuration into the extensible SDK configuration.
+                    Usually, these are variables that are specific to the
+                    machine on which the build system is running and thus
+                    would be potentially problematic within the extensible SDK.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_LOCAL_CONF_WHITELIST'><glossterm>SDK_LOCAL_CONF_WHITELIST</glossterm>
+            <info>
+                SDK_LOCAL_CONF_WHITELIST[doc] = "A list of variables allowed through from the build system configuration into the extensible SDK configuration."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of variables allowed through from the build system
+                    configuration into the extensible SDK configuration.
+                    This list overrides the variables specified using the
+                    <link linkend='var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></link>
+                    variable as well as any variables identified by automatic
+                    blacklisting due to the "/" character being found at the
+                    start of the value, which is usually indicative of being a
+                    path and thus might not be valid on the system where the
+                    SDK is installed.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDK_NAME'><glossterm>SDK_NAME</glossterm>
             <info>
                 SDK_NAME[doc] = "The base name for SDK output files."
@@ -10814,7 +10979,8 @@
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    The toolchain binary prefix used for nativesdk recipes.
+                    The toolchain binary prefix used for
+                    <filename>nativesdk</filename> recipes.
                     The OpenEmbedded build system uses the
                     <filename>SDK_PREFIX</filename> value to set the
                     <link linkend='var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></link>
@@ -10824,6 +10990,33 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SDK_RECRDEP_TASKS'><glossterm>SDK_RECRDEP_TASKS</glossterm>
+            <info>
+                SDK_RECRDEP_TASKS[doc] = "A list of shared state tasks added to the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of shared state tasks added to the extensible SDK.
+                    By default, the following tasks are added:
+                    <literallayout class='monospaced'>
+     do_populate_lic
+     do_package_qa
+     do_populate_sysroot
+     do_deploy
+                    </literallayout>
+                    Despite the default value of "" for the
+                    <filename>SDK_RECRDEP_TASKS</filename> variable, the
+                    above four tasks are always added to the SDK.
+                    To specify tasks beyond these four, you need to use
+                    the <filename>SDK_RECRDEP_TASKS</filename> variable (e.g.
+                    you are defining additional tasks that are needed in
+                    order to build
+                    <link linkend='var-SDK_TARGETS'><filename>SDK_TARGETS</filename></link>).
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDK_SYS'><glossterm>SDK_SYS</glossterm>
             <info>
                 SDK_SYS[doc] = "Specifies the system, including the architecture and the operating system, for which the SDK will be built."
@@ -10881,6 +11074,64 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SDK_TARGETS'><glossterm>SDK_TARGETS</glossterm>
+            <info>
+                SDK_TARGETS[doc] = "A list of targets to install from shared state as part of the standard or extensible SDK installation."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of targets to install from shared state as part of
+                    the standard or extensible SDK installation.
+                    The default value is "${PN}" (i.e. the image from which
+                    the SDK is built).
+                </para>
+
+                <para>
+                    The <filename>SDK_TARGETS</filename> variable is an
+                    internal variable and typically would not be changed.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_TITLE'><glossterm>SDK_TITLE</glossterm>
+            <info>
+                SDK_TITLE[doc] = "Specifies a title to be printed when running the SDK installer."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies a title to be printed when running the SDK
+                    installer.
+                    The <filename>SDK_TITLE</filename> variable defaults to
+                    "<replaceable>distro</replaceable> SDK" for the standard
+                    SDK and "<replaceable>distro</replaceable> Extensible SDK"
+                    for the extensible SDK, where
+                    <replaceable>distro</replaceable> is the first one of
+                    <link linkend='var-DISTRO_NAME'><filename>DISTRO_NAME</filename></link>
+                    or
+                    <link linkend='var-DISTRO'><filename>DISTRO</filename></link>
+                    that is set in your configuration.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_UPDATE_URL'><glossterm>SDK_UPDATE_URL</glossterm>
+            <info>
+                SDK_UPDATE_URL[doc] = "An optional URL for an update server for the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    An optional URL for an update server for the extensible
+                    SDK.
+                    If set, the value is used as the default update server when
+                    running <filename>devtool sdk-update</filename> within the
+                    extensible SDK.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDK_VENDOR'><glossterm>SDK_VENDOR</glossterm>
             <info>
                 SDK_VENDOR[doc] = "Specifies the name of the SDK vendor."
@@ -10902,7 +11153,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the version of the SDK.
                     The distribution configuration file (e.g.
-                    <filename>/meta-yocto/conf/distro/poky.conf</filename>)
+                    <filename>/meta-poky/conf/distro/poky.conf</filename>)
                     defines the <filename>SDK_VERSION</filename> as follows:
                     <literallayout class='monospaced'>
      SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
@@ -10939,14 +11190,13 @@
 
         <glossentry id='var-SDKMACHINE'><glossterm>SDKMACHINE</glossterm>
             <info>
-                SDKMACHINE[doc] = "Specifies the architecture (i.e. i686 or x86_64) for which to build SDK and ADT items."
+                SDKMACHINE[doc] = "Specifies the architecture (i.e. i686 or x86_64) for which to build SDK items."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    The machine for which the Application Development Toolkit
-                    (ADT) or SDK is built.
-                    In other words, the SDK or ADT is built such that it
+                    The machine for which the SDK is built.
+                    In other words, the SDK is built such that it
                     runs on the target you specify with the
                     <filename>SDKMACHINE</filename> value.
                     The value points to a corresponding
@@ -11892,14 +12142,14 @@
                         <listitem><para>For recipes building for the target
                            machine, the value is "${STAGING_DIR}/${MACHINE}".
                            </para></listitem>
-                        <listitem><para>For <filename>native</filename>
-                           recipes building
+                        <listitem><para>For native recipes building
                            for the build host, the value is empty given the
                            assumption that when building for the build host,
                            the build host's own directories should be used.
                            </para></listitem>
-                        <listitem><para>For <filename>nativesdk</filename>
-                           recipes that build for the SDK, the value is
+                        <listitem><para>For native SDK
+                           recipes that build for the SDK
+                           (<filename>nativesdk</filename>), the value is
                            "${STAGING_DIR}/${MULTIMACH_HOST_SYS}".
                            </para></listitem>
                     </itemizedlist>
@@ -12707,12 +12957,13 @@
                             "${<link linkend='var-TARGET_SYS'>TARGET_SYS</link>}-".
                             </para></listitem>
                         <listitem><para>
-                            For <filename>native</filename> recipes, the build
-                            system sets the variable to the value of
+                            For native recipes, the build system sets the
+                            variable to the value of
                             <filename>BUILD_PREFIX</filename>.
                             </para></listitem>
                         <listitem><para>
-                            For <filename>nativesdk</filename> recipes, the
+                            For native SDK recipes
+                            (<filename>nativesdk</filename>), the
                             build system sets the variable to the value of
                             <filename>SDK_PREFIX</filename>.
                             </para></listitem>
@@ -12751,9 +13002,8 @@
                     Consider these two examples:
                     <itemizedlist>
                         <listitem><para>
-                            Given a <filename>native</filename> recipe on a
-                            32-bit, x86 machine running Linux, the value is
-                            "i686-linux".
+                            Given a native recipe on a 32-bit, x86 machine
+                            running Linux, the value is "i686-linux".
                             </para></listitem>
                         <listitem><para>
                             Given a recipe being built for a little-endian,
@@ -13359,11 +13609,14 @@
                     toolchain set that runs on the
                     <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
                     and each package should usually have the prefix
-                    "nativesdk-".
-                    When building an SDK using
-                    <filename>bitbake -c populate_sdk &lt;imagename&gt;</filename>,
-                    a default list of packages is set in this variable, but
-                    you can add additional packages to the list.
+                    <filename>nativesdk-</filename>.
+                    For example, consider the following command when
+                    building an SDK:
+                    <literallayout class='monospaced'>
+     $ bitbake -c populate_sdk <replaceable>imagename</replaceable>
+                    </literallayout>
+                    In this case, a default list of packages is set in this
+                    variable, but you can add additional packages to the list.
                 </para>
 
                 <para>
@@ -13373,8 +13626,7 @@
                     section.
                     For information on setting up a cross-development
                     environment, see the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
-                    section in the Yocto Project Application Developer's Guide.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
                 </para>
             </glossdef>
         </glossentry>
@@ -13425,8 +13677,7 @@
                     section.
                     For information on setting up a cross-development
                     environment, see the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
-                    section in the Yocto Project Application Developer's Guide.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
                 </para>
             </glossdef>
         </glossentry>
@@ -14121,7 +14372,7 @@
      USER_CLASSES ?= "buildstats image-mklibs image-prelink"
                     </literallayout>
                     For more information, see
-                    <filename>meta-yocto/conf/local.conf.sample</filename> in
+                    <filename>meta-poky/conf/local.conf.sample</filename> in
                     the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para>

yocto-poky/documentation/ref-manual/technical-details.xml

diff --git a/yocto-poky/documentation/ref-manual/technical-details.xml b/yocto-poky/documentation/ref-manual/technical-details.xml
index 2df3652..f06382a 100644
--- a/yocto-poky/documentation/ref-manual/technical-details.xml
+++ b/yocto-poky/documentation/ref-manual/technical-details.xml
@@ -187,7 +187,7 @@
         This section provides some technical background on how
         cross-development toolchains are created and used.
         For more information on toolchains, you can also see the
-        <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
+        <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
     </para>
 
     <para>
@@ -219,6 +219,12 @@
         You can think of <filename>gcc-cross</filename> simply as an
         automatically generated cross-compiler that is used internally within
         BitBake only.
+        <note>
+            The extensible SDK does not use
+            <filename>gcc-cross-canadian</filename> since this SDK
+            ships a copy of the OpenEmbedded build system and the sysroot
+            within it contains <filename>gcc-cross</filename>.
+        </note>
     </para>
 
     <para>
@@ -282,8 +288,10 @@
         the development tools (e.g., the
         <filename>gcc-cross-canadian</filename>),
         <filename>binutils-cross-canadian</filename>, and other
-        <filename>nativesdk-*</filename> tools you need to cross-compile and
-        test your software.
+        <filename>nativesdk-*</filename> tools,
+        which are tools native to the SDK (i.e. native to
+        <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>),
+        you need to cross-compile and test your software.
         The figure shows the commands you use to easily build out this
         toolchain.
         This cross-development toolchain is built to execute on the
@@ -363,8 +371,9 @@
     <note>
         For information on advantages gained when building a
         cross-development toolchain installer, see the
-        "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-        section in the Yocto Project Application Developer's Guide.
+        "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+        section in the Yocto Project Software Development Kit (SDK) Developer's
+        Guide.
     </note>
 </section>
 
@@ -470,17 +479,24 @@
         </para>
 
         <para>
-            To complicate the problem, there are things that should not be included in
-            the checksum.
+            To complicate the problem, there are things that should not be
+            included in the checksum.
             First, there is the actual specific build path of a given task -
             the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
-            It does not matter if the work directory changes because it should not
-            affect the output for target packages.
-            Also, the build process has the objective of making native or cross packages relocatable.
-            The checksum therefore needs to exclude <filename>WORKDIR</filename>.
+            It does not matter if the work directory changes because it should
+            not affect the output for target packages.
+            Also, the build process has the objective of making native
+            or cross packages relocatable.
+            <note>
+                Both native and cross packages run on the build host.
+                However, cross packages generate output for the target
+                architecture.
+            </note>
+            The checksum therefore needs to exclude
+            <filename>WORKDIR</filename>.
             The simplistic approach for excluding the work directory is to set
-            <filename>WORKDIR</filename> to some fixed value and create the checksum
-            for the "run" script.
+            <filename>WORKDIR</filename> to some fixed value and create the
+            checksum for the "run" script.
         </para>
 
         <para>
@@ -665,7 +681,6 @@
             <literallayout class='monospaced'>
      DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
      SSTATETASKS += "do_deploy"
-     do_deploy[sstate-name] = "deploy"
      do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
      do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
 
@@ -770,22 +785,49 @@
                 Because of this, the Yocto Project includes strong debugging
                 tools:
                 <itemizedlist>
-                    <listitem><para>Whenever a shared state package is written out, so is a
-                        corresponding <filename>.siginfo</filename> file.
-                        This practice results in a pickled Python database of all
-                        the metadata that went into creating the hash for a given shared state
-                        package.</para></listitem>
-                    <listitem><para>If you run BitBake with the <filename>--dump-signatures</filename>
-                        (or <filename>-S</filename>) option, BitBake dumps out
-                        <filename>.siginfo</filename> files in
-                        the stamp directory for every task it would have executed instead of
-                        building the specified target package.</para></listitem>
-                    <listitem><para>There is a <filename>bitbake-diffsigs</filename> command that
-                        can process <filename>.siginfo</filename> files.
-                        If you specify one of these files, BitBake dumps out the dependency
-                        information in the file.
-                        If you specify two files, BitBake compares the two files and dumps out
-                        the differences between the two.
+                    <listitem><para>Whenever a shared state package is written
+                        out into the
+                        <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
+                        a corresponding <filename>.siginfo</filename> file is
+                        also written.
+                        This file contains a pickled Python database of all
+                        the Metadata that went into creating the hash for a
+                        given shared state package.
+                        Whenever a stamp is written into the stamp directory
+                        <link linkend='var-STAMP'><filename>STAMP</filename></link>,
+                        a corresponding <filename>.sigdata</filename> file
+                        is created that contains the same hash data that
+                        represented the executed task.
+                        </para></listitem>
+                    <listitem><para>You can use BitBake to dump out the
+                        signature construction information without executing
+                        tasks by using either of the following BitBake
+                        command-line options:
+                        <literallayout class='monospaced'>
+     &dash;&dash;dump-signatures=<replaceable>SIGNATURE_HANDLER</replaceable>
+     -S <replaceable>SIGNATURE_HANDLER</replaceable>
+                        </literallayout>
+                        <note>
+                            Two common values for
+                            <replaceable>SIGNATURE_HANDLER</replaceable> are
+                            "none" and "printdiff" to only dump the signature
+                            or to compare the dumped signature with the
+                            cached one, respectively.
+                        </note>
+                        Using BitBake with either of these options causes
+                        BitBake to dump out <filename>.sigdata</filename> files
+                        in the stamp directory for every task it would have
+                        executed instead of building the specified target
+                        package.
+                        </para></listitem>
+                    <listitem><para>There is a
+                        <filename>bitbake-diffsigs</filename> command that
+                        can process <filename>.sigdata</filename> and
+                        <filename>.siginfo</filename> files.
+                        If you specify one of these files, BitBake dumps out
+                        the dependency information in the file.
+                        If you specify two files, BitBake compares the two
+                        files and dumps out the differences between the two.
                         This more easily helps answer the question of "What
                         changed between X and Y?"</para></listitem>
                 </itemizedlist>
@@ -1378,7 +1420,6 @@
                 <literallayout class='monospaced'>
      COMMERCIAL_AUDIO_PLUGINS ?= ""
      COMMERCIAL_VIDEO_PLUGINS ?= ""
-     COMMERCIAL_QT = ""
                 </literallayout>
                 If you want to enable these components, you can do so by making sure you have
                 statements similar to the following
@@ -1388,7 +1429,6 @@
         gst-plugins-ugly-mpegaudioparse"
      COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
         gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
-     COMMERCIAL_QT ?= "qmmp"
      LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
                 </literallayout>
                 Of course, you could also create a matching whitelist
@@ -1406,9 +1446,8 @@
                 Specifying audio and video plug-ins as part of the
                 <filename>COMMERCIAL_AUDIO_PLUGINS</filename> and
                 <filename>COMMERCIAL_VIDEO_PLUGINS</filename> statements
-                or commercial Qt components as part of
-                the <filename>COMMERCIAL_QT</filename> statement (along
-                with the enabling <filename>LICENSE_FLAGS_WHITELIST</filename>) includes the
+                (along with the enabling
+                <filename>LICENSE_FLAGS_WHITELIST</filename>) includes the
                 plug-ins or components into built images, thus adding
                 support for media formats or components.
             </para>

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

diff --git a/yocto-poky/documentation/ref-manual/usingpoky.xml b/yocto-poky/documentation/ref-manual/usingpoky.xml
index ca87962..a7bf32d 100644
--- a/yocto-poky/documentation/ref-manual/usingpoky.xml
+++ b/yocto-poky/documentation/ref-manual/usingpoky.xml
@@ -113,8 +113,7 @@
         <filename class="directory">tmp/deploy/images</filename>.
         For information on how to run pre-built images such as <filename>qemux86</filename>
         and <filename>qemuarm</filename>, see the
-        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Example Using Pre-Built Binaries and QEMU</ulink>"
-        section in the Yocto Project Application Developer's Guide.
+        <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
         For information about how to install these images, see the documentation for your
         particular board or machine.
     </para>
@@ -150,10 +149,11 @@
 
     <para>
         For discussions on debugging, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
-        and
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working within Eclipse</ulink>"
-        sections in the Yocto Project Development Manual.
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>" section
+        in the Yocto Project Developer's Manual
+        and the
+        "<ulink url='&YOCTO_DOCS_SDK_URL;#adt-eclipse'>Working within Eclipse</ulink>"
+        section in the Yocto Project Software Development Kit (SDK) Developer's Guide.
     </para>
 
     <note>
@@ -799,12 +799,18 @@
 
         <section id='build-history-sdk-information'>
             <title>Build History SDK Information</title>
+
             <para>
                 Build history collects similar information on the contents
-                of SDKs (e.g. <filename>meta-toolchain</filename>
-                or <filename>bitbake -c populate_sdk imagename</filename>)
+                of SDKs
+                (e.g. <filename>bitbake -c populate_sdk imagename</filename>)
                 as compared to information it collects for images.
-                The following list shows the files produced for each SDK:
+                Furthermore, this information differs depending on whether an
+                extensible or standard SDK is being produced.
+            </para>
+
+            <para>
+                The following list shows the files produced for SDKs:
                 <itemizedlist>
                     <listitem><para><filename>files-in-sdk.txt:</filename>
                         A list of files in the SDK with permissions,
@@ -817,11 +823,49 @@
                         about the SDK.
                         See the following listing example for more information.
                         </para></listitem>
+                    <listitem><para><filename>sstate-task-sizes.txt:</filename>
+                        A text file containing name-value pairs with information
+                        about task group sizes
+                        (e.g. <filename>do_populate_sysroot</filename> tasks
+                        have a total size).
+                        The <filename>sstate-task-sizes.txt</filename> file
+                        exists only when an extensible SDK is created.
+                        </para></listitem>
+                    <listitem><para><filename>sstate-package-sizes.txt:</filename>
+                        A text file containing name-value pairs with information
+                        for the shared-state packages and sizes in the SDK.
+                        The <filename>sstate-package-sizes.txt</filename> file
+                        exists only when an extensible SDK is created.
+                        </para></listitem>
+                    <listitem><para><filename>sdk-files:</filename>
+                        A folder that contains copies of the files mentioned in
+                        <filename>BUILDHISTORY_SDK_FILES</filename> if the
+                        files are present in the output.
+                        Additionally, the default value of
+                        <filename>BUILDHISTORY_SDK_FILES</filename> is specific
+                        to the extensible SDK although you can set it
+                        differently if you would like to pull in specific files
+                        from the standard SDK.</para>
+                        <para>The default files are
+                        <filename>conf/local.conf</filename>,
+                        <filename>conf/bblayers.conf</filename>,
+                        <filename>conf/auto.conf</filename>,
+                        <filename>conf/locked-sigs.inc</filename>, and
+                        <filename>conf/devtool.conf</filename>.
+                        Thus, for an extensible SDK, these files get copied
+                        into the <filename>sdk-files</filename> directory.
+                        </para></listitem>
                     <listitem><para>The following information appears under
                         each of the <filename>host</filename>
                         and <filename>target</filename> directories
                         for the portions of the SDK that run on the host and
                         on the target, respectively:
+                        <note>
+                            The following files for the most part are empty
+                            when producing an extensible SDK because this
+                            type of SDK is not constructed from packages as is
+                            the standard SDK.
+                        </note>
                         <itemizedlist>
                             <listitem><para><filename>depends.dot:</filename>
                                 Dependency graph for the SDK that is

yocto-poky/documentation/sdk-manual/figures/sdk-devtool-add-flow.png

diff --git a/yocto-poky/documentation/sdk-manual/figures/sdk-devtool-add-flow.png b/yocto-poky/documentation/sdk-manual/figures/sdk-devtool-add-flow.png
new file mode 100644
index 0000000..c09e60e
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/figures/sdk-devtool-add-flow.png
Binary files differ

yocto-poky/documentation/sdk-manual/figures/sdk-devtool-modify-flow.png

diff --git a/yocto-poky/documentation/sdk-manual/figures/sdk-devtool-modify-flow.png b/yocto-poky/documentation/sdk-manual/figures/sdk-devtool-modify-flow.png
new file mode 100644
index 0000000..cd06c01
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/figures/sdk-devtool-modify-flow.png
Binary files differ

yocto-poky/documentation/sdk-manual/figures/sdk-eclipse-dev-flow.png

diff --git a/yocto-poky/documentation/sdk-manual/figures/sdk-eclipse-dev-flow.png b/yocto-poky/documentation/sdk-manual/figures/sdk-eclipse-dev-flow.png
new file mode 100644
index 0000000..9f986e0
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/figures/sdk-eclipse-dev-flow.png
Binary files differ

yocto-poky/documentation/sdk-manual/figures/sdk-environment.png

diff --git a/yocto-poky/documentation/sdk-manual/figures/sdk-environment.png b/yocto-poky/documentation/sdk-manual/figures/sdk-environment.png
new file mode 100644
index 0000000..78b8cad
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/figures/sdk-environment.png
Binary files differ

yocto-poky/documentation/sdk-manual/figures/sdk-installed-extensible-sdk-directory.png

diff --git a/yocto-poky/documentation/sdk-manual/figures/sdk-installed-extensible-sdk-directory.png b/yocto-poky/documentation/sdk-manual/figures/sdk-installed-extensible-sdk-directory.png
new file mode 100644
index 0000000..99e07ce
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/figures/sdk-installed-extensible-sdk-directory.png
Binary files differ

yocto-poky/documentation/sdk-manual/figures/sdk-installed-standard-sdk-directory.png

diff --git a/yocto-poky/documentation/sdk-manual/figures/sdk-installed-standard-sdk-directory.png b/yocto-poky/documentation/sdk-manual/figures/sdk-installed-standard-sdk-directory.png
new file mode 100644
index 0000000..d4af850
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/figures/sdk-installed-standard-sdk-directory.png
Binary files differ

yocto-poky/documentation/sdk-manual/figures/sdk-title.png

diff --git a/yocto-poky/documentation/sdk-manual/figures/sdk-title.png b/yocto-poky/documentation/sdk-manual/figures/sdk-title.png
new file mode 100644
index 0000000..e9d5b34
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/figures/sdk-title.png
Binary files differ

yocto-poky/documentation/sdk-manual/sdk-appendix-customizing.xml

diff --git a/yocto-poky/documentation/sdk-manual/sdk-appendix-customizing.xml b/yocto-poky/documentation/sdk-manual/sdk-appendix-customizing.xml
new file mode 100644
index 0000000..7932607
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/sdk-appendix-customizing.xml
@@ -0,0 +1,388 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<appendix id='sdk-appendix-customizing'>
+
+<title>Customizing the SDK</title>
+
+<para>
+    This appendix presents customizations you can apply to both the standard
+    and extensible SDK.
+    Each subsection identifies the type of SDK to which the section applies.
+</para>
+
+<section id='sdk-configuring-the-extensible-sdk'>
+    <title>Configuring the Extensible SDK</title>
+
+    <para>
+        The extensible SDK primarily consists of a pre-configured copy of
+        the OpenEmbedded build system from which it was produced.
+        Thus, the SDK's configuration is derived using that build system and
+        the following filters, which the OpenEmbedded build system applies
+        against <filename>local.conf</filename> and
+        <filename>auto.conf</filename> if they are present:
+        <itemizedlist>
+            <listitem><para>
+                Variables whose values start with "/" are excluded since the
+                assumption is that those values are paths that are likely to
+                be specific to the build host.
+                </para></listitem>
+            <listitem><para>
+                Variables listed in
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></ulink>
+                are excluded.
+                The default value blacklists
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-CONF_VERSION'><filename>CONF_VERSION</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PRSERV_HOST'><filename>PRSERV_HOST</filename></ulink>,
+                and
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></ulink>.
+                </para></listitem>
+            <listitem><para>
+                Variables listed in
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_WHITELIST'><filename>SDK_LOCAL_CONF_WHITELIST</filename></ulink>
+                are included.
+                Including a variable in the value of
+                <filename>SDK_LOCAL_CONF_WHITELIST</filename> overrides either
+                of the above two conditions.
+                The default value is blank.
+                </para></listitem>
+            <listitem><para>
+                Classes inherited globally with
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-INHERIT'><filename>INHERIT</filename></ulink>
+                that are listed in
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></ulink>
+                are disabled.
+                Using <filename>SDK_INHERIT_BLACKLIST</filename> to disable
+                these classes is is the typical method to disable classes that
+                are problematic or unnecessary in the SDK context.
+                The default value blacklists the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-buildhistory'><filename>buildhistory</filename></ulink>
+                and
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-icecc'><filename>icecc</filename></ulink>
+                classes.
+                </para></listitem>
+        </itemizedlist>
+        Additionally, the contents of <filename>conf/sdk-extra.conf</filename>,
+        when present, are appended to the end of
+        <filename>conf/local.conf</filename> within the produced SDK, without
+        any filtering.
+        The <filename>sdk-extra.conf</filename> file is particularly useful
+        if you want to set a variable value just for the SDK and not the
+        OpenEmbedded build system used to create the SDK.
+    </para>
+</section>
+
+<section id='adjusting-the-extensible-sdk-to-suit-your-build-system-setup'>
+    <title>Adjusting the Extensible SDK to Suit Your Build System Setup</title>
+
+    <para>
+        In most cases, the extensible SDK defaults should work.
+        However, some cases exist for which you might consider making
+        adjustments:
+        <itemizedlist>
+            <listitem><para>
+                If your SDK configuration inherits additional classes
+                using the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-INHERIT'><filename>INHERIT</filename></ulink>
+                variable and you do not need or want those classes enabled in
+                the SDK, you can blacklist them by adding them to the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></ulink>
+                variable.
+                The default value of <filename>SDK_INHERIT_BLACKLIST</filename>
+                is set using the "?=" operator.
+                Consequently, you will need to either set the complete value
+                using "=" or append the value using "_append".
+                </para></listitem>
+            <listitem><para>
+                If you have classes or recipes that add additional tasks to
+                the standard build flow (i.e. that execute as part of building
+                the recipe as opposed to needing to be called explicitly), then
+                you need to do one of the following:
+                <itemizedlist>
+                    <listitem><para>
+                        Ensure the tasks are shared state tasks (i.e. their
+                        output is saved to and can be restored from the shared
+                        state cache), or that the tasks are able to be
+                        produced quickly from a task that is a shared state
+                        task and add the task name to the value of
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_RECRDEP_TASKS'><filename>SDK_RECRDEP_TASKS</filename></ulink>.
+                        </para></listitem>
+                    <listitem><para>
+                        Disable the tasks if they are added by a class and
+                        you do not need the functionality the class provides
+                        in the extensible SDK.
+                        To disable the tasks, add the class to
+                        <filename>SDK_INHERIT_BLACKLIST</filename> as previously
+                        described.
+                        </para></listitem>
+                </itemizedlist>
+                </para></listitem>
+            <listitem><para>
+                Generally, you want to have a shared state mirror set up so
+                users of the SDK can add additional items to the SDK after
+                installation without needing to build the items from source.
+                See the
+                "<link linkend='sdk-providing-additional-installable-extensible-sdk-content'>Providing Additional Installable Extensible SDK Content</link>"
+                section for information.
+                </para></listitem>
+            <listitem><para>
+                If you want users of the SDK to be able to easily update the
+                SDK, you need to set the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL'><filename>SDK_UPDATE_URL</filename></ulink>
+                variable.
+                For more information, see the
+                "<link linkend='sdk-providing-updates-after-installing-the-extensible-sdk'>Providing Updates After Installing the Extensible SDK</link>"
+                section.
+                </para></listitem>
+            <listitem><para>
+                If you have adjusted the list of files and directories that
+                appear in
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-COREBASE'><filename>COREBASE</filename></ulink>
+                (other than layers that are enabled through
+                <filename>bblayers.conf</filename>), then you must list these
+                files in
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-COREBASE_FILES'><filename>COREBASE_FILES</filename></ulink>
+                so that the files are copied into the SDK.
+                </para></listitem>
+            <listitem><para>
+                If your OpenEmbedded build system setup uses a different
+                environment setup script other than
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                or
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>,
+                then you must set
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-OE_INIT_ENV_SCRIPT'><filename>OE_INIT_ENV_SCRIPT</filename></ulink>
+                to point to the environment setup script you use.
+                <note>
+                    You must also reflect this change in the value used for the
+                    <filename>COREBASE_FILES</filename> variable as previously
+                    described.
+                </note>
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='sdk-changing-the-appearance-of-the-extensible-sdk'>
+    <title>Changing the Appearance of the Extensible SDK</title>
+
+    <para>
+        You can change the title shown by the SDK installer by setting the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_TITLE'><filename>SDK_TITLE</filename></ulink>
+        variable.
+        By default, this title is derived from
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_NAME'><filename>DISTRO_NAME</filename></ulink>
+        when it is set.
+        If the <filename>DISTRO_NAME</filename> variable is not set, the title
+        is derived from the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
+        variable.
+    </para>
+</section>
+
+<section id='sdk-providing-updates-after-installing-the-extensible-sdk'>
+    <title>Providing Updates After Installing the Extensible SDK</title>
+
+    <para>
+        When you make changes to your configuration or to the metadata and
+        if you want those changes to be reflected in installed SDKs, you need
+        to perform additional steps to make it possible for those that use
+        the SDK to update their installations with the
+        <filename>devtool sdk-update</filename> command:
+        <orderedlist>
+            <listitem><para>
+                Arrange to be created a directory that can be shared over
+                HTTP or HTTPS.
+                </para></listitem>
+            <listitem><para>
+                Set the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL'><filename>SDK_UPDATE_URL</filename></ulink>
+                variable to point to the corresponding HTTP or HTTPS URL.
+                Setting this variable causes any SDK built to default to that
+                URL and thus, the user does not have to pass the URL to the
+                <filename>devtool sdk-update</filename> command.
+                </para></listitem>
+            <listitem><para>
+                Build the extensible SDK normally (i.e., use the
+                <filename>bitbake -c populate_sdk_ext</filename> <replaceable>imagename</replaceable>
+                command).
+                </para></listitem>
+            <listitem><para>
+                Publish the SDK using the following command:
+                <literallayout class='monospaced'>
+     $ oe-publish-sdk <replaceable>some_path</replaceable>/sdk-installer.sh <replaceable>path_to_shared/http_directory</replaceable>
+                </literallayout>
+                You must repeat this step each time you rebuild the SDK
+                with changes that you want to make available through the
+                update mechanism.
+                </para></listitem>
+        </orderedlist>
+    </para>
+
+    <para>
+        Completing the above steps allows users of the existing SDKs to
+        simply run <filename>devtool sdk-update</filename> to retrieve the
+        latest updates.
+        See the
+        "<link linkend='sdk-updating-the-extensible-sdk'>Updating the Extensible SDK</link>"
+        section for further information.
+    </para>
+</section>
+
+<section id='sdk-providing-additional-installable-extensible-sdk-content'>
+    <title>Providing Additional Installable Extensible SDK Content</title>
+
+    <para>
+        If you want the users of the extensible SDK you are building to be
+        able to add items to the SDK without needing to build the
+        items from source, you need to do a number of things:
+        <orderedlist>
+            <listitem><para>
+                Ensure the additional items you want the user to be able to
+                install are actually built.
+                You can ensure these items are built a number of different
+                ways: 1) Build them explicitly, perhaps using one or more
+                "meta" recipes that depend on lists of other recipes to keep
+                things tidy, or 2) Build the "world" target and set
+                <filename>EXCLUDE_FROM_WORLD_pn-</filename><replaceable>recipename</replaceable>
+                for the recipes you do not want built.
+                See the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-EXCLUDE_FROM_WORLD'><filename>EXCLUDE_FROM_WORLD</filename></ulink>
+                variable for additional information.
+                </para></listitem>
+            <listitem><para>
+                Expose the <filename>sstate-cache</filename> directory
+                produced by the build.
+                Typically, you expose this directory over HTTP or HTTPS.
+                </para></listitem>
+            <listitem><para>
+                Set the appropriate configuration so that the produced SDK
+                knows how to find the configuration.
+                The variable you need to set is
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></ulink>:
+                <literallayout class='monospaced'>
+     SSTATE_MIRRORS = "file://.*  http://<replaceable>example</replaceable>.com/<replaceable>some_path</replaceable>/sstate-cache/PATH"
+                </literallayout>
+                You can set the <filename>SSTATE_MIRRORS</filename> variable
+                in two different places:
+                <itemizedlist>
+                    <listitem><para>
+                        If the mirror value you are setting is appropriate to
+                        be set for both the OpenEmbedded build system that is
+                        actually building the SDK and the SDK itself (i.e. the
+                        mirror is accessible in both places or it will fail
+                        quickly on the OpenEmbedded build system side, and its
+                        contents will not interfere with the build), then you
+                        can set the variable in your
+                        <filename>local.conf</filename> or custom distro
+                        configuration file.
+                        You can then "whitelist" the variable through
+                        to the SDK by adding the following:
+                        <literallayout class='monospaced'>
+     SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>
+                        Alternatively, if you just want to set the
+                        <filename>SSTATE_MIRRORS</filename> variable's value
+                        for the SDK alone, create a
+                        <filename>conf/sdk-extra.conf</filename> either in
+                        your
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                        or within any layer and put your
+                        <filename>SSTATE_MIRRORS</filename> setting within
+                        that file.
+                        <note>
+                            This second option is the safest option should
+                            you have any doubts as to which method to use when
+                            setting <filename>SSTATE_MIRRORS</filename>.
+                        </note>
+                        </para></listitem>
+                </itemizedlist>
+                </para></listitem>
+        </orderedlist>
+    </para>
+</section>
+
+<section id='sdk-minimizing-the-size-of-the-extensible-sdk-installer-download'>
+    <title>Minimizing the Size of the Extensible SDK Installer Download</title>
+
+    <para>
+        By default, the extensible SDK bundles the shared state artifacts for
+        everything needed to reconstruct the image for which the SDK was built.
+        This bundling can lead to an SDK installer file that is a Gigabyte or
+        more in size.
+        If the size of this file causes a problem, you can build an SDK that
+        has just enough in it to install and provide access to the
+        <filename>devtool command</filename> by setting the following in your
+        configuration:
+        <literallayout class='monospaced'>
+     SDK_EXT_TYPE = "minimal"
+        </literallayout>
+        Setting
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE'><filename>SDK_EXT_TYPE</filename></ulink>
+        to "minimal" produces an SDK installer that is around 35 Mbytes in
+        size, which downloads and installs quickly.
+        You need to realize, though, that the minimal installer does not
+        install any libraries or tools out of the box.
+        These must be installed either "on the fly" or through actions you
+        perform using <filename>devtool</filename> or explicitly with the
+        <filename>devtool sdk-install</filename> command.
+    </para>
+
+    <para>
+        In most cases, when building a minimal SDK you will need to also enable
+        bringing in the information on a wider range of packages produced by
+        the system.
+        This is particularly true so that <filename>devtool add</filename>
+        is able to effectively map dependencies it discovers in a source tree
+        to the appropriate recipes.
+        Also so that the <filename>devtool search</filename> command
+        is able to return useful results.
+    </para>
+
+    <para>
+        To facilitate this wider range of information, you would additionally
+        set the following:
+        <literallayout class='monospaced'>
+     SDK_INCLUDE_PKGDATA = "1"
+        </literallayout>
+        See the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_PKGDATA'><filename>SDK_INCLUDE_PKGDATA</filename></ulink>
+        variable for additional information.
+    </para>
+
+    <para>
+        Setting the <filename>SDK_INCLUDE_PKGDATA</filename> variable as
+        shown causes the "world" target to be built so that information
+        for all of the recipes included within it are available.
+        Having these recipes available increases build time significantly and
+        increases the size of the SDK installer by 30-80 Mbytes depending on
+        how many recipes are included in your configuration.
+    </para>
+
+    <para>
+        You can use
+        <filename>EXCLUDE_FROM_WORLD_pn-</filename><replaceable>recipename</replaceable>
+        for recipes you want to exclude.
+        However, it is assumed that you would need to be building the "world"
+        target if you want to provide additional items to the SDK.
+        Consequently, building for "world" should not represent undue
+        overhead in most cases.
+        <note>
+            If you set <filename>SDK_EXT_TYPE</filename> to "minimal",
+            then providing a shared state mirror is mandatory so that items
+            can be installed as needed.
+            See the
+            "<link linkend='sdk-providing-additional-installable-extensible-sdk-content'>Providing Additional Installable Extensible SDK Content</link>"
+            section for more information.
+        </note>
+    </para>
+</section>
+</appendix>
+<!--
+vim: expandtab tw=80 ts=4
+-->

yocto-poky/documentation/sdk-manual/sdk-appendix-obtain.xml

diff --git a/yocto-poky/documentation/sdk-manual/sdk-appendix-obtain.xml b/yocto-poky/documentation/sdk-manual/sdk-appendix-obtain.xml
new file mode 100644
index 0000000..3d4e364
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/sdk-appendix-obtain.xml
@@ -0,0 +1,252 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<appendix id='sdk-appendix-obtain'>
+
+<title>Obtaining the SDK</title>
+
+<section id='sdk-locating-pre-built-sdk-installers'>
+    <title>Locating Pre-Built SDK Installers</title>
+
+    <para>
+        You can use existing, pre-built toolchains by locating and running
+        an SDK installer script that ships with the Yocto Project.
+        Using this method, you select and download an architecture-specific
+        toolchain installer and then run the script to hand-install the
+        toolchain.
+    </para>
+
+    <para>
+        You can find SDK installers here:
+        <itemizedlist>
+            <listitem><para><emphasis>Standard SDK Installers</emphasis>
+                Go to <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>
+                and find the folder that matches your host development system
+                (i.e. <filename>i686</filename> for 32-bit machines or
+                <filename>x86_64</filename> for 64-bit machines).</para>
+
+                <para>Go into that folder and download the toolchain installer
+                whose name includes the appropriate target architecture.
+                The toolchains provided by the Yocto Project are based off of
+                the <filename>core-image-sato</filename> image and contain
+                libraries appropriate for developing against that image.
+                For example, if your host development system is a 64-bit x86
+                system and you are going to use your cross-toolchain for a
+                32-bit x86 target, go into the <filename>x86_64</filename>
+                folder and download the following installer:
+                <literallayout class='monospaced'>
+     poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+                </literallayout>
+                </para></listitem>
+            <listitem><para><emphasis>Extensible SDK Installers</emphasis>
+                Installers for the extensible SDK are in
+                <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='sdk-building-an-sdk-installer'>
+    <title>Building an SDK Installer</title>
+
+    <para>
+        As an alternative to locating and downloading a toolchain installer,
+        you can build the toolchain installer assuming you have first sourced
+        the environment setup script.
+        See the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
+        section in the Yocto Project Quick Start for steps that show you
+        how to set up the Yocto Project environment.
+        In particular, you need to be sure the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+        variable matches the architecture for which you are building and that
+        the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>
+        variable is correctly set if you are building a toolchain designed to
+        run on an architecture that differs from your current development host
+        machine (i.e. the build machine).
+    </para>
+
+    <para>
+        To build the toolchain installer for a standard SDK and populate
+        the SDK image, use the following command:
+        <literallayout class='monospaced'>
+     $ bitbake <replaceable>image</replaceable> -c populate_sdk
+        </literallayout>
+        You can do the same for the extensible SDK using this command:
+        <literallayout class='monospaced'>
+     $ bitbake <replaceable>image</replaceable> -c populate_sdk_ext
+        </literallayout>
+        These commands result in a toolchain installer that contains the sysroot
+        that matches your target root filesystem.
+    </para>
+
+    <para>
+        When the <filename>bitbake</filename> command completes, the toolchain
+        installer will be in
+        <filename>tmp/deploy/sdk</filename> in the Build Directory.
+        <note>
+            By default, this toolchain does not build static binaries.
+            If you want to use the toolchain to build these types of libraries,
+            you need to be sure your image has the appropriate static
+            development libraries.
+            Use the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
+            variable inside your <filename>local.conf</filename> file to
+            install the appropriate library packages.
+            Following is an example using <filename>glibc</filename> static
+            development libraries:
+            <literallayout class='monospaced'>
+     IMAGE_INSTALL_append = " glibc-staticdev"
+            </literallayout>
+        </note>
+    </para>
+</section>
+
+<section id='sdk-extracting-the-root-filesystem'>
+    <title>Extracting the Root Filesystem</title>
+
+    <para>
+        After installing the toolchain, for some use cases you
+        might need to separately extract a root filesystem:
+        <itemizedlist>
+            <listitem><para>You want to boot the image using NFS.
+                </para></listitem>
+            <listitem><para>You want to use the root filesystem as the
+                target sysroot.
+                For example, the Eclipse IDE environment with the Eclipse
+                Yocto Plug-in installed allows you to use QEMU to boot
+                under NFS.</para></listitem>
+            <listitem><para>You want to develop your target application
+                using the root filesystem as the target sysroot.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        To extract the root filesystem, first <filename>source</filename>
+        the cross-development environment setup script to establish
+        necessary environment variables.
+        If you built the toolchain in the Build Directory, you will find
+        the toolchain environment script in the
+        <filename>tmp</filename> directory.
+        If you installed the toolchain by hand, the environment setup
+        script is located in <filename>/opt/poky/&DISTRO;</filename>.
+    </para>
+
+    <para>
+        After sourcing the environment script, use the
+        <filename>runqemu-extract-sdk</filename> command and provide the
+        filesystem image.
+    </para>
+
+    <para>
+        Following is an example.
+        The second command sets up the environment.
+        In this case, the setup script is located in the
+        <filename>/opt/poky/&DISTRO;</filename> directory.
+        The third command extracts the root filesystem from a previously
+        built filesystem that is located in the
+        <filename>~/Downloads</filename> directory.
+        Furthermore, this command extracts the root filesystem into the
+        <filename>qemux86-sato</filename> directory:
+        <literallayout class='monospaced'>
+     $ cd ~
+     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+     $ runqemu-extract-sdk \
+        ~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
+        $HOME/qemux86-sato
+        </literallayout>
+        You could now point to the target sysroot at
+        <filename>qemux86-sato</filename>.
+    </para>
+</section>
+
+<section id='sdk-installed-standard-sdk-directory-structure'>
+    <title>Installed Standard SDK Directory Structure</title>
+
+    <para>
+        The following figure shows the resulting directory structure after
+        you install the Standard SDK by running the <filename>.sh</filename>
+        SDK installation script:
+    </para>
+
+    <para>
+        <imagedata fileref="figures/sdk-installed-standard-sdk-directory.png" scale="60" align="center" />
+    </para>
+
+    <para>
+        The installed SDK consists of an environment setup script for the SDK,
+        a configuration file for the target, a version file for the target,
+        and the root filesystem (<filename>sysroots</filename>) needed to
+        develop objects for the target system.
+    </para>
+
+    <para>
+        Within the figure, italicized text is used to indicate replaceable
+        portions of the file or directory name.
+        For example,
+        <replaceable>install_dir</replaceable>/<replaceable>version</replaceable>
+        is the directory where the SDK is installed.
+        By default, this directory is <filename>/opt/poky/</filename>.
+        And, <replaceable>version</replaceable> represents the specific
+        snapshot of the SDK (e.g. <filename>&DISTRO;+snapshot</filename>).
+        Furthermore, <replaceable>target</replaceable> represents the target
+        architecture (e.g. <filename>i586</filename>) and
+        <replaceable>host</replaceable> represents the development system's
+        architecture (e.g. <filename>x86_64</filename>).
+        Thus, the complete names of the two directories within the
+        <filename>sysroots</filename> could be
+        <filename>i586-poky-linux</filename> and
+        <filename>x86_64-pokysdk-linux</filename> for the target and host,
+        respectively.
+    </para>
+</section>
+
+<section id='sdk-installed-extensible-sdk-directory-structure'>
+    <title>Installed Extensible SDK Directory Structure</title>
+
+    <para>
+        The following figure shows the resulting directory structure after
+        you install the Extensible SDK by running the <filename>.sh</filename>
+        SDK installation script:
+    </para>
+
+    <para>
+        <imagedata fileref="figures/sdk-installed-extensible-sdk-directory.png" scale="60" align="center" />
+    </para>
+
+    <para>
+        The installed directory structure for the extensible SDK is quite
+        different than the installed structure for the standard SDK.
+        The extensible SDK does not separate host and target parts in the
+        same manner as does the standard SDK.
+        The extensible SDK uses an embedded copy of the OpenEmbedded
+        build system, which has its own sysroots.
+    </para>
+
+    <para>
+        Of note in the directory structure are an environment setup script
+        for the SDK, a configuration file for the target, a version file for
+        the target, and a log file for the OpenEmbedded build system
+        preparation script run by the installer.
+    </para>
+
+    <para>
+        Within the figure, italicized text is used to indicate replaceable
+        portions of the file or directory name.
+        For example,
+        <replaceable>install_dir</replaceable> is the directory where the SDK
+        is installed, which is <filename>poky_sdk</filename> by default.
+        <replaceable>target</replaceable> represents the target
+        architecture (e.g. <filename>i586</filename>) and
+        <replaceable>host</replaceable> represents the development system's
+        architecture (e.g. <filename>x86_64</filename>).
+    </para>
+</section>
+
+</appendix>
+<!--
+vim: expandtab tw=80 ts=4
+-->

yocto-poky/documentation/sdk-manual/sdk-extensible.xml

diff --git a/yocto-poky/documentation/sdk-manual/sdk-extensible.xml b/yocto-poky/documentation/sdk-manual/sdk-extensible.xml
new file mode 100644
index 0000000..3e11fc9
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/sdk-extensible.xml
@@ -0,0 +1,1304 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='sdk-extensible'>
+
+<title>Using the Extensible SDK</title>
+
+<para>
+    This chapter describes the extensible SDK and how to use it.
+    The extensible SDK makes it easy to add new applications and libraries
+    to an image, modify the source for an existing component, test
+    changes on the target hardware, and ease integration into the rest of the
+    <ulink url='&YOCTO_DOCS_DEV_URL;#build-system-term'>OpenEmbedded build system</ulink>.
+</para>
+
+<para>
+    Information in this chapter covers features that are not part of the
+    standard SDK.
+    In other words, the chapter presents information unique to the
+    extensible SDK only.
+    For information on how to use the standard SDK, see the
+    "<link linkend='sdk-using-the-standard-sdk'>Using the Standard SDK</link>"
+    chapter.
+</para>
+
+<section id='sdk-setting-up-to-use-the-extensible-sdk'>
+    <title>Setting Up to Use the Extensible SDK</title>
+
+    <para>
+        Getting set up to use the extensible SDK is identical to getting set
+        up to use the standard SDK.
+        You still need to locate and run the installer and then run the
+        environment setup script.
+        See the
+        "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>"
+        and the
+        "<link linkend='sdk-running-the-sdk-environment-setup-script'>Running the SDK Environment Setup Script</link>"
+        sections for general information.
+        The following items highlight the only differences between getting
+        set up to use the extensible SDK as compared to the standard SDK:
+        <itemizedlist>
+            <listitem><para><emphasis>Default Installation Directory:</emphasis>
+                By default, the extensible SDK installs into the
+                <filename>poky_sdk</filename> folder of your home directory.
+                As with the standard SDK, you can choose to install the
+                extensible SDK in any location when you run the installer.
+                However, unlike the standard SDK, the location you choose needs
+                to be writable for whichever users need to use the SDK,
+                since files will need to be written under that directory during
+                the normal course of operation.
+                </para></listitem>
+            <listitem><para><emphasis>Build Tools and Build System:</emphasis>
+                The extensible SDK installer performs additional tasks as
+                compared to the standard SDK installer.
+                The extensible SDK installer extracts build tools specific
+                to the SDK and the installer also prepares the internal build
+                system within the SDK.
+                Here is example output for running the extensible SDK
+                installer:
+                <literallayout class='monospaced'>
+     $ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.1+snapshot.sh
+     Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.1+snapshot
+     ===================================================================================
+     Enter target directory for SDK (default: ~/poky_sdk):
+     You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y
+     Extracting SDK......................................................................done
+     Setting it up...
+     Extracting buildtools...
+     Preparing build system...
+     done
+     SDK has been successfully set up and is ready to be used.
+     Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
+      $ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux
+                </literallayout>
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        After installing the SDK, you need to run the SDK environment setup
+        script.
+        Here is the output:
+        <literallayout class='monospaced'>
+     $ source environment-setup-core2-64-poky-linux
+     SDK environment now set up; additionally you may now run devtool to perform development tasks.
+     Run devtool --help for further details.
+        </literallayout>
+        Once you run the environment setup script, you have
+        <filename>devtool</filename> available.
+    </para>
+</section>
+
+<section id='using-devtool-in-your-sdk-workflow'>
+    <title>Using <filename>devtool</filename> in Your SDK Workflow</title>
+
+    <para>
+        The cornerstone of the extensible SDK is a command-line tool
+        called <filename>devtool</filename>.
+        This tool provides a number of features that help
+        you build, test and package software within the extensible SDK, and
+        optionally integrate it into an image built by the OpenEmbedded build
+        system.
+    </para>
+
+    <para>
+        The <filename>devtool</filename> command line is organized similarly
+        to
+        <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> in that it has a
+        number of sub-commands for each function.
+        You can run <filename>devtool --help</filename> to see all the
+        commands.
+    </para>
+
+    <para>
+        Two <filename>devtool</filename> subcommands that provide
+        entry-points into development are:
+        <itemizedlist>
+            <listitem><para><emphasis><filename>devtool add</filename></emphasis>:
+                Assists in adding new software to be built.
+                </para></listitem>
+            <listitem><para><emphasis><filename>devtool modify</filename></emphasis>:
+                Sets up an environment to enable you to modify the source of
+                an existing component.
+                </para></listitem>
+        </itemizedlist>
+        As with the OpenEmbedded build system, "recipes" represent software
+        packages within <filename>devtool</filename>.
+        When you use <filename>devtool add</filename>, a recipe is
+        automatically created.
+        When you use <filename>devtool modify</filename>, the specified
+        existing recipe is used in order to determine where to get the source
+        code and how to patch it.
+        In both cases, an environment is set up so that when you build the
+        recipe a source tree that is under your control is used in order to
+        allow you to make changes to the source as desired.
+        By default, both new recipes and the source go into a "workspace"
+        directory under the SDK.
+    </para>
+
+    <para>
+        The remainder of this section presents the
+        <filename>devtool add</filename> and
+        <filename>devtool modify</filename> workflows.
+    </para>
+
+    <section id='sdk-use-devtool-to-add-an-application'>
+        <title>Use <filename>devtool add</filename> to Add an Application</title>
+
+        <para>
+            The <filename>devtool add</filename> command generates
+            a new recipe based on existing source code.
+            This command takes advantage of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#devtool-the-workspace-layer-structure'>workspace</ulink>
+            layer that many <filename>devtool</filename> commands
+            use.
+            The command is flexible enough to allow you to extract source
+            code into both the workspace or a separate local Git repository
+            and to use existing code that does not need to be extracted.
+        </para>
+
+        <para>
+            Depending on your particular scenario, the arguments and options
+            you use with <filename>devtool add</filename> form different
+            combinations.
+            The following diagram shows common development flows
+            you would use with the <filename>devtool add</filename>
+            command:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/sdk-devtool-add-flow.png" align="center" />
+        </para>
+
+        <para>
+            <orderedlist>
+                <listitem><para><emphasis>Generating the New Recipe</emphasis>:
+                    The top part of the flow shows three scenarios by which
+                    you could use <filename>devtool add</filename> to
+                    generate a recipe based on existing source code.</para>
+
+                    <para>In a shared development environment, it is
+                    typical where other developers are responsible for
+                    various areas of source code.
+                    As a developer, you are probably interested in using
+                    that source code as part of your development using
+                    the Yocto Project.
+                    All you need is access to the code, a recipe, and a
+                    controlled area in which to do your work.</para>
+
+                    <para>Within the diagram, three possible scenarios
+                    feed into the <filename>devtool add</filename> workflow:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Left</emphasis>:
+                            The left scenario represents a common situation
+                            where the source code does not exist locally
+                            and needs to be extracted.
+                            In this situation, you just let it get
+                            extracted to the default workspace - you do not
+                            want it in some specific location outside of the
+                            workspace.
+                            Thus, everything you need will be located in the
+                            workspace:
+                            <literallayout class='monospaced'>
+     $ devtool add <replaceable>recipe fetchuri</replaceable>
+                            </literallayout>
+                            With this command, <filename>devtool</filename>
+                            creates a recipe and an append file in the
+                            workspace as well as extracts the upstream
+                            source files into a local Git repository also
+                            within the <filename>sources</filename> folder.
+                            </para></listitem>
+                        <listitem><para><emphasis>Middle</emphasis>:
+                            The middle scenario also represents a situation where
+                            the source code does not exist locally.
+                            In this case, the code is again upstream
+                            and needs to be extracted to some
+                            local area - this time outside of the default
+                            workspace.
+                            As always, if required <filename>devtool</filename> creates
+                            a Git repository locally during the extraction.
+                            Furthermore, the first positional argument
+                            <replaceable>srctree</replaceable> in this case
+                            identifies where the
+                            <filename>devtool add</filename> command
+                            will locate the extracted code outside of the
+                            workspace:
+                            <literallayout class='monospaced'>
+     $ devtool add <replaceable>recipe srctree fetchuri</replaceable>
+                            </literallayout>
+                            In summary, the source code is pulled from
+                            <replaceable>fetchuri</replaceable> and extracted
+                            into the location defined by
+                            <replaceable>srctree</replaceable> as a local
+                            Git repository.</para>
+
+                            <para>Within workspace, <filename>devtool</filename>
+                            creates both the recipe and an append file
+                            for the recipe.
+                            </para></listitem>
+                        <listitem><para><emphasis>Right</emphasis>:
+                            The right scenario represents a situation
+                            where the source tree (srctree) has been
+                            previously prepared outside of the
+                            <filename>devtool</filename> workspace.
+                            </para>
+
+                            <para>The following command names the recipe
+                            and identifies where the existing source tree
+                            is located:
+                            <literallayout class='monospaced'>
+     $ devtool add <replaceable>recipe srctree</replaceable>
+                            </literallayout>
+                            The command examines the source code and creates
+                            a recipe for it placing the recipe into the
+                            workspace.</para>
+
+                            <para>Because the extracted source code already exists,
+                            <filename>devtool</filename> does not try to
+                            relocate it into the workspace - just the new
+                            the recipe is placed in the workspace.</para>
+
+                            <para>Aside from a recipe folder, the command
+                            also creates an append folder and places an initial
+                            <filename>*.bbappend</filename> within.
+                            </para></listitem>
+                    </itemizedlist>
+                    </para></listitem>
+                <listitem><para><emphasis>Edit the Recipe</emphasis>:
+                    At this point, you can use <filename>devtool edit-recipe</filename>
+                    to open up the editor as defined by the
+                    <filename>$EDITOR</filename> environment variable
+                    and modify the file:
+                    <literallayout class='monospaced'>
+     $ devtool edit-recipe <replaceable>recipe</replaceable>
+                    </literallayout>
+                    From within the editor, you can make modifications to the
+                    recipe that take affect when you build it later.
+                    </para></listitem>
+                <listitem><para><emphasis>Build the Recipe or Rebuild the Image</emphasis>:
+                    At this point in the flow, the next step you
+                    take depends on what you are going to do with
+                    the new code.</para>
+                    <para>If you need to take the build output and eventually
+                    move it to the target hardware, you would use
+                    <filename>devtool build</filename>:
+                    <literallayout class='monospaced'>
+     $ devtool build <replaceable>recipe</replaceable>
+                    </literallayout></para>
+                    <para>On the other hand, if you want an image to
+                    contain the recipe's packages for immediate deployment
+                    onto a device (e.g. for testing purposes), you can use
+                    the <filename>devtool build-image</filename> command:
+                    <literallayout class='monospaced'>
+     $ devtool build-image <replaceable>image</replaceable>
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para><emphasis>Deploy the Build Output</emphasis>:
+                    When you use the <filename>devtool build</filename>
+                    command to build out your recipe, you probably want to
+                    see if the resulting build output works as expected on target
+                    hardware.
+                    <note>
+                        This step assumes you have a previously built
+                        image that is already either running in QEMU or
+                        running on actual hardware.
+                        Also, it is assumed that for deployment of the image
+                        to the target, SSH is installed in the image and if
+                        the image is running on real hardware that you have
+                        network access to and from your development machine.
+                    </note>
+                    You can deploy your build output to that target hardware by
+                    using the <filename>devtool deploy-target</filename> command:
+                    <literallayout class='monospaced'>
+     $ devtool deploy-target <replaceable>recipe target</replaceable>
+                    </literallayout>
+                    The <replaceable>target</replaceable> is a live target machine
+                    running as an SSH server.</para>
+
+                    <para>You can, of course, also deploy the image you build
+                    using the <filename>devtool build-image</filename> command
+                    to actual hardware.
+                    However, <filename>devtool</filename> does not provide a
+                    specific command that allows you to do this.
+                    </para></listitem>
+                <listitem><para><emphasis>Optionally Update the Recipe With Patch Files</emphasis>:
+                    Once you are satisfied with the recipe, if you have made
+                    any changes to the source tree that you want to have
+                    applied by the recipe, you need to generate patches
+                    from those changes.
+                    You do this before moving the recipe
+                    to its final layer and cleaning up the workspace area
+                    <filename>devtool</filename> uses.
+                    This optional step is especially relevant if you are
+                    using or adding third-party software.</para>
+                    <para>To convert commits created using Git to patch files,
+                    use the <filename>devtool update-recipe</filename> command.
+                    <note>
+                        Any changes you want to turn into patches must be
+                        committed to the Git repository in the source tree.
+                    </note>
+                    <literallayout class='monospaced'>
+     $ devtool update-recipe <replaceable>recipe</replaceable>
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para><emphasis>Move the Recipe to its Permanent Layer</emphasis>:
+                    Before cleaning up the workspace, you need to move the
+                    final recipe to its permanent layer.
+                    You must do this before using the
+                    <filename>devtool reset</filename> command if you want to
+                    retain the recipe.
+                    </para></listitem>
+                <listitem><para><emphasis>Reset the Recipe</emphasis>:
+                    As a final step, you can restore the state such that
+                    standard layers and the upstream source is used to build
+                    the recipe rather than data in the workspace.
+                    To reset the recipe, use the <filename>devtool reset</filename>
+                    command:
+                    <literallayout class='monospaced'>
+     $ devtool reset <replaceable>recipe</replaceable>
+                    </literallayout>
+                    </para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+
+    <section id='sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component'>
+        <title>Use <filename>devtool modify</filename> to Modify the Source of an Existing Component</title>
+
+        <para>
+            The <filename>devtool modify</filename> command prepares the
+            way to work on existing code that already has a recipe in
+            place.
+            The command is flexible enough to allow you to extract code,
+            specify the existing recipe, and keep track of and gather any
+            patch files from other developers that are
+            associated with the code.
+        </para>
+
+        <para>
+            Depending on your particular scenario, the arguments and options
+            you use with <filename>devtool modify</filename> form different
+            combinations.
+            The following diagram shows common development flows
+            you would use with the <filename>devtool modify</filename>
+            command:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/sdk-devtool-modify-flow.png" align="center" />
+        </para>
+
+        <para>
+            <orderedlist>
+                <listitem><para><emphasis>Preparing to Modify the Code</emphasis>:
+                    The top part of the flow shows three scenarios by which
+                    you could use <filename>devtool modify</filename> to
+                    prepare to work on source files.
+                    Each scenario assumes the following:
+                    <itemizedlist>
+                        <listitem><para>The recipe exists in some layer external
+                            to the <filename>devtool</filename> workspace.
+                            </para></listitem>
+                        <listitem><para>The source files exist upstream in an
+                            un-extracted state or locally in a previously
+                            extracted state.
+                            </para></listitem>
+                    </itemizedlist>
+                    The typical situation is where another developer has
+                    created some layer for use with the Yocto Project and
+                    their recipe already resides in that layer.
+                    Furthermore, their source code is readily available
+                    either upstream or locally.
+                    <itemizedlist>
+                        <listitem><para><emphasis>Left</emphasis>:
+                            The left scenario represents a common situation
+                            where the source code does not exist locally
+                            and needs to be extracted.
+                            In this situation, the source is extracted
+                            into the default workspace location.
+                            The recipe, in this scenario, is in its own
+                            layer outside the workspace
+                            (i.e.
+                            <filename>meta-</filename><replaceable>layername</replaceable>).
+                            </para>
+
+                            <para>The following command identifies the recipe
+                            and by default extracts the source files:
+                            <literallayout class='monospaced'>
+     $ devtool modify <replaceable>recipe</replaceable>
+                            </literallayout>
+                            Once <filename>devtool</filename>locates the recipe,
+                            it uses the
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                            variable to locate the source code and
+                            any local patch files from other developers are
+                            located.
+                            <note>
+                                You cannot provide an URL for
+                                <replaceable>srctree</replaceable> when using the
+                                <filename>devtool modify</filename> command.
+                            </note>
+                            With this scenario, however, since no
+                            <replaceable>srctree</replaceable> argument exists, the
+                            <filename>devtool modify</filename> command by default
+                            extracts the source files to a Git structure.
+                            Furthermore, the location for the extracted source is the
+                            default area within the workspace.
+                            The result is that the command sets up both the source
+                            code and an append file within the workspace with the
+                            recipe remaining in its original location.
+                            </para></listitem>
+                        <listitem><para><emphasis>Middle</emphasis>:
+                            The middle scenario represents a situation where
+                            the source code also does not exist locally.
+                            In this case, the code is again upstream
+                            and needs to be extracted to some
+                            local area as a Git repository.
+                            The recipe, in this scenario, is again in its own
+                            layer outside the workspace.</para>
+
+                            <para>The following command tells
+                            <filename>devtool</filename> what recipe with
+                            which to work and, in this case, identifies a local
+                            area for the extracted source files that is outside
+                            of the default workspace:
+                            <literallayout class='monospaced'>
+     $ devtool modify <replaceable>recipe srctree</replaceable>
+                            </literallayout>
+                            As with all extractions, the command uses
+                            the recipe's <filename>SRC_URI</filename> to locate the
+                            source files.
+                            Once the files are located, the command by default
+                            extracts them.
+                            Providing the <replaceable>srctree</replaceable>
+                            argument instructs <filename>devtool</filename> where
+                            place the extracted source.</para>
+
+                            <para>Within workspace, <filename>devtool</filename>
+                            creates an append file for the recipe.
+                            The recipe remains in its original location but
+                            the source files are extracted to the location you
+                            provided with <replaceable>srctree</replaceable>.
+                            </para></listitem>
+                        <listitem><para><emphasis>Right</emphasis>:
+                            The right scenario represents a situation
+                            where the source tree
+                            (<replaceable>srctree</replaceable>) exists as a
+                            previously extracted Git structure outside of
+                            the <filename>devtool</filename> workspace.
+                            In this example, the recipe also exists
+                            elsewhere in its own layer.
+                            </para>
+
+                            <para>The following command tells
+                            <filename>devtool</filename> the recipe
+                            with which to work, uses the "-n" option to indicate
+                            source does not need to be extracted, and uses
+                            <replaceable>srctree</replaceable> to point to the
+                            previously extracted source files:
+                            <literallayout class='monospaced'>
+     $ devtool modify -n <replaceable>recipe srctree</replaceable>
+                            </literallayout>
+                            </para>
+
+                            <para>Once the command finishes, it creates only
+                            an append file for the recipe in the workspace.
+                            The recipe and the source code remain in their
+                            original locations.
+                            </para></listitem>
+                        </itemizedlist>
+                    </para></listitem>
+                <listitem><para><emphasis>Edit the Source</emphasis>:
+                    Once you have used the <filename>devtool modify</filename>
+                    command, you are free to make changes to the source
+                    files.
+                    You can use any editor you like to make and save
+                    your source code modifications.
+                    </para></listitem>
+                <listitem><para><emphasis>Build the Recipe</emphasis>:
+                    Once you have updated the source files, you can build
+                    the recipe.
+                    </para></listitem>
+                <listitem><para><emphasis>Deploy the Build Output</emphasis>:
+                    When you use the <filename>devtool build</filename>
+                    command to build out your recipe, you probably want to see
+                    if the resulting build output works as expected on target
+                    hardware.
+                    <note>
+                        This step assumes you have a previously built
+                        image that is already either running in QEMU or
+                        running on actual hardware.
+                        Also, it is assumed that for deployment of the image
+                        to the target, SSH is installed in the image and if
+                        the image is running on real hardware that you have
+                        network access to and from your development machine.
+                    </note>
+                    You can deploy your build output to that target hardware by
+                    using the <filename>devtool deploy-target</filename> command:
+                    <literallayout class='monospaced'>
+     $ devtool deploy-target <replaceable>recipe target</replaceable>
+                    </literallayout>
+                    The <replaceable>target</replaceable> is a live target machine
+                    running as an SSH server.</para>
+
+                    <para>You can, of course, also deploy the image you build
+                    using the <filename>devtool build-image</filename> command
+                    to actual hardware.
+                    However, <filename>devtool</filename> does not provide a
+                    specific command that allows you to do this.
+                    </para></listitem>
+                <listitem><para><emphasis>Optionally Create Patch Files for Your Changes</emphasis>:
+                    After you have debugged your changes, you can
+                    use <filename>devtool update-recipe</filename> to
+                    generate patch files for all the commits you have
+                    made.
+                    <note>
+                        Patch files are generated only for changes
+                        you have committed.
+                    </note>
+                    <literallayout class='monospaced'>
+     $ devtool update-recipe <replaceable>recipe</replaceable>
+                    </literallayout>
+                    By default, the
+                    <filename>devtool update-recipe</filename> command
+                    creates the patch files in a folder named the same
+                    as the recipe beneath the folder in which the recipe
+                    resides, and updates the recipe's
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                    statement to point to the generated patch files.
+                    <note>
+                        You can use the
+                        "--append <replaceable>LAYERDIR</replaceable>"
+                        option to cause the command to create append files
+                        in a specific layer rather than the default
+                        recipe layer.
+                    </note>
+                    </para></listitem>
+                <listitem><para><emphasis>Restore the Workspace</emphasis>:
+                    The <filename>devtool reset</filename> restores the
+                    state so that standard layers and upstream sources are
+                    used to build the recipe rather than what is in the
+                    workspace.
+                    <literallayout class='monospaced'>
+     $ devtool reset <replaceable>recipe</replaceable>
+                    </literallayout>
+                    </para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
+<section id='sdk-a-closer-look-at-devtool-add'>
+    <title>A Closer Look at <filename>devtool add</filename></title>
+
+    <para>
+        The <filename>devtool add</filename> command automatically creates a
+        recipe based on the source tree with which you provide it.
+        Currently, the command has support for the following:
+        <itemizedlist>
+            <listitem><para>
+                Autotools (<filename>autoconf</filename> and
+                <filename>automake</filename>)
+                </para></listitem>
+            <listitem><para>
+                CMake
+                </para></listitem>
+            <listitem><para>
+                Scons
+                </para></listitem>
+            <listitem><para>
+                <filename>qmake</filename>
+                </para></listitem>
+            <listitem><para>
+                Plain <filename>Makefile</filename>
+                </para></listitem>
+            <listitem><para>
+                Out-of-tree kernel module
+                </para></listitem>
+            <listitem><para>
+                Binary package (i.e. "-b" option)
+                </para></listitem>
+            <listitem><para>
+                Node.js module through
+                <filename>npm</filename>
+                </para></listitem>
+            <listitem><para>
+                Python modules that use <filename>setuptools</filename>
+                or <filename>distutils</filename>
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        Apart from binary packages, the determination of how a source tree
+        should be treated is automatic based on the files present within
+        that source tree.
+        For example, if a <filename>CMakeLists.txt</filename> file is found,
+        then the source tree is assumed to be using
+        CMake and is treated accordingly.
+        <note>
+            In most cases, you need to edit the automatically generated
+            recipe in order to make it build properly.
+            Typically, you would go through several edit and build cycles
+            until you can build the recipe.
+            Once the recipe can be built, you could use possible further
+            iterations to test the recipe on the target device.
+        </note>
+    </para>
+
+    <para>
+        The remainder of this section covers specifics regarding how parts
+        of the recipe are generated.
+    </para>
+
+    <section id='sdk-name-and-version'>
+        <title>Name and Version</title>
+
+        <para>
+            If you do not specify a name and version on the command
+            line, <filename>devtool add</filename> attempts to determine
+            the name and version of the software being built from
+            various metadata within the source tree.
+            Furthermore, the command sets the name of the created recipe
+            file accordingly.
+            If the name or version cannot be determined, the
+            <filename>devtool add</filename> command prints an error and
+            you must re-run the command with both the name and version
+            or just the name or version specified.
+        </para>
+
+        <para>
+            Sometimes the name or version determined from the source tree
+            might be incorrect.
+            For such a case, you must reset the recipe:
+            <literallayout class='monospaced'>
+     $ devtool reset -n <replaceable>recipename</replaceable>
+            </literallayout>
+            After running the <filename>devtool reset</filename> command,
+            you need to run <filename>devtool add</filename> again and
+            provide the name or the version.
+        </para>
+    </section>
+
+    <section id='sdk-dependency-detection-and-mapping'>
+        <title>Dependency Detection and Mapping</title>
+
+        <para>
+            The <filename>devtool add</filename> command attempts to
+            detect build-time dependencies and map them to other recipes
+            in the system.
+            During this mapping, the command fills in the names of those
+            recipes in the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
+            value within the recipe.
+            If a dependency cannot be mapped, then a comment is placed in
+            the recipe indicating such.
+            The inability to map a dependency might be caused because the
+            naming is not recognized or because the dependency simply is
+            not available.
+            For cases where the dependency is not available, you must use
+            the <filename>devtool add</filename> command to add an
+            additional recipe to satisfy the dependency and then come
+            back to the first recipe and add its name to
+            <filename>DEPENDS</filename>.
+        </para>
+
+        <para>
+            If you need to add runtime dependencies, you can do so by
+            adding the following to your recipe:
+            <literallayout class='monospaced'>
+     RDEPENDS_${PN} += "dependency1 dependency2 ..."
+            </literallayout>
+            <note>
+                The <filename>devtool add</filename> command often cannot
+                distinguish between mandatory and optional dependencies.
+                Consequently, some of the detected dependencies might
+                in fact be optional.
+                When in doubt, consult the documentation or the configure
+                script for the software the recipe is building for further
+                details.
+                In some cases, you might find you can substitute the
+                dependency for an option to disable the associated
+                functionality passed to the configure script.
+            </note>
+        </para>
+    </section>
+
+    <section id='sdk-license-detection'>
+        <title>License Detection</title>
+
+        <para>
+            The <filename>devtool add</filename> command attempts to
+            determine if the software you are adding is able to be
+            distributed under a common open-source license and sets the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
+            value accordingly.
+            You should double-check this value against the documentation
+            or source files for the software you are building and update
+            that <filename>LICENSE</filename> value if necessary.
+        </para>
+
+        <para>
+            The <filename>devtool add</filename> command also sets the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></ulink>
+            value to point to all files that appear to be license-related.
+            However, license statements often appear in comments at the top
+            of source files or within documentation.
+            Consequently, you might need to amend the
+            <filename>LIC_FILES_CHKSUM</filename> variable to point to one
+            or more of those comments if present.
+            Setting <filename>LIC_FILES_CHKSUM</filename> is particularly
+            important for third-party software.
+            The mechanism attempts to ensure correct licensing should you
+            upgrade the recipe to a newer upstream version in future.
+            Any change in licensing is detected and you receive an error
+            prompting you to check the license text again.
+        </para>
+
+        <para>
+            If the <filename>devtool add</filename> command cannot
+            determine licensing information, the
+            <filename>LICENSE</filename> value is set to "CLOSED" and the
+            <filename>LIC_FILES_CHKSUM</filename> vaule remains unset.
+            This behavior allows you to continue with development but is
+            unlikely to be correct in all cases.
+            Consequently, you should check the documentation or source
+            files for the software you are building to determine the actual
+            license.
+        </para>
+    </section>
+
+    <section id='sdk-adding-makefile-only-software'>
+        <title>Adding Makefile-Only Software</title>
+
+        <para>
+            The use of <filename>make</filename> by itself is very common
+            in both proprietary and open source software.
+            Unfortunately, Makefiles are often not written with
+            cross-compilation in mind.
+            Thus, <filename>devtool add</filename> often cannot do very
+            much to ensure that these Makefiles build correctly.
+            It is very common, for example, to explicitly call
+            <filename>gcc</filename> instead of using the
+            <filename>CC</filename> variable.
+            Usually, in a cross-compilation environment,
+            <filename>gcc</filename> is the compiler for the build host
+            and the cross-compiler is named something similar to
+            <filename>arm-poky-linux-gnueabi-gcc</filename> and might
+            require some arguments (e.g. to point to the associated sysroot
+            for the target machine).
+        </para>
+
+        <para>
+            When writing a recipe for Makefile-only software, keep the
+            following in mind:
+            <itemizedlist>
+                <listitem><para>
+                    You probably need to patch the Makefile to use
+                    variables instead of hardcoding tools within the
+                    toolchain such as <filename>gcc</filename> and
+                    <filename>g++</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    The environment in which <filename>make</filename> runs
+                    is set up with various standard variables for
+                    compilation (e.g. <filename>CC</filename>,
+                    <filename>CXX</filename>, and so forth) in a similar
+                    manner to the environment set up by the SDK's
+                    environment setup script.
+                    One easy way to see these variables is to run the
+                    <filename>devtool build</filename> command on the
+                    recipe and then look in
+                    <filename>oe-logs/run.do_compile</filename>.
+                    Towards the top of this file you will see a list of
+                    environment variables that are being set.
+                    You can take advantage of these variables within the
+                    Makefile.
+                    </para></listitem>
+                <listitem><para>
+                    If the Makefile sets a default for a variable using "=",
+                    that default overrides the value set in the environment,
+                    which is usually not desirable.
+                    In this situation, you can either patch the Makefile
+                    so it sets the default using the "?=" operator, or
+                    you can alternatively force the value on the
+                    <filename>make</filename> command line.
+                    To force the value on the command line, add the
+                    variable setting to
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OEMAKE'><filename>EXTRA_OEMAKE</filename></ulink>
+                    within the recipe as follows:
+                    <literallayout class='monospaced'>
+     EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"
+                    </literallayout>
+                    In the above example, single quotes are used around the
+                    variable settings as the values are likely to contain
+                    spaces because required default options are passed to
+                    the compiler.
+                    </para></listitem>
+                <listitem><para>
+                    Hardcoding paths inside Makefiles is often problematic
+                    in a cross-compilation environment.
+                    This is particularly true because those hardcoded paths
+                    often point to locations on the build host and thus
+                    will either be read-only or will introduce
+                    contamination into the cross-compilation by virtue of
+                    being specific to the build host rather than the target.
+                    Patching the Makefile to use prefix variables or other
+                    path variables is usually the way to handle this.
+                    </para></listitem>
+                <listitem><para>
+                    Sometimes a Makefile runs target-specific commands such
+                    as <filename>ldconfig</filename>.
+                    For such cases, you might be able to simply apply
+                    patches that remove these commands from the Makefile.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='sdk-adding-native-tools'>
+        <title>Adding Native Tools</title>
+
+        <para>
+            Often, you need to build additional tools that run on the
+            build host system as opposed to the target.
+            You should indicate this using one of the following methods
+            when you run <filename>devtool add</filename>:
+            <itemizedlist>
+                <listitem><para>
+                    Specify the name of the recipe such that it ends
+                    with "-native".
+                    Specifying the name like this produces a recipe that
+                    only builds for the build host.
+                    </para></listitem>
+                <listitem><para>
+                    Specify the "&dash;&dash;also-native" option with the
+                    <filename>devtool add</filename> command.
+                    Specifying this option creates a recipe file that still
+                    builds for the target but also creates a variant with
+                    a "-native" suffix that builds for the build host.
+                    </para></listitem>
+            </itemizedlist>
+            <note>
+                If you need to add a tool that is shipped as part of a
+                source tree that builds code for the target, you can
+                typically accomplish this by building the native and target
+                parts separately rather than within the same compilation
+                process.
+                Realize though that with the "&dash;&dash;also-native" option, you
+                can add the tool using just one recipe file.
+            </note>
+        </para>
+    </section>
+
+    <section id='sdk-adding-node-js-modules'>
+        <title>Adding Node.js Modules</title>
+
+        <para>
+            You can use the <filename>devtool add</filename> command in the
+            following form to add Node.js modules:
+            <literallayout class='monospaced'>
+     $ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1"
+            </literallayout>
+            The name and version parameters are mandatory.
+            Lockdown and shrinkwrap files are generated and pointed to by
+            the recipe in order to freeze the version that is fetched for
+            the dependencies according to the first time.
+            This also saves checksums that are verified on future fetches.
+            Together, these behaviors ensure the reproducibility and
+            integrity of the build.
+            <note><title>Notes</title>
+                <itemizedlist>
+                    <listitem><para>
+                        You must use quotes around the URL.
+                        The <filename>devtool add</filename> does not require
+                        the quotes, but the shell considers ";" as a splitter
+                        between multiple commands.
+                        Thus, without the quotes,
+                        <filename>devtool add</filename> does not receive the
+                        other parts, which results in several "command not
+                        found" errors.
+                        </para></listitem>
+                    <listitem><para>
+                        In order to support adding
+                        Node.js modules, a
+                        <filename>nodejs</filename> recipe must be part of your
+                        SDK in order to provide Node.js
+                        itself.
+                        </para></listitem>
+                </itemizedlist>
+            </note>
+        </para>
+    </section>
+</section>
+
+<section id='sdk-working-with-recipes'>
+    <title>Working With Recipes</title>
+
+    <para>
+        When building a recipe with <filename>devtool build</filename> the
+        typical build progression is as follows:
+        <orderedlist>
+            <listitem><para>
+                Fetch the source
+                </para></listitem>
+            <listitem><para>
+                Unpack the source
+                </para></listitem>
+            <listitem><para>
+                Configure the source
+                </para></listitem>
+            <listitem><para>
+                Compiling the source
+                </para></listitem>
+            <listitem><para>
+                Install the build output
+                </para></listitem>
+            <listitem><para>
+                Package the installed output
+                </para></listitem>
+        </orderedlist>
+        For recipes in the workspace, fetching and unpacking is disabled
+        as the source tree has already been prepared and is persistent.
+        Each of these build steps is defined as a function, usually with a
+        "do_" prefix.
+        These functions are typically shell scripts but can instead be written
+        in Python.
+    </para>
+
+    <para>
+        If you look at the contents of a recipe, you will see that the
+        recipe does not include complete instructions for building the
+        software.
+        Instead, common functionality is encapsulated in classes inherited
+        with the <filename>inherit</filename> directive, leaving the recipe
+        to describe just the things that are specific to the software to be
+        built.
+        A <ulink url='ref-classes-base'><filename>base</filename></ulink>
+        class exists that is implicitly inherited by all recipes and provides
+        the functionality that most typical recipes need.
+    </para>
+
+    <para>
+        The remainder of this section presents information useful when
+        working with recipes.
+    </para>
+
+    <section id='sdk-finding-logs-and-work-files'>
+        <title>Finding Logs and Work Files</title>
+
+        <para>
+            When you are debugging a recipe that you previously created using
+            <filename>devtool add</filename> or whose source you are modifying
+            by using the <filename>devtool modify</filename> command, after
+            the first run of <filename>devtool build</filename>, you will
+            find some symbolic links created within the source tree:
+            <filename>oe-logs</filename>, which points to the directory in
+            which log files and run scripts for each build step are created
+            and <filename>oe-workdir</filename>, which points to the temporary
+            work area for the recipe.
+            You can use these links to get more information on what is
+            happening at each build step.
+        </para>
+
+        <para>
+            These locations under <filename>oe-workdir</filename> are
+            particularly useful:
+            <itemizedlist>
+                <listitem><para><filename>image/</filename>:
+                    Contains all of the files installed at the
+                    <ulink url='&YOCTO_DOCS_REF_URL;ref-tasks-install'><filename>do_install</filename></ulink>
+                    stage.
+                    Within a recipe, this directory is referred to by the
+                    expression
+                    <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink><filename>}</filename>.
+                    </para></listitem>
+                <listitem><para><filename>sysroot-destdir/</filename>:
+                    Contains a subset of files installed within
+                    <filename>do_install</filename> that have been put into the
+                    shared sysroot.
+                    For more information, see the
+                    "<link linkend='sdk-sharing-files-between-recipes'>Sharing Files Between Recipes</link>"
+                    section.
+                    </para></listitem>
+                <listitem><para><filename>packages-split/</filename>:
+                    Contains subdirectories for each package produced by the
+                    recipe.
+                    For more information, see the
+                    "<link linkend='sdk-packaging'>Packaging</link>" section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='sdk-setting-configure-arguments'>
+        <title>Setting Configure Arguments</title>
+
+        <para>
+            If the software your recipe is building uses GNU autoconf,
+            then a fixed set of arguments is passed to it to enable
+            cross-compilation plus any extras specified by
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></ulink>
+            set within the recipe.
+            If you wish to pass additional options, add them to
+            <filename>EXTRA_OECONF</filename>.
+            Other supported build tools have similar variables
+            (e.g.
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OECMAKE'><filename>EXTRA_OECMAKE</filename></ulink>
+            for CMake,
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OESCONS'><filename>EXTRA_OESCONS</filename></ulink>
+            for Scons, and so forth).
+            If you need to pass anything on the <filename>make</filename>
+            command line, you can use <filename>EXTRA_OEMAKE</filename> to do
+            so.
+        </para>
+
+        <para>
+            You can use the <filename>devtool configure-help</filename> command
+            to help you set the arguments listed in the previous paragraph.
+            The command determines the exact options being passed, and shows
+            them to you along with any custom arguments specified through
+            <filename>EXTRA_OECONF</filename>.
+            If applicable, the command also shows you the output of the
+            configure script's "&dash;&dash;help" option as a reference.
+        </para>
+    </section>
+
+    <section id='sdk-sharing-files-between-recipes'>
+        <title>Sharing Files Between Recipes</title>
+
+        <para>
+            Recipes often need to use files provided by other recipes on
+            the build host.
+            For example, an application linking to a common library needs
+            access to the library itself and its associated headers.
+            The way this access is accomplished within the extensible SDK is
+            through the sysroot.
+            One sysroot exists per "machine" for which the SDK is being built.
+            In practical terms, this means a sysroot exists for the target
+            machine, and a sysroot exists for the build host.
+        </para>
+
+        <para>
+            Recipes should never write files directly into the sysroot.
+            Instead, files should be installed into standard locations
+            during the
+            <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
+            task within the
+            <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink><filename>}</filename>
+            directory.
+            A subset of these files automatically go into the sysroot.
+            The reason for this limitation is that almost all files that go
+            into the sysroot are cataloged in manifests in order to ensure
+            they can be removed later when a recipe is modified or removed.
+            Thus, the sysroot is able to remain free from stale files.
+        </para>
+    </section>
+
+    <section id='sdk-packaging'>
+        <title>Packaging</title>
+
+        <para>
+            Packaging is not always particularly relevant within the
+            extensible SDK.
+            However, if you examine how build output gets into the final image
+            on the target device, it is important to understand packaging
+            because the contents of the image are expressed in terms of
+            packages and not recipes.
+        </para>
+
+        <para>
+            During the
+            <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package'><filename>do_package</filename></ulink>
+            task, files installed during the
+            <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
+            task are split into one main package, which is almost always named
+            the same as the recipe, and several other packages.
+            This separation is done because not all of those installed files
+            are always useful in every image.
+            For example, you probably do not need any of the documentation
+            installed in a production image.
+            Consequently, for each recipe the documentation files are separated
+            into a <filename>-doc</filename> package.
+            Recipes that package software that has optional modules or
+            plugins might do additional package splitting as well.
+        </para>
+
+        <para>
+            After building a recipe you can see where files have gone by
+            looking in the <filename>oe-workdir/packages-split</filename>
+            directory, which contains a subdirectory for each package.
+            Apart from some advanced cases, the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
+            and
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink>
+            variables controls splitting.
+            The <filename>PACKAGES</filename> variable lists all of the
+            packages to be produced, while the <filename>FILES</filename>
+            variable specifies which files to include in each package,
+            using an override to specify the package.
+            For example, <filename>FILES_${PN}</filename> specifies the files
+            to go into the main package (i.e. the main package is named the
+            same as the recipe and
+            <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
+            evaluates to the recipe name).
+            The order of the <filename>PACKAGES</filename> value is significant.
+            For each installed file, the first package whose
+            <filename>FILES</filename> value matches the file is the package
+            into which the file goes.
+            Defaults exist for both the <filename>PACKAGES</filename> and
+            <filename>FILES</filename> variables.
+            Consequently, you might find you do not even need to set these
+            variables in your recipe unless the software the recipe is
+            building installs files into non-standard locations.
+        </para>
+    </section>
+</section>
+
+<section id='sdk-restoring-the-target-device-to-its-original-state'>
+    <title>Restoring the Target Device to its Original State</title>
+
+    <para>
+        If you use the <filename>devtool deploy-target</filename>
+        command to write a recipe's build output to the target, and
+        you are working on an existing component of the system, then you
+        might find yourself in a situation where you need to restore the
+        original files that existed prior to running the
+        <filename>devtool deploy-target</filename> command.
+        Because the <filename>devtool deploy-target</filename> command
+        backs up any files it overwrites, you can use the
+        <filename>devtool undeploy-target</filename> to restore those files
+        and remove any other files the recipe deployed.
+        Consider the following example:
+        <literallayout class='monospaced'>
+     $ devtool undeploy-target lighttpd root@192.168.7.2
+        </literallayout>
+        If you have deployed multiple applications, you can remove them
+        all at once thus restoring the target device back to its
+        original state:
+        <literallayout class='monospaced'>
+     $ devtool undeploy-target -a root@192.168.7.2
+        </literallayout>
+        Information about files deployed to the target as well as any
+        backed up files are stored on the target itself.
+        This storage of course requires some additional space
+        on the target machine.
+        <note>
+            The <filename>devtool deploy-target</filename> and
+            <filename>devtool undeploy-target</filename> command do not
+            currently interact with any package management system on the
+            target device (e.g. RPM or OPKG).
+            Consequently, you should not intermingle operations
+            <filename>devtool deploy-target</filename> and the package
+            manager operations on the target device.
+            Doing so could result in a conflicting set of files.
+        </note>
+    </para>
+</section>
+
+<section id='sdk-installing-additional-items-into-the-extensible-sdk'>
+    <title>Installing Additional Items Into the Extensible SDK</title>
+
+    <para>
+        The extensible SDK typically only comes with a small number of tools
+        and libraries out of the box.
+        If you have a minimal SDK, then it starts mostly empty and is
+        populated on-demand.
+        However, sometimes you will need to explicitly install extra items
+        into the SDK.
+        If you need these extra items, you can first search for the items
+        using the <filename>devtool search</filename> command.
+        For example, suppose you need to link to libGL but you are not sure
+        which recipe provides it.
+        You can use the following command to find out:
+        <literallayout class='monospaced'>
+     $ devtool search libGL
+     mesa                  A free implementation of the OpenGL API
+        </literallayout>
+        Once you know the recipe (i.e. <filename>mesa</filename> in this
+        example), you can install it:
+        <literallayout class='monospaced'>
+     $ devtool sdk-install mesa
+        </literallayout>
+        By default, the <filename>devtool sdk-install</filename> assumes the
+        item is available in pre-built form from your SDK provider.
+        If the item is not available and it is acceptable to build the item
+        from source, you can add the "-s" option as follows:
+        <literallayout class='monospaced'>
+     $ devtool sdk-install -s mesa
+        </literallayout>
+        It is important to remember that building the item from source takes
+        significantly longer than installing the pre-built artifact.
+        Also, if no recipe exists for the item you want to add to the SDK, you
+        must instead add it using the <filename>devtool add</filename> command.
+    </para>
+</section>
+
+<section id='sdk-updating-the-extensible-sdk'>
+     <title>Updating the Extensible SDK</title>
+
+     <para>
+         If you are working with an extensible SDK that gets occasionally
+         updated (e.g. typically when that SDK has been provided to you by
+         another party), then you will need to manually pull down those
+         updates to your installed SDK.
+     </para>
+
+     <para>
+         To update your installed SDK, run the following:
+         <literallayout class='monospaced'>
+     $ devtool sdk-update
+         </literallayout>
+         The previous command assumes your SDK provider has set the default
+         update URL for you.
+         If that URL has not been set, you need to specify it yourself as
+         follows:
+         <literallayout class='monospaced'>
+     $ devtool sdk-update <replaceable>path_to_update_directory</replaceable>
+         </literallayout>
+         <note>
+             The URL needs to point specifically to a published SDK and not an
+             SDK installer that you would download and install.
+         </note>
+    </para>
+</section>
+
+<section id='sdk-creating-a-derivative-sdk-with-additional-components'>
+    <title>Creating a Derivative SDK With Additional Components</title>
+
+    <para>
+        You might need to produce an SDK that contains your own custom
+        libraries for sending to a third party (e.g., if you are a vendor with
+        customers needing to build their own software for the target platform).
+        If that is the case, then you can produce a derivative SDK based on
+        the currently installed SDK fairly easily.
+        Use these steps:
+        <orderedlist>
+            <listitem><para>If necessary, install an extensible SDK that
+                you want to use as a base for your derivative SDK.
+                </para></listitem>
+            <listitem><para>Source the environment script for the SDK.
+                </para></listitem>
+            <listitem><para>Add the extra libraries or other components
+                you want by using the <filename>devtool add</filename>
+                command.
+                </para></listitem>
+            <listitem><para>Run the <filename>devtool build-sdk</filename>
+                command.
+                </para></listitem>
+        </orderedlist>
+        The above procedure takes the recipes added to the workspace and
+        constructs a new SDK installer containing those recipes and the
+        resulting binary artifacts.
+        The recipes go into their own separate layer in the constructed
+        derivative SDK, leaving the workspace clean and ready for users
+        to add their own recipes.
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->

yocto-poky/documentation/sdk-manual/sdk-intro.xml

diff --git a/yocto-poky/documentation/sdk-manual/sdk-intro.xml b/yocto-poky/documentation/sdk-manual/sdk-intro.xml
new file mode 100644
index 0000000..88ae778
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/sdk-intro.xml
@@ -0,0 +1,338 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='sdk-intro'>
+<title>Introduction</title>
+
+<section id='sdk-manual-intro'>
+    <title>Introduction</title>
+
+    <para>
+        Welcome to the Yocto Project Software Development Kit (SDK)
+        Developer's Guide.
+        This manual provides information that lets you use both the standard
+        Yocto Project SDK and an extensible SDK to develop applications and
+        images using the Yocto Project.
+        Additionally, the manual also provides information on how to use
+        the popular <trademark class='trade'>Eclipse</trademark> IDE as part
+        of your application development workflow.
+    </para>
+
+    <para>
+        Prior to the 2.0 Release of the Yocto Project, application
+        development was primarily accomplished through the use of the
+        Application Development Toolkit (ADT) and the availability
+        of stand-alone cross-development toolchains and other tools.
+        With the 2.1 Release of the Yocto Project, application development
+        has transitioned to within a more traditional SDK and extensible
+        SDK.
+    </para>
+
+    <para>
+        A standard SDK consists of a cross-development toolchain that contains
+        a compiler, debugger, and various miscellaneous tools; libraries,
+        headers, and symbols to match an image; and environment setup script.
+        You can use this SDK to independently develop and test code that is
+        destined to run on some target machine.
+    </para>
+
+    <para>
+        An extensible SDK consists of everything that the standard SDK has plus
+        tools that allow you to easily add new applications and libraries to
+        an image, modify the source of an existing component, test changes on
+        the target hardware, and easily integrate an application into the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-system-term'>OpenEmbedded build system</ulink>.
+    </para>
+
+    <para>
+        SDKs are completely self-contained.
+        The binaries are linked against their own copy of
+        <filename>libc</filename>, which results in no dependencies
+        on the target system.
+        To achieve this, the pointer to the dynamic loader is
+        configured at install time since that path cannot be dynamically
+        altered.
+        This is the reason for a wrapper around the
+        <filename>populate_sdk</filename> and
+        <filename>populate_sdk_ext</filename> archives.
+    </para>
+
+    <para>
+        Another feature for the SDKs is that only one set of cross-canadian
+        toolchain binaries are produced per architecture.
+        This feature takes advantage of the fact that the target hardware can
+        be passed to <filename>gcc</filename> as a set of compiler options.
+        Those options are set up by the environment script and contained in
+        variables such as
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>
+        and
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink>.
+        This reduces the space needed for the tools.
+        Understand, however, that a sysroot is still needed for every target
+        since those binaries are target-specific.
+    </para>
+
+    <para>
+        Going beyond the actual SDK, the SDK development environment consists
+        of the following:
+        <itemizedlist>
+            <listitem><para>An architecture-specific cross-toolchain and
+                matching sysroots (target and native) all built by the
+                OpenEmbedded build system.
+                The toolchain and sysroots are based on a
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                configuration and extensions,
+                which allows you to cross-develop on the host machine for the
+                target hardware.
+                </para></listitem>
+            <listitem><para>The Quick EMUlator (QEMU), which lets you simulate
+                target hardware.
+                QEMU is not literally part of the SDK.
+                You must build and include this emulator separately.
+                However, QEMU plays an important role in the development
+                process that revolves around use of and SDK.
+                </para></listitem>
+            <listitem><para>The Eclipse IDE Yocto Plug-in.
+                This plug-in is also available for you if you are an Eclipse
+                user.
+                In the same manner as QEMU, the plug-in is not literally part
+                of the SDK but is rather available for use as part of the
+                development process.
+                </para></listitem>
+            <listitem><para>Various user-space tools that greatly enhance
+                your application development experience.
+                These tools are also separate from the actual SDK but can be
+                independently obtained and used in the development process.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <section id='the-cross-development-toolchain'>
+        <title>The Cross-Development Toolchain</title>
+
+        <para>
+            The
+            <ulink url='&YOCTO_DOCS_DEV_URL;#cross-development-toolchain'>Cross-Development Toolchain</ulink>
+            consists of a cross-compiler, cross-linker, and cross-debugger
+            that are used to develop user-space applications for targeted
+            hardware.
+            This toolchain is created by running a toolchain installer script
+            or through a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            that is based on your Metadata configuration or extension for
+            your targeted device.
+            The cross-toolchain works with a matching target sysroot.
+        </para>
+    </section>
+
+    <section id='sysroot'>
+        <title>Sysroots</title>
+
+        <para>
+            The native and target sysroots contain needed headers and libraries
+            for generating binaries that run on the target architecture.
+            The target sysroot is based on the target root filesystem image
+            that is built by the OpenEmbedded build system 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 not part of the SDK but is made available a number of ways:
+            <itemizedlist>
+                <listitem><para>
+                    If you have cloned the <filename>poky</filename> Git
+                    repository to create a
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    and you have sourced the environment setup script, QEMU is
+                    installed and automatically available.
+                    </para></listitem>
+                <listitem><para>
+                    If you have downloaded a Yocto Project release and unpacked
+                    it to create a
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    and you have sourced the environment setup script, QEMU is
+                    installed and automatically available.
+                    </para></listitem>
+                <listitem><para>
+                    If you have installed the cross-toolchain tarball and you
+                    have sourced the toolchain's setup environment script, QEMU
+                    is also installed and automatically available.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='eclipse-overview'>
+        <title>Eclipse Yocto Plug-in</title>
+
+        <para>
+            The Eclipse IDE is a popular development environment and it fully
+            supports development using the Yocto Project.
+            When you install and configure the Eclipse Yocto Project Plug-in
+            into the Eclipse IDE, you maximize your Yocto Project 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, deployment, and
+            execution of your output into a QEMU emulation session.
+            You can also perform cross-debugging and profiling.
+            The environment also supports a suite of tools that allows you to
+            perform remote profiling, tracing, collection of power data,
+            collection of latency data, and collection of performance data.
+        </para>
+
+        <para>
+            For information about the application development workflow that
+            uses the Eclipse IDE and for a detailed example of how to install
+            and configure the Eclipse Yocto Project Plug-in, see the
+            "<link link='sdk-developing-applications-using-eclipse'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></link>"
+            section.
+        </para>
+    </section>
+
+    <section id='user-space-tools'>
+        <title>User-Space Tools</title>
+
+        <para>
+            User-space tools are available as part of the SDK development
+            process and can be helpful.
+            The tools include LatencyTOP, PowerTOP, 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.
+                    </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='https://01.org/powertop/'></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/'></ulink>.
+                    For examples on how to setup and use this tool, see the
+                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
+                    section in the Yocto Project Profiling and Tracing Manual.
+                    </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 Eclipse IDE Yocto Plug-in.
+                    See <ulink url='http://sourceware.org/systemtap'></ulink>
+                    for more information on SystemTap.
+                    For examples on how to setup and use this tool, see the
+                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-systemtap'>SystemTap</ulink>"
+                    section in the Yocto Project Profiling and Tracing Manual.
+                    </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>
+
+<section id='sdk-development-model'>
+    <title>SDK Development Model</title>
+
+    <para>
+        Fundamentally, the SDK fits into the development process as follows:
+        <imagedata fileref="figures/sdk-environment.png" align="center" width="6in" depth="5in" scalefit="100" />
+        The SDK is installed on any machine and can be used to develop
+        applications, images, and kernels.
+        An SDK can even be used by a QA Engineer or Release Engineer.
+        The fundamental concept is that the machine that has the SDK installed
+        does not have to be associated with the machine that has the
+        Yocto Project installed.
+        A developer can independently compile and test an object on their
+        machine and then, when the object is ready for integration into an
+        image, they can simply make it available to the machine that has the
+        the Yocto Project.
+        Once the object is available, the image can be rebuilt using the
+        Yocto Project to produce the modified image.
+    </para>
+
+    <para>
+        You just need to follow these general steps:
+        <orderedlist>
+            <listitem><para><emphasis>Install the SDK for your target hardware:</emphasis>
+                For information on how to install the SDK, see the
+                "<link url='sdk-installing-the-sdk'>Installing the SDK</link>"
+                section.</para></listitem>
+            <listitem><para><emphasis>Download the Target Image:</emphasis>
+                The Yocto Project supports several target architectures
+                and has many pre-built kernel images and root filesystem
+                images.</para>
+                <para>If you are going to develop your application on
+                hardware, go to the
+                <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
+                download area and choose a target machine area
+                from which to download the kernel image and root filesystem.
+                This download area could have several files in it that
+                support development using actual hardware.
+                For example, the area might contain
+                <filename>.hddimg</filename> files that combine the
+                kernel image with the filesystem, boot loaders, and
+                so forth.
+                Be sure to get the files you need for your particular
+                development process.</para>
+                <para>If you are going to develop your application and
+                then run and test it using the QEMU emulator, go to the
+                <ulink url='&YOCTO_QEMU_DL_URL;'><filename>machines/qemu</filename></ulink>
+                download area.
+                From this area, go down into the directory for your
+                target architecture (e.g. <filename>qemux86_64</filename>
+                for an <trademark class='registered'>Intel</trademark>-based
+                64-bit architecture).
+                Download kernel, root filesystem, and any other files you
+                need for your process.
+                <note>In order to use the root filesystem in QEMU, you
+                need to extract it.
+                See the
+                "<link url='sdk-extracting-the-root-filesystem'>Extracting the Root Filesystem</link>"
+                section for information on how to extract the root
+                filesystem.</note></para></listitem>
+            <listitem><para><emphasis>Develop and Test your
+                Application:</emphasis>  At this point, you have the tools
+                to develop your application.
+                If you need to separately install and use the QEMU
+                emulator, you can go to
+                <ulink url='http://wiki.qemu.org/Main_Page'>QEMU Home Page</ulink>
+                to download and learn about the emulator.
+                You can see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>"
+                chapter in the Yocto Project Development Manual
+                for information on using QEMU within the Yocto
+                Project.</para></listitem>
+        </orderedlist>
+    </para>
+
+    <para>
+        The remainder of this manual describes how to use both the standard
+        SDK and the extensible SDK.
+        Information also exists in appendix form that describes how you can
+        build, install, and modify an SDK.
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->

yocto-poky/documentation/sdk-manual/sdk-manual-customization.xsl

diff --git a/yocto-poky/documentation/sdk-manual/sdk-manual-customization.xsl b/yocto-poky/documentation/sdk-manual/sdk-manual-customization.xsl
new file mode 100644
index 0000000..dae992c
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/sdk-manual-customization.xsl
@@ -0,0 +1,27 @@
+<?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://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
+-->
+
+  <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
+
+<!--
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
+
+-->
+
+  <xsl:include href="../template/permalinks.xsl"/>
+  <xsl:include href="../template/section.title.xsl"/>
+  <xsl:include href="../template/component.title.xsl"/>
+  <xsl:include href="../template/division.title.xsl"/>
+  <xsl:include href="../template/formal.object.heading.xsl"/>
+
+  <xsl:param name="html.stylesheet" select="'sdk-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel">A</xsl:param>
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+  <xsl:param name="generate.id.attributes" select="1" />
+
+</xsl:stylesheet>

yocto-poky/documentation/sdk-manual/sdk-manual-eclipse-customization.xsl

diff --git a/yocto-poky/documentation/sdk-manual/sdk-manual-eclipse-customization.xsl b/yocto-poky/documentation/sdk-manual/sdk-manual-eclipse-customization.xsl
new file mode 100644
index 0000000..03555d6
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/sdk-manual-eclipse-customization.xsl
@@ -0,0 +1,37 @@
+<?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://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" />
+-->
+
+  <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" />
+
+<!--
+
+  <xsl:import
+	  href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" />
+
+-->
+
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.quietly" select="1"/>
+  <xsl:param name="chunk.first.sections" select="1"/>
+  <xsl:param name="chunk.section.depth" select="10"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="ulink.target" select="'_self'" />
+  <xsl:param name="base.dir" select="'html/adt-manual/'"/>
+  <xsl:param name="html.stylesheet" select="'../book.css'"/>
+  <xsl:param name="eclipse.manifest" select="0"/>
+  <xsl:param name="create.plugin.xml" select="0"/>
+  <xsl:param name="suppress.navigation" select="1"/>
+  <xsl:param name="generate.index" select="0"/>
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>

yocto-poky/documentation/sdk-manual/sdk-manual.xml

diff --git a/yocto-poky/documentation/sdk-manual/sdk-manual.xml b/yocto-poky/documentation/sdk-manual/sdk-manual.xml
new file mode 100644
index 0000000..c860782
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/sdk-manual.xml
@@ -0,0 +1,80 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<book id='sdk-manual' lang='en'
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+    <bookinfo>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref='figures/sdk-title.png'
+                    format='SVG'
+                    align='left' scalefit='1' width='100%'/>
+            </imageobject>
+        </mediaobject>
+
+        <title>
+            Yocto Project Software Development Kit (SDK) Developer's Guide
+        </title>
+
+        <authorgroup>
+            <author>
+                <firstname>Scott</firstname> <surname>Rifenbark</surname>
+                <affiliation>
+                    <orgname>Scotty's Documentation Services, LLC</orgname>
+                </affiliation>
+                <email>srifenbark@gmail.com</email>
+            </author>
+        </authorgroup>
+
+        <revhistory>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>April 2016</date>
+                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+            </revision>
+       </revhistory>
+
+    <copyright>
+      <year>&COPYRIGHT_YEAR;</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>
+      <note>
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>
+          from the Yocto Project website.
+      </note>
+
+    </legalnotice>
+
+    </bookinfo>
+
+    <xi:include href="sdk-intro.xml"/>
+
+    <xi:include href="sdk-using.xml"/>
+
+    <xi:include href="sdk-extensible.xml"/>
+
+    <xi:include href="sdk-appendix-obtain.xml"/>
+
+    <xi:include href="sdk-appendix-customizing.xml"/>
+
+<!--    <index id='index'>
+      <title>Index</title>
+    </index>
+-->
+
+</book>
+<!--
+vim: expandtab tw=80 ts=4
+-->

yocto-poky/documentation/sdk-manual/sdk-style.css

diff --git a/yocto-poky/documentation/sdk-manual/sdk-style.css b/yocto-poky/documentation/sdk-manual/sdk-style.css
new file mode 100644
index 0000000..5251896
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/sdk-style.css
@@ -0,0 +1,988 @@
+/*
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+	  Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #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: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("figures/sdk-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;*/
+}
+
+/* This style defines how the permalink character
+   appears by itself and when hovered over with
+   the mouse. */
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+
+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: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2;
+}
+
+.writernotes {
+  color: #ff0000;
+}
+
+.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-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: #f0f0f2;
+   color: #333;
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;
+}
+
+.tip a,
+.note a {
+   color: #333;
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}

yocto-poky/documentation/sdk-manual/sdk-using.xml

diff --git a/yocto-poky/documentation/sdk-manual/sdk-using.xml b/yocto-poky/documentation/sdk-manual/sdk-using.xml
new file mode 100644
index 0000000..1ea47d3
--- /dev/null
+++ b/yocto-poky/documentation/sdk-manual/sdk-using.xml
@@ -0,0 +1,1466 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='sdk-using-the-standard-sdk'>
+
+<title>Using the Standard SDK</title>
+
+<para>
+    This chapter describes the standard SDK and how to use it.
+    Information covers the pieces of the SDK, how to install it, and presents
+    several task-based procedures common for developing with a standard SDK.
+    <note>
+        The tasks you can perform using a standard SDK are also applicable
+        when you are using an extensible SDK.
+        For information on the differences when using an extensible SDK as
+        compared to an extensible SDK, see the
+        "<link linkend='sdk-extensible'>Using the Extensible SDK</link>"
+        chapter.
+    </note>
+</para>
+
+<section id='sdk-standard-sdk-intro'>
+    <title>Why use the Standard SDK and What is in It?</title>
+
+    <para>
+        The Standard SDK provides a cross-development toolchain and libraries
+        tailored to the contents of a specific image.
+        You would use the Standard SDK if you want a more traditional toolchain
+        experience.
+    </para>
+
+    <para>
+        The installed Standard SDK consists of several files and directories.
+        Basically, it contains an SDK environment setup script, some
+        configuration files, and host and target root filesystems to support
+        usage.
+        You can see the directory structure in the
+        "<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
+        section.
+    </para>
+</section>
+
+<section id='sdk-installing-the-sdk'>
+    <title>Installing the SDK</title>
+
+    <para>
+        The first thing you need to do is install the SDK on your host
+        development machine by running the <filename>.sh</filename>
+        installation script.
+    </para>
+
+    <para>
+        You can download a tarball installer, which includes the
+        pre-built toolchain, the <filename>runqemu</filename>
+        script, and support files from the appropriate directory under
+        <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.
+        Toolchains are available for 32-bit and 64-bit x86 development
+        systems from the <filename>i686</filename> and
+        <filename>x86_64</filename> directories, respectively.
+        The toolchains the Yocto Project provides are based off the
+        <filename>core-image-sato</filename> image and contain
+        libraries appropriate for developing against that image.
+        Each type of development system supports five or more target
+        architectures.
+    </para>
+
+    <para>
+        The names of the tarball installer scripts are such that a
+        string representing the host system appears first in the
+        filename and then is immediately followed by a string
+        representing the target architecture.
+        <literallayout class='monospaced'>
+     poky-glibc-<replaceable>host_system</replaceable>-<replaceable>image_type</replaceable>-<replaceable>arch</replaceable>-toolchain-<replaceable>release_version</replaceable>.sh
+
+     Where:
+         <replaceable>host_system</replaceable> is a string representing your development system:
+
+                    i686 or x86_64.
+
+         <replaceable>image_type</replaceable> is the image for which the SDK was built.
+
+         <replaceable>arch</replaceable> is a string representing the tuned target architecture:
+
+                    i586, x86_64, powerpc, mips, armv7a or armv5te
+
+         <replaceable>release_version</replaceable> is a string representing the release number of the
+                Yocto Project:
+
+                    &DISTRO;, &DISTRO;+snapshot
+        </literallayout>
+        For example, the following toolchain installer is for a 64-bit
+        development host system and a i586-tuned target architecture
+        based off the SDK for <filename>core-image-sato</filename> and
+        using the current &DISTRO; snapshot:
+        <literallayout class='monospaced'>
+     poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+        </literallayout>
+    </para>
+
+    <para>
+        The SDK and toolchains are self-contained and by default are installed
+        into <filename>/opt/poky</filename>.
+        However, when you run the SDK installer, you can choose an
+        installation directory.
+        <note>
+            You must change the permissions on the toolchain
+            installer script so that it is executable:
+            <literallayout class='monospaced'>
+     $ chmod +x poky-glibc-x86_64-core-image-sato-i586-toolchain-2.1.sh
+            </literallayout>
+        </note>
+    </para>
+
+    <para>
+        The following command shows how to run the installer given a
+        toolchain tarball for a 64-bit x86 development host system and
+        a 32-bit x86 target architecture.
+        The example assumes the toolchain installer is located in
+        <filename>~/Downloads/</filename>.
+        <note>
+            If you do not have write permissions for the directory
+            into which you are installing the SDK, the installer
+            notifies you and exits.
+            Be sure you have write permissions in the directory and
+            run the installer again.
+        </note>
+        <literallayout class='monospaced'>
+     $ ./poky-glibc-x86_64-core-image-sato-i586-toolchain-2.1.sh
+     Poky (Yocto Project Reference Distro) SDK installer version 2.0
+     ===============================================================
+     Enter target directory for SDK (default: /opt/poky/2.1):
+     You are about to install the SDK to "/opt/poky/2.1". Proceed[Y/n]? Y
+     Extracting SDK.......................................................................done
+     Setting it up...done
+     SDK has been successfully set up and is ready to be used.
+     Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
+      $ . /opt/poky/2.1/environment-setup-i586-poky-linux
+        </literallayout>
+    </para>
+
+    <para>
+        Again, reference the
+        "<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
+        section for more details on the resulting directory structure of
+        the installed SDK.
+    </para>
+</section>
+
+<section id='sdk-running-the-sdk-environment-setup-script'>
+    <title>Running the SDK Environment Setup Script</title>
+
+    <para>
+        Once you have the SDK installed, you must run the SDK environment
+        setup script before you can actually use it.
+        This setup script resides in the directory you chose when you installed
+        the SDK.
+        For information on where this setup script can reside, see the
+        "<link linkend='sdk-appendix-obtain'>Obtaining the SDK</link>"
+        Appendix.
+    </para>
+
+    <para>
+        Before running the script, be sure it is the one that matches the
+        architecture for which you are developing.
+        Environment setup scripts begin with the string
+        "<filename>environment-setup</filename>" and include as part of their
+        name the tuned target architecture.
+        For example, the command to source a setup script for an IA-based
+        target machine using i586 tuning and located in the default SDK
+        installation directory is as follows:
+        <literallayout class='monospaced'>
+     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+        </literallayout>
+        When you run the setup script, many environment variables are
+        defined:
+        <literallayout class='monospaced'>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKTARGETSYSROOT'><filename>SDKTARGETSYSROOT</filename></ulink> - The path to the sysroot used for cross-compilation
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-PKG_CONFIG_PATH'><filename>PKG_CONFIG_PATH</filename></ulink> - The path to the target pkg-config files
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIG_SITE'><filename>CONFIG_SITE</filename></ulink> - A GNU autoconf site file preconfigured for the target
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink> - The minimal command and arguments to run the C compiler
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXX'><filename>CXX</filename></ulink> - The minimal command and arguments to run the C++ compiler
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CPP'><filename>CPP</filename></ulink> - The minimal command and arguments to run the C preprocessor
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-AS'><filename>AS</filename></ulink> - The minimal command and arguments to run the assembler
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink> - The minimal command and arguments to run the linker
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-GDB'><filename>GDB</filename></ulink> - The minimal command and arguments to run the GNU Debugger
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-STRIP'><filename>STRIP</filename></ulink> - The minimal command and arguments to run 'strip', which strips symbols
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-RANLIB'><filename>RANLIB</filename></ulink> - The minimal command and arguments to run 'ranlib'
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-OBJCOPY'><filename>OBJCOPY</filename></ulink> - The minimal command and arguments to run 'objcopy'
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-OBJDUMP'><filename>OBJDUMP</filename></ulink> - The minimal command and arguments to run 'objdump'
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-AR'><filename>AR</filename></ulink> - The minimal command and arguments to run 'ar'
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-NM'><filename>NM</filename></ulink> - The minimal command and arguments to run 'nm'
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></ulink> - The toolchain binary prefix for the target tools
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CROSS_COMPILE'><filename>CROSS_COMPILE</filename></ulink> - The toolchain binary prefix for the target tools
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink> - The minimal arguments for GNU configure
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CFLAGS'><filename>CFLAGS</filename></ulink> - Suggested C flags
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXXFLAGS'><filename>CXXFLAGS</filename></ulink> - Suggested C++ flags
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-LDFLAGS'><filename>LDFLAGS</filename></ulink> - Suggested linker flags when you use CC to link
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CPPFLAGS'><filename>CPPFLAGS</filename></ulink> - Suggested preprocessor flags
+        </literallayout>
+    </para>
+</section>
+
+<section id='autotools-based-projects'>
+    <title>Autotools-Based Projects</title>
+
+    <para>
+        Once you have a suitable cross-toolchain installed, it is very easy to
+        develop a project outside of the OpenEmbedded build system.
+        This section presents a simple "Helloworld" example that shows how
+        to set up, compile, and run the project.
+    </para>
+
+    <section id='creating-and-running-a-project-based-on-gnu-autotools'>
+        <title>Creating and Running a Project Based on GNU Autotools</title>
+
+        <para>
+            Follow these steps to create a simple Autotools-based project:
+            <orderedlist>
+                <listitem><para><emphasis>Create your directory:</emphasis>
+                    Create a clean directory for your project and then make
+                    that directory your working location:
+                    <literallayout class='monospaced'>
+     $ mkdir $HOME/helloworld
+     $ cd $HOME/helloworld
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Populate the directory:</emphasis>
+                    Create <filename>hello.c</filename>, <filename>Makefile.am</filename>,
+                    and <filename>configure.in</filename> files as follows:
+                    <itemizedlist>
+                        <listitem><para>For <filename>hello.c</filename>, include
+                            these lines:
+                            <literallayout class='monospaced'>
+     #include &lt;stdio.h&gt;
+
+     main()
+        {
+           printf("Hello World!\n");
+        }
+                            </literallayout></para></listitem>
+                        <listitem><para>For <filename>Makefile.am</filename>,
+                            include these lines:
+                            <literallayout class='monospaced'>
+     bin_PROGRAMS = hello
+     hello_SOURCES = hello.c
+                            </literallayout></para></listitem>
+                        <listitem><para>For <filename>configure.in</filename>,
+                            include these lines:
+                            <literallayout class='monospaced'>
+     AC_INIT(hello.c)
+     AM_INIT_AUTOMAKE(hello,0.1)
+     AC_PROG_CC
+     AC_PROG_INSTALL
+     AC_OUTPUT(Makefile)
+                            </literallayout></para></listitem>
+                    </itemizedlist></para></listitem>
+                <listitem><para><emphasis>Source the cross-toolchain
+                    environment setup file:</emphasis>
+                    Installation of the cross-toolchain creates a cross-toolchain
+                    environment setup script in the directory that the SDK
+                    was installed.
+                    Before you can use the tools to develop your project, you must
+                    source this setup script.
+                    The script begins with the string "environment-setup" and contains
+                    the machine architecture, which is followed by the string
+                    "poky-linux".
+                    Here is an example that sources a script from the
+                    default SDK installation directory that uses the
+                    32-bit Intel x86 Architecture and the
+                    &DISTRO_NAME; Yocto Project release:
+                    <literallayout class='monospaced'>
+     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Generate the local aclocal.m4
+                    files and create the configure script:</emphasis>
+                    The following GNU Autotools generate the local
+                    <filename>aclocal.m4</filename> files and create the
+                    configure script:
+                    <literallayout class='monospaced'>
+     $ aclocal
+     $ autoconf
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Generate files needed by GNU
+                    coding standards:</emphasis>
+                    GNU coding standards require certain files in order for the
+                    project to be compliant.
+                    This command creates those files:
+                    <literallayout class='monospaced'>
+     $ touch NEWS README AUTHORS ChangeLog
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Generate the configure
+                    file:</emphasis>
+                    This command generates the <filename>configure</filename>:
+                    <literallayout class='monospaced'>
+     $ automake -a
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Cross-compile the project:</emphasis>
+                    This command compiles the project using the cross-compiler.
+                    The
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink>
+                    environment variable provides the minimal arguments for
+                    GNU configure:
+                    <literallayout class='monospaced'>
+     $ ./configure ${CONFIGURE_FLAGS}
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Make and install the project:</emphasis>
+                    These two commands generate and install the project into the
+                    destination directory:
+                    <literallayout class='monospaced'>
+     $ make
+     $ make install DESTDIR=./tmp
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Verify the installation:</emphasis>
+                    This command is a simple way to verify the installation
+                    of your project.
+                    Running the command prints the architecture on which
+                    the binary file can run.
+                    This architecture should be the same architecture that
+                    the installed cross-toolchain supports.
+                    <literallayout class='monospaced'>
+     $ file ./tmp/usr/local/bin/hello
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Execute your project:</emphasis>
+                    To execute the project in the shell, simply enter the name.
+                    You could also copy the binary to the actual target hardware
+                    and run the project there as well:
+                    <literallayout class='monospaced'>
+     $ ./hello
+                    </literallayout>
+                    As expected, the project displays the "Hello World!" message.
+                    </para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+
+    <section id='passing-host-options'>
+        <title>Passing Host Options</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 found in the directory in which you installed the cross-toolchain.
+            For example, the host option for an ARM-based target that uses the GNU EABI
+            is <filename>armv5te-poky-linux-gnueabi</filename>.
+            You will notice that the name of the script is
+            <filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
+            Thus, the following command works to update your project and
+            rebuild it using the appropriate cross-toolchain tools:
+            <literallayout class='monospaced'>
+     $ ./configure --host=armv5te-poky-linux-gnueabi \
+        --with-libtool-sysroot=<replaceable>sysroot_dir</replaceable>
+            </literallayout>
+            <note>
+                If the <filename>configure</filename> script results in problems recognizing the
+                <filename>--with-libtool-sysroot=</filename><replaceable>sysroot-dir</replaceable> option,
+                regenerate the script to enable the support by doing the following and then
+                run the script again:
+                <literallayout class='monospaced'>
+     $ libtoolize --automake
+     $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
+        [-I <replaceable>dir_containing_your_project-specific_m4_macros</replaceable>]
+     $ autoconf
+     $ autoheader
+     $ automake -a
+                </literallayout>
+            </note>
+        </para>
+    </section>
+</section>
+
+<section id='makefile-based-projects'>
+    <title>Makefile-Based Projects</title>
+
+    <para>
+        For Makefile-based projects, the cross-toolchain environment variables
+        established by running the cross-toolchain environment setup script
+        are subject to general <filename>make</filename> rules.
+    </para>
+
+    <para>
+        To illustrate this, consider the following four cross-toolchain
+        environment variables:
+        <literallayout class='monospaced'>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'>CC</ulink>=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'>LD</ulink>=i586-poky-linux-ld --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CFLAGS'>CFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXXFLAGS'>CXXFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
+        </literallayout>
+        Now, consider the following three cases:
+        <itemizedlist>
+            <listitem><para><emphasis>Case 1 - No Variables Set in the <filename>Makefile</filename>:</emphasis>
+                Because these variables are not specifically set in the
+                <filename>Makefile</filename>, the variables retain their
+                values based on the environment.
+                </para></listitem>
+            <listitem><para><emphasis>Case 2 - Variables Set in the <filename>Makefile</filename>:</emphasis>
+                Specifically setting variables in the
+                <filename>Makefile</filename> during the build results in the
+                environment settings of the variables being overwritten.
+                </para></listitem>
+            <listitem><para><emphasis>Case 3 - Variables Set when the <filename>Makefile</filename> is Executed from the Command Line:</emphasis>
+                Executing the <filename>Makefile</filename> from the command
+                line results in the variables being overwritten with
+                command-line content regardless of what is being set in the
+                <filename>Makefile</filename>.
+                In this case, environment variables are not considered unless
+                you use the "-e" flag during the build:
+                <literallayout class='monospaced'>
+     $ make -e <replaceable>file</replaceable>
+                </literallayout>
+                If you use this flag, then the environment values of the
+                variables override any variables specifically set in the
+                <filename>Makefile</filename>.
+                </para></listitem>
+        </itemizedlist>
+        <note>
+            For the list of variables set up by the cross-toolchain environment
+            setup script, see the
+            "<link linkend='sdk-running-the-sdk-environment-setup-script'>Running the SDK Environment Setup Script</link>"
+            section.
+        </note>
+    </para>
+</section>
+
+<section id='sdk-developing-applications-using-eclipse'>
+    <title>Developing Applications Using <trademark class='trade'>Eclipse</trademark></title>
+
+    <para>
+        If you are familiar with the popular Eclipse IDE, you can use an
+        Eclipse Yocto Plug-in to allow you to develop, deploy, and test your
+        application all from within Eclipse.
+        This section describes general workflow using the SDK and Eclipse
+        and how to configure and set up Eclipse.
+    </para>
+
+    <section id='workflow-using-eclipse'>
+
+        <title>Workflow Using <trademark class='trade'>Eclipse</trademark></title>
+
+        <para>
+            The following figure and supporting list summarize the application
+            development general workflow that employs both the SDK Eclipse.
+        </para>
+
+        <para>
+            <imagedata fileref="figures/sdk-eclipse-dev-flow.png"
+                width="7in" depth="7in" align="center" scale="100" />
+        </para>
+
+        <para>
+            <orderedlist>
+                <listitem><para><emphasis>Prepare the host system for the Yocto Project</emphasis>:
+                    See
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
+                    and
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>" sections both
+                    in the Yocto Project Reference Manual for requirements.
+                    In particular, be sure your host system has the
+                    <filename>xterm</filename> package installed.
+                    </para></listitem>
+                <listitem><para><emphasis>Secure the Yocto Project kernel target image</emphasis>:
+                    You must have a target kernel image that has been built using the OpenEmbedded
+                    build system.</para>
+                    <para>Depending on whether the Yocto Project has a pre-built image that matches your target
+                    architecture and where you are going to run the image while you develop your application
+                    (QEMU or real hardware), the area from which you get the image differs.
+                        <itemizedlist>
+                            <listitem><para>Download the image from
+                                <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
+                                if your target architecture is supported and you are going to develop
+                                and test your application on actual hardware.</para></listitem>
+                            <listitem><para>Download the image from
+                                <ulink url='&YOCTO_QEMU_DL_URL;'>
+                                <filename>machines/qemu</filename></ulink> if your target architecture is supported
+                                and you are going to develop and test your application using the QEMU
+                                emulator.</para></listitem>
+                            <listitem><para>Build your image if you cannot find a pre-built image that matches
+                                your target architecture.
+                                If your target architecture is similar to a supported architecture, you can
+                                modify the kernel image before you build it.
+                                See the
+                                "<ulink url='&YOCTO_DOCS_DEV_URL;#patching-the-kernel'>Patching the Kernel</ulink>"
+                                section in the Yocto Project Development
+                                manual for an example.</para></listitem>
+                        </itemizedlist></para>
+                    <para>For information on pre-built kernel image naming schemes for images
+                    that can run on the QEMU emulator, see the
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+                    </para></listitem>
+                <listitem><para><emphasis>Install the SDK</emphasis>:
+                    The SDK provides a target-specific cross-development toolchain, the root filesystem,
+                    the QEMU emulator, and other tools that can help you develop your application.
+                    For information on how to install the SDK, see the
+                    "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>"
+                    section.
+                    </para></listitem>
+                <listitem><para><emphasis>Secure the target root filesystem
+                    and the Cross-development toolchain</emphasis>:
+                    You need to find and download the appropriate root filesystem and
+                    the cross-development toolchain.</para>
+                    <para>You can find the tarballs for the root filesystem in the same area used
+                    for the kernel image.
+                    Depending on the type of image you are running, the root filesystem you need differs.
+                    For example, if you are developing an application that runs on an image that
+                    supports Sato, you need to get a root filesystem that supports Sato.</para>
+                    <para>You can find the cross-development toolchains at
+                    <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>.
+                    Be sure to get the correct toolchain for your development host and your
+                    target architecture.
+                    See the "<link linkend='sdk-locating-pre-built-sdk-installers'>Locating Pre-Built SDK Installers</link>"
+                    section for information and the
+                    "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>"
+                    section for installation information.
+                    </para></listitem>
+                <listitem><para><emphasis>Create and build your application</emphasis>:
+                    At this point, you need to have source files for your application.
+                    Once you have the files, you can use the Eclipse IDE to import them and build the
+                    project.
+                    If you are not using Eclipse, you need to use the cross-development tools you have
+                    installed to create the image.</para></listitem>
+                <listitem><para><emphasis>Deploy the image with the application</emphasis>:
+                    If you are using the Eclipse IDE, you can deploy your image to the hardware or to
+                    QEMU through the project's preferences.
+                    If you are not using the Eclipse IDE, then you need to deploy the application
+                    to the hardware using other methods.
+                    Or, if you are using QEMU, you need to use that tool and
+                    load your image in for testing.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>"
+                    chapter in the Yocto Project Development Manual
+                    for information on using QEMU.
+                    </para></listitem>
+                <listitem><para><emphasis>Test and debug the application</emphasis>:
+                    Once your application is deployed, you need to test it.
+                    Within the Eclipse IDE, you can use the debugging environment along with the
+                    set of installed user-space tools to debug your application.
+                    Of course, the same user-space tools are available separately if you choose
+                    not to use the Eclipse IDE.</para></listitem>
+           </orderedlist>
+        </para>
+    </section>
+
+    <section id='adt-eclipse'>
+        <title>Working Within Eclipse</title>
+
+        <para>
+            The Eclipse IDE is a popular development environment and it fully
+            supports development using the Yocto Project.
+            <note>
+                This release of the Yocto Project supports both the Luna
+                and Kepler versions of the Eclipse IDE.
+                Thus, the following information provides setup information for
+                both versions.
+            </note>
+        </para>
+
+        <para>
+            When you install and configure the Eclipse Yocto Project Plug-in
+            into the Eclipse IDE, you maximize your Yocto Project 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, deployment, and
+            execution of your output into a QEMU emulation session as well as
+            actual target hardware.
+            You can also perform cross-debugging and profiling.
+            The environment also supports a suite of tools that allows you
+            to perform remote profiling, tracing, collection of power data,
+            collection of 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 application.
+        </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>Install the optimal version of the Eclipse
+                       IDE.</para></listitem>
+                    <listitem><para>Configure the Eclipse IDE.
+                       </para></listitem>
+                    <listitem><para>Install the Eclipse Yocto Plug-in.
+                       </para></listitem>
+                    <listitem><para>Configure the Eclipse Yocto Plug-in.
+                       </para></listitem>
+                </orderedlist>
+                <note>
+                    Do not install Eclipse from your distribution's package
+                    repository.
+                    Be sure to install Eclipse from the official Eclipse
+                    download site as directed in the next section.
+                </note>
+            </para>
+
+            <section id='installing-eclipse-ide'>
+                <title>Installing the Eclipse IDE</title>
+
+                <para>
+                    It is recommended that you have the Luna SR2 (4.4.2)
+                    version of the Eclipse IDE installed on your development
+                    system.
+                    However, if you currently have the Kepler 4.3.2 version
+                    installed and you do not want to upgrade the IDE, you can
+                    configure Kepler to work with the Yocto Project.
+                </para>
+
+                <para>
+                    If you do not have the Luna SR2 (4.4.2) Eclipse IDE
+                    installed, you can find the tarball at
+                    <ulink url='&ECLIPSE_MAIN_URL;'></ulink>.
+                    From that site, choose the appropriate download from the
+                    "Eclipse IDE for C/C++ Developers".
+                    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.
+                    For example, the following commands unpack and install the
+                    downloaded Eclipse IDE tarball into a clean directory
+                    using the default name <filename>eclipse</filename>:
+                    <literallayout class='monospaced'>
+     $ cd ~
+     $ tar -xzvf ~/Downloads/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='configuring-the-eclipse-ide'>
+                <title>Configuring the Eclipse IDE</title>
+
+                <para>
+                    This section presents the steps needed to configure the
+                    Eclipse IDE.
+                </para>
+
+                <para>
+                    Before installing and configuring the Eclipse Yocto Plug-in,
+                    you need to configure the Eclipse IDE.
+                    Follow these general steps:
+                    <orderedlist>
+                        <listitem><para>Start the Eclipse IDE.</para></listitem>
+                        <listitem><para>Make sure you are in your Workbench and
+                            select "Install New Software" from the "Help"
+                            pull-down menu.</para></listitem>
+                        <listitem><para>Select
+                            <filename>Luna - &ECLIPSE_LUNA_URL;</filename>
+                            from the "Work with:" pull-down menu.
+                            <note>
+                                For Kepler, select
+                                <filename>Kepler - &ECLIPSE_KEPLER_URL;</filename>
+                            </note>
+                            </para></listitem>
+                        <listitem><para>Expand the box next to "Linux Tools"
+                            and select the
+                            <filename>Linux Tools LTTng Tracer Control</filename>,
+                            <filename>Linux Tools LTTng Userspace Analysis</filename>,
+                            and
+                            <filename>LTTng Kernel Analysis</filename> boxes.
+                            If these selections do not appear in the list,
+                            that means the items are already installed.
+                            <note>
+                                For Kepler, select
+                                <filename>LTTng - Linux Tracing Toolkit</filename>
+                                box.
+                            </note>
+                            </para></listitem>
+                        <listitem><para>Expand the box next to "Mobile and
+                            Device Development" and select the following boxes.
+                            Again, if any of the following items are not
+                            available for selection, that means the items are
+                            already installed:
+                            <itemizedlist>
+                                <listitem><para><filename>C/C++ Remote Launch (Requires RSE Remote System Explorer)</filename></para></listitem>
+                                <listitem><para><filename>Remote System Explorer End-user Runtime</filename></para></listitem>
+                                <listitem><para><filename>Remote System Explorer User Actions</filename></para></listitem>
+                                <listitem><para><filename>Target Management Terminal (Core SDK)</filename></para></listitem>
+                                <listitem><para><filename>TCF Remote System Explorer add-in</filename></para></listitem>
+                                <listitem><para><filename>TCF Target Explorer</filename></para></listitem>
+                            </itemizedlist></para></listitem>
+                        <listitem><para>Expand the box next to "Programming
+                            Languages" and select the
+                            <filename>C/C++ Autotools Support</filename>
+                            and <filename>C/C++ Development Tools</filename>
+                            boxes.
+                            For Luna, these items do not appear on the list
+                            as they are already installed.
+                            </para></listitem>
+                        <listitem><para>Complete the installation and restart
+                            the Eclipse IDE.</para></listitem>
+                    </orderedlist>
+                </para>
+            </section>
+
+            <section id='installing-the-eclipse-yocto-plug-in'>
+                <title>Installing or Accessing the Eclipse Yocto Plug-in</title>
+
+                <para>
+                    You can install the Eclipse Yocto Plug-in into the Eclipse
+                    IDE one of two ways:  use the Yocto Project's Eclipse
+                    Update site to install the pre-built plug-in or build and
+                    install the plug-in from the latest source code.
+                </para>
+
+                <section id='new-software'>
+                    <title>Installing the Pre-built Plug-in from the Yocto Project Eclipse Update Site</title>
+
+                    <para>
+                        To install the Eclipse Yocto Plug-in from the update
+                        site, follow these steps:
+                        <orderedlist>
+                            <listitem><para>Start up the Eclipse IDE.
+                                </para></listitem>
+                            <listitem><para>In Eclipse, select "Install New
+                                Software" from the "Help" menu.
+                                </para></listitem>
+                            <listitem><para>Click "Add..." in the "Work with:"
+                                area.</para></listitem>
+                           <listitem><para>Enter
+                                <filename>&ECLIPSE_DL_PLUGIN_URL;/luna</filename>
+                                in the URL field and provide a meaningful name
+                                in the "Name" field.
+                                <note>
+                                    If you are using Kepler, use
+                                    <filename>&ECLIPSE_DL_PLUGIN_URL;/kepler</filename>
+                                    in the URL field.
+                                </note></para></listitem>
+                            <listitem><para>Click "OK" to have the entry added
+                                to the "Work with:" drop-down list.
+                                </para></listitem>
+                            <listitem><para>Select the entry for the plug-in
+                                from the "Work with:" drop-down list.
+                                </para></listitem>
+                            <listitem><para>Check the boxes next to
+                                <filename>Yocto Project ADT Plug-in</filename>,
+                                <filename>Yocto Project Bitbake Commander Plug-in</filename>,
+                                and
+                                <filename>Yocto Project Documentation plug-in</filename>.
+                                </para></listitem>
+                            <listitem><para>Complete the remaining software
+                                installation steps and then restart the Eclipse
+                                IDE to finish the installation of the plug-in.
+                                <note>
+                                    You can click "OK" when prompted about
+                                    installing software that contains unsigned
+                                    content.
+                                </note>
+                                </para></listitem>
+                        </orderedlist>
+                    </para>
+                </section>
+
+               <section id='zip-file-method'>
+                   <title>Installing the Plug-in Using the Latest Source Code</title>
+
+                   <para>
+                        To install the Eclipse Yocto Plug-in from the latest
+                        source code, follow these steps:
+                        <orderedlist>
+                            <listitem><para>Be sure your development system
+                                is not using OpenJDK to build the plug-in
+                                by doing the following:
+                                <orderedlist>
+                                    <listitem><para>Use the Oracle JDK.
+                                        If you don't have that, go to
+                                        <ulink url='http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html'></ulink>
+                                        and download the latest appropriate
+                                        Java SE Development Kit tarball for
+                                        your development system and
+                                        extract it into your home directory.
+                                        </para></listitem>
+                                    <listitem><para>In the shell you are going
+                                        to do your work, export the location of
+                                        the Oracle Java.
+                                        The previous step creates a new folder
+                                        for the extracted software.
+                                        You need to use the following
+                                        <filename>export</filename> command
+                                        and provide the specific location:
+                                        <literallayout class='monospaced'>
+     export PATH=~/<replaceable>extracted_jdk_location</replaceable>/bin:$PATH
+                                        </literallayout>
+                                        </para></listitem>
+                                </orderedlist>
+                                </para></listitem>
+                            <listitem><para>In the same shell, create a Git
+                                repository with:
+                                <literallayout class='monospaced'>
+     $ cd ~
+     $ git clone git://git.yoctoproject.org/eclipse-poky
+                                </literallayout>
+                                </para></listitem>
+                            <listitem><para>Be sure to checkout the correct
+                                tag.
+                                For example, if you are using Luna, do the
+                                following:
+                                <literallayout class='monospaced'>
+     $ git checkout luna/yocto-&DISTRO;
+                                </literallayout>
+                                This puts you in a detached HEAD state, which
+                                is fine since you are only going to be building
+                                and not developing.
+                                <note>
+                                    If you are building kepler, checkout the
+                                    <filename>kepler/yocto-&DISTRO;</filename>
+                                    branch.
+                                </note>
+                                </para></listitem>
+                            <listitem><para>Change to the
+                                <filename>scripts</filename>
+                                directory within the Git repository:
+                                <literallayout class='monospaced'>
+     $ cd scripts
+                                </literallayout>
+                                </para></listitem>
+                            <listitem><para>Set up the local build environment
+                                by running the setup script:
+                                <literallayout class='monospaced'>
+     $ ./setup.sh
+                                </literallayout>
+                                </para></listitem>
+                            <listitem><para>When the script finishes execution,
+                                it prompts you with instructions on how to run
+                                the <filename>build.sh</filename> script, which
+                                is also in the <filename>scripts</filename>
+                                directory of the Git repository created
+                                earlier.
+                                </para></listitem>
+                            <listitem><para>Run the <filename>build.sh</filename>
+                                script as directed.
+                                Be sure to provide the tag name, documentation
+                                branch, and a release name.
+                                Here is an example that uses the
+                                <filename>luna/yocto-&DISTRO;</filename> tag, the
+                                <filename>master</filename> documentation
+                                branch, and
+                                <filename>&DISTRO_NAME_NO_CAP;</filename> for the
+                                release name:
+                                <literallayout class='monospaced'>
+     $ ECLIPSE_HOME=/home/scottrif/eclipse-poky/scripts/eclipse ./build.sh luna/yocto-&DISTRO; master &DISTRO_NAME_NO_CAP; 2>&amp;1 | tee -a build.log
+                                </literallayout>
+                                After running the script, the file
+                                <filename>org.yocto.sdk-</filename><replaceable>release</replaceable><filename>-</filename><replaceable>date</replaceable><filename>-archive.zip</filename>
+                                is in the current directory.
+                                </para></listitem>
+                            <listitem><para>If necessary, start the Eclipse IDE
+                                and be sure you are in the Workbench.
+                                </para></listitem>
+                            <listitem><para>Select "Install New Software" from
+                                the "Help" pull-down menu.
+                                </para></listitem>
+                            <listitem><para>Click "Add".</para></listitem>
+                            <listitem><para>Provide anything you want in the
+                                "Name" field.
+                                </para></listitem>
+                            <listitem><para>Click "Archive" and browse to the
+                                ZIP file you built in step eight.
+                                This ZIP file should not be "unzipped", and must
+                                be the <filename>*archive.zip</filename> file
+                                created by running the
+                                <filename>build.sh</filename> script.
+                                </para></listitem>
+                            <listitem><para>Click the "OK" button.
+                                </para></listitem>
+                            <listitem><para>Check the boxes that appear in
+                                the installation window to install the
+                                <filename>Yocto Project ADT Plug-in</filename>,
+                                <filename>Yocto Project Bitbake Commander Plug-in</filename>,
+                                and the
+                                <filename>Yocto Project Documentation plug-in</filename>.
+                                </para></listitem>
+                            <listitem><para>Finish the installation by clicking
+                                through the appropriate buttons.
+                                You can click "OK" when prompted about
+                                installing software that contains unsigned
+                                content.
+                                </para></listitem>
+                            <listitem><para>Restart the Eclipse IDE if
+                                necessary.
+                                </para></listitem>
+                        </orderedlist>
+                    </para>
+
+                    <para>
+                        At this point you should be able to configure the
+                        Eclipse Yocto Plug-in as described in the
+                        "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>"
+                        section.</para>
+                </section>
+            </section>
+
+            <section id='configuring-the-eclipse-yocto-plug-in'>
+                <title>Configuring the Eclipse Yocto Plug-in</title>
+
+                <para>
+                    Configuring the Eclipse Yocto Plug-in involves setting the
+                    Cross Compiler options and the Target options.
+                    The configurations you choose become the default settings
+                    for all projects.
+                    You do have opportunities to change them later when
+                    you configure the project (see the following section).
+                </para>
+
+                <para>
+                    To start, you need to do the following from within the
+                    Eclipse IDE:
+                    <itemizedlist>
+                        <listitem><para>Choose "Preferences" from the
+                            "Window" menu to display the Preferences Dialog.
+                            </para></listitem>
+                        <listitem><para>Click "Yocto Project ADT" to display
+                            the configuration screen.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <section id='configuring-the-cross-compiler-options'>
+                    <title>Configuring the Cross-Compiler Options</title>
+
+                    <para>
+                        To configure the Cross Compiler Options, you must select
+                        the type of toolchain, point to the toolchain, specify
+                        the sysroot location, and select the target
+                        architecture.
+                        <itemizedlist>
+                            <listitem><para><emphasis>Selecting the Toolchain Type:</emphasis>
+                                Choose between
+                                <filename>Standalone pre-built toolchain</filename>
+                                and
+                                <filename>Build system derived toolchain</filename>
+                                for Cross Compiler Options.
+                                    <itemizedlist>
+                                        <listitem><para><emphasis>
+                                            <filename>Standalone Pre-built Toolchain:</filename></emphasis>
+                                            Select this mode when you are using
+                                            a stand-alone cross-toolchain.
+                                            For example, suppose you are an
+                                            application developer and do not
+                                            need to build a target image.
+                                            Instead, you just want to use an
+                                            architecture-specific toolchain on
+                                            an existing kernel and target root
+                                            filesystem.</para></listitem>
+                                       <listitem><para><emphasis>
+                                            <filename>Build System Derived Toolchain:</filename></emphasis>
+                                            Select this mode if the
+                                            cross-toolchain has been installed
+                                            and built as part of the
+                                            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                                            When you select
+                                            <filename>Build system derived toolchain</filename>,
+                                            you are using the toolchain bundled
+                                            inside the Build Directory.
+                                            </para></listitem>
+                                    </itemizedlist>
+                                </para></listitem>
+                            <listitem><para><emphasis>Point to the Toolchain:</emphasis>
+                                If you are using a stand-alone pre-built
+                                toolchain, you should be pointing to where it is
+                                installed.
+                                See the
+                                "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>"
+                                section for information about how the SDK is
+                                installed.</para>
+                                <para>If you are using a system-derived
+                                toolchain, the path you provide for the
+                                <filename>Toolchain Root Location</filename>
+                                field is the
+                                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                                See the
+                                "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>"
+                                section.</para></listitem>
+                            <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
+                                This location is where the root filesystem for
+                                the target hardware resides.
+                                </para>
+                                <para>The location of
+                                the sysroot filesystem depends on where you
+                                separately extracted and installed the
+                                filesystem.</para>
+                                <para>For information on how to install the
+                                toolchain and on how to extract and install the
+                                sysroot filesystem, see the
+                                "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>"
+                                section.
+                                </para></listitem>
+                            <listitem><para><emphasis>Select the Target Architecture:</emphasis>
+                                The target architecture is the type of hardware
+                                you are going to use or emulate.
+                                Use the pull-down
+                                <filename>Target Architecture</filename> menu
+                                to make your selection.
+                                The pull-down menu should have the supported
+                                architectures.
+                                If the architecture you need is not listed in
+                                the menu, you will need to build the image.
+                                See the
+                                "<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
+                                section of the Yocto Project Quick Start for
+                                more information.</para></listitem>
+                        </itemizedlist>
+                    </para>
+                </section>
+
+                <section id='configuring-the-target-options'>
+                    <title>Configuring the Target Options</title>
+
+                    <para>
+                        You can choose to emulate hardware using the QEMU
+                        emulator, or you can choose to run your image on actual
+                        hardware.
+                        <itemizedlist>
+                            <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 specify any custom
+                                options.</para>
+                                <para>If you selected
+                                <filename>Build system derived toolchain</filename>,
+                                the target kernel you built will be located in
+                                the Build Directory in
+                                <filename>tmp/deploy/images/<replaceable>machine</replaceable></filename>
+                                directory.
+                                If you selected
+                                <filename>Standalone pre-built toolchain</filename>,
+                                the pre-built image 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 as part of the Cross-Compiler Options
+                                configuration in the
+                                <filename>Sysroot Location:</filename> field.
+                                </para></listitem>
+                            <listitem><para><emphasis>External HW:</emphasis>
+                                Select this option if you will be using actual
+                                hardware.</para></listitem>
+                        </itemizedlist>
+                    </para>
+
+                    <para>
+                        Click the "OK" 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 Makefile-based projects in a
+                terminal window, see the
+                "<link linkend='makefile-based-projects'>Makefile-Based Projects</link>"
+                section.
+                <note>
+                    Do not use special characters in project names
+                    (e.g. spaces, underscores, etc.).  Doing so can
+                    cause configuration to fail.
+                </note>
+            </para>
+
+            <para>
+                To create a project based on a Yocto template and then display
+                the source code, follow these steps:
+                <orderedlist>
+                    <listitem><para>Select "Project" from the "File -> New" menu.
+                        </para></listitem>
+                    <listitem><para>Double click <filename>CC++</filename>.
+                        </para></listitem>
+                    <listitem><para>Double click <filename>C Project</filename>
+                        to create the project.</para></listitem>
+                    <listitem><para>Expand <filename>Yocto Project ADT Autotools Project</filename>.
+                        </para></listitem>
+                    <listitem><para>Select <filename>Hello World ANSI C Autotools Project</filename>.
+                        This is an Autotools-based project based on a Yocto
+                        template.</para></listitem>
+                    <listitem><para>Put a name in the <filename>Project name:</filename>
+                        field.
+                        Do not use hyphens as part of the name.
+                        </para></listitem>
+                    <listitem><para>Click "Next".</para></listitem>
+                    <listitem><para>Add information in the
+                        <filename>Author</filename> and
+                        <filename>Copyright notice</filename> fields.
+                        </para></listitem>
+                    <listitem><para>Be sure the <filename>License</filename>
+                        field is correct.</para></listitem>
+                    <listitem><para>Click "Finish".</para></listitem>
+                    <listitem><para>If the "open perspective" prompt appears,
+                        click "Yes" so that you in the C/C++ perspective.
+                        </para></listitem>
+                    <listitem><para>The left-hand navigation pane shows your
+                        project.
+                        You can display your source by double clicking the
+                        project's source file.</para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='configuring-the-cross-toolchains'>
+            <title>Configuring the Cross-Toolchains</title>
+
+            <para>
+                The earlier section,
+                "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>",
+                sets up the default project configurations.
+                You can override these settings for a given project by following
+                these steps:
+                <orderedlist>
+                    <listitem><para>Select "Change Yocto Project Settings" from
+                        the "Project" menu.
+                        This selection brings up the Yocto Project Settings
+                        Dialog and allows you to make changes specific to an
+                        individual project.</para>
+                        <para>By default, the Cross Compiler Options and Target
+                        Options for a project are inherited from settings you
+                        provided using the Preferences Dialog as described
+                        earlier in the
+                        "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>" section.
+                        The Yocto Project Settings Dialog allows you to override
+                        those default settings for a given project.
+                        </para></listitem>
+                    <listitem><para>Make your configurations for the project
+                        and click "OK".
+                        </para></listitem>
+                    <listitem><para>Right-click in the navigation pane and
+                        select "Reconfigure Project" from the pop-up menu.
+                        This selection reconfigures the project by running
+                        <filename>autogen.sh</filename> in the workspace for
+                        your project.
+                        The script also runs <filename>libtoolize</filename>,
+                        <filename>aclocal</filename>,
+                        <filename>autoconf</filename>,
+                        <filename>autoheader</filename>,
+                        <filename>automake --a</filename>, and
+                        <filename>./configure</filename>.
+                        Click on the "Console" tab beneath your source code to
+                        see the results of reconfiguring your project.
+                        </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='building-the-project'>
+            <title>Building the Project</title>
+
+            <para>
+                To build the project select "Build Project" from the
+                "Project" menu.
+                The console should update and you can note the cross-compiler
+                you are using.
+                <note>
+                    When building "Yocto Project ADT Autotools" projects, the Eclipse
+                    IDE might display error messages for Functions/Symbols/Types
+                    that cannot be "resolved", even when the related include file
+                    is listed at the project navigator and when the project is
+                    able to build.
+                    For these cases only, it is recommended to add a new linked
+                    folder to the appropriate sysroot.
+                    Use these steps to add the linked folder:
+                    <orderedlist>
+                        <listitem><para>
+                            Select the project.
+                            </para></listitem>
+                        <listitem><para>
+                            Select "Folder" from the
+                            <filename>File > New</filename> menu.
+                            </para></listitem>
+                        <listitem><para>
+                            In the "New Folder" Dialog, select "Link to alternate
+                            location (linked folder)".
+                            </para></listitem>
+                        <listitem><para>
+                            Click "Browse" to navigate to the include folder inside
+                            the same sysroot location selected in the Yocto Project
+                            configuration preferences.
+                            </para></listitem>
+                        <listitem><para>
+                            Click "OK".
+                            </para></listitem>
+                        <listitem><para>
+                            Click "Finish" to save the linked folder.
+                            </para></listitem>
+                    </orderedlist>
+                </note>
+            </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:
+                <note>
+                    See the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>"
+                    chapter in the Yocto Project Development Manual
+                    for more information on using QEMU.
+                </note>
+                <orderedlist>
+                    <listitem><para>Expose and select "External Tools" from
+                        the "Run" menu.
+                        Your image should appear as a selectable menu item.
+                        </para></listitem>
+                    <listitem><para>Select your image from the menu to launch
+                        the emulator in a new window.
+                        </para></listitem>
+                    <listitem><para>If needed, enter your host root password in
+                        the shell window at the prompt.
+                        This sets up a <filename>Tap 0</filename> 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 can begin operating
+                        within that environment.
+                        One useful task at this point would be to determine the
+                        IP Address for the user-space NFS by using the
+                       <filename>ifconfig</filename> command.
+                       </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='deploying-and-debugging-the-application'>
+            <title>Deploying and Debugging the Application</title>
+
+            <para>
+                Once the QEMU emulator is running the image, you can deploy
+                your application using the Eclipse IDE and then use
+                the emulator to perform debugging.
+                Follow these steps to deploy the application.
+                <note>
+                    Currently, Eclipse does not support SSH port forwarding.
+                    Consequently, if you need to run or debug a remote
+                    application using the host display, you must create a
+                    tunneling connection from outside Eclipse and keep
+                    that connection alive during your work.
+                    For example, in a new terminal, run the following:
+                    <literallayout class='monospaced'>
+     ssh -XY user_name@remote_host_ip
+                    </literallayout>
+                    After running the command, add the command to be executed
+                    in Eclipse's run configuration before the application
+                    as follows:
+                    <literallayout class='monospaced'>
+     export DISPLAY=:10.0
+                    </literallayout>
+                </note>
+                <orderedlist>
+                    <listitem><para>Select "Debug Configurations..." from the
+                        "Run" menu.</para></listitem>
+                    <listitem><para>In the left area, expand
+                        <filename>C/C++Remote Application</filename>.
+                        </para></listitem>
+                    <listitem><para>Locate your project and select it to bring
+                        up a new tabbed view in the Debug Configurations Dialog.
+                        </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:" field.
+                        For example, enter
+                        <filename>/usr/bin/<replaceable>programname</replaceable></filename>.
+                        </para></listitem>
+                    <listitem><para>Click on the "Debugger" tab to see the
+                        cross-tool debugger you are using.</para></listitem>
+                    <listitem><para>Click on the "Main" tab.</para></listitem>
+                    <listitem><para>Create a new connection to the QEMU instance
+                        by clicking on "new".</para></listitem>
+                    <listitem><para>Select <filename>TCF</filename>, 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 Dialog.</para></listitem>
+                    <listitem><para>Use the drop-down menu now in the
+                        "Connection" field and pick the IP Address you entered.
+                         </para></listitem>
+                    <listitem><para>Click "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 Eclipse
+                IDE through the "YoctoProjectTools" 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><filename>Lttng2.0 trace import</filename>:</emphasis>
+                        Selecting this tool transfers the remote target's
+                        <filename>Lttng</filename> tracing data back to the
+                        local host machine and uses the Lttng Eclipse plug-in
+                        to graphically display the output.
+                        For information on how to use Lttng to trace an
+                        application,
+                        see <ulink url='http://lttng.org/documentation'></ulink>
+                        and the
+                        "<ulink url='&YOCTO_DOCS_PROF_URL;#lttng-linux-trace-toolkit-next-generation'>LTTng (Linux Trace Toolkit, next generation)</ulink>"
+                        section, which is in the Yocto Project Profiling and
+                        Tracing Manual.
+                        <note>Do not use
+                            <filename>Lttng-user space (legacy)</filename> tool.
+                            This tool no longer has any upstream support.</note>
+                        </para>
+                        <para>Before you use the
+                        <filename>Lttng2.0 trace import</filename> tool,
+                        you need to setup the Lttng Eclipse plug-in and create a
+                        Tracing project.
+                        Do the following:
+                        <orderedlist>
+                            <listitem><para>Select "Open Perspective" from the
+                                "Window" menu and then select "Other..." to
+                                bring up a menu of other perspectives.
+                                Choose "Tracing".
+                                </para></listitem>
+                            <listitem><para>Click "OK" to change the Eclipse
+                                perspective into the Tracing perspective.
+                                </para></listitem>
+                            <listitem><para>Create a new Tracing project by
+                                selecting "Project" from the "File -> New" menu.
+                                </para></listitem>
+                            <listitem><para>Choose "Tracing Project" from the
+                                "Tracing" menu and click "Next".
+                                </para></listitem>
+                            <listitem><para>Provide a name for your tracing
+                                project and click "Finish".
+                                </para></listitem>
+                            <listitem><para>Generate your tracing data on the
+                                remote target.</para></listitem>
+                            <listitem><para>Select "Lttng2.0 trace import"
+                                from the "Yocto Project Tools" menu to
+                                start the data import process.</para></listitem>
+                            <listitem><para>Specify your remote connection name.
+                                </para></listitem>
+                            <listitem><para>For the Ust directory path, specify
+                                the location of your remote tracing data.
+                                Make sure the location ends with
+                                <filename>ust</filename> (e.g.
+                                <filename>/usr/mysession/ust</filename>).
+                                </para></listitem>
+                            <listitem><para>Click "OK" to complete the import
+                                process.
+                                The data is now in the local tracing project
+                                you created.</para></listitem>
+                            <listitem><para>Right click on the data and then use
+                                the menu to Select "Generic CTF Trace" from the
+                                "Trace Type... -> Common Trace Format" menu to
+                                map the tracing type.</para></listitem>
+                            <listitem><para>Right click the mouse and select
+                                "Open" to bring up the Eclipse Lttng Trace
+                                Viewer so you view the tracing data.
+                                </para></listitem>
+                        </orderedlist></para></listitem>
+                    <listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis>
+                        Selecting this tool runs PowerTOP on the remote target
+                        machine and displays the results in a new view called
+                        PowerTOP.</para>
+                        <para>The "Time to gather data(sec):" field is the time
+                        passed in seconds before data is gathered from the
+                        remote target for analysis.</para>
+                        <para>The "show pids in wakeups list:" field corresponds
+                        to the <filename>-p</filename> argument passed to
+                        <filename>PowerTOP</filename>.</para></listitem>
+                    <listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
+                        LatencyTOP identifies system latency, while
+                        Perf monitors the system's performance counter
+                        registers.
+                        Selecting either of these tools causes an RSE terminal
+                        view to appear from which you can run the tools.
+                        Both tools refresh the entire screen to display results
+                        while they run.
+                        For more information on setting up and using
+                        <filename>perf</filename>, see the
+                        "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
+                        section in the Yocto Project Profiling and Tracing
+                        Manual.
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>SystemTap</filename>:</emphasis>
+                        Systemtap is a tool that lets you create and reuse
+                        scripts to examine the activities of a live Linux
+                        system.
+                        You can easily extract, filter, and summarize data
+                        that helps you diagnose complex performance or
+                        functional problems.
+                        For more information on setting up and using
+                        <filename>SystemTap</filename>, see the
+                        <ulink url='https://sourceware.org/systemtap/documentation.html'>SystemTap Documentation</ulink>.
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>yocto-bsp</filename>:</emphasis>
+                        The <filename>yocto-bsp</filename> tool lets you
+                        quickly set up a Board Support Package (BSP) layer.
+                        The tool requires a Metadata location, build location,
+                        BSP name, BSP output location, and a kernel
+                        architecture.
+                        For more information on the
+                        <filename>yocto-bsp</filename> tool outside of Eclipse,
+                        see the
+                        "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a new BSP Layer Using the yocto-bsp Script</ulink>"
+                        section in the Yocto Project Board Support Package
+                        (BSP) Developer's Guide.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+    </section>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->

yocto-poky/documentation/toaster-manual/figures/compatible-layers.png

diff --git a/yocto-poky/documentation/toaster-manual/figures/compatible-layers.png b/yocto-poky/documentation/toaster-manual/figures/compatible-layers.png
new file mode 100644
index 0000000..38436b0
--- /dev/null
+++ b/yocto-poky/documentation/toaster-manual/figures/compatible-layers.png
Binary files differ

yocto-poky/documentation/toaster-manual/figures/import-layer.png

diff --git a/yocto-poky/documentation/toaster-manual/figures/import-layer.png b/yocto-poky/documentation/toaster-manual/figures/import-layer.png
new file mode 100644
index 0000000..436ec7a
--- /dev/null
+++ b/yocto-poky/documentation/toaster-manual/figures/import-layer.png
Binary files differ

yocto-poky/documentation/toaster-manual/figures/new-project.png

diff --git a/yocto-poky/documentation/toaster-manual/figures/new-project.png b/yocto-poky/documentation/toaster-manual/figures/new-project.png
new file mode 100644
index 0000000..dbc50b9
--- /dev/null
+++ b/yocto-poky/documentation/toaster-manual/figures/new-project.png
Binary files differ

yocto-poky/documentation/toaster-manual/toaster-manual-intro.xml

diff --git a/yocto-poky/documentation/toaster-manual/toaster-manual-intro.xml b/yocto-poky/documentation/toaster-manual/toaster-manual-intro.xml
index 9f4c38b..ee1dcba 100644
--- a/yocto-poky/documentation/toaster-manual/toaster-manual-intro.xml
+++ b/yocto-poky/documentation/toaster-manual/toaster-manual-intro.xml
@@ -14,89 +14,25 @@
         remote build servers.
     </para>
 
-    <note>
-        <para>
-            This release of Toaster does allow you to configure and initiate
-            builds.
-            However, you cannot use Toaster to customize image recipes, which
-            still must either be done by hand or through
-            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>.
-            As Toaster matures, it eventually will equal and surpass Hob
-            functionality, at which time Hob will be deprecated.
-        </para>
+    <section id='intro-features'>
+        <title>Toaster Features</title>
 
         <para>
-            For more information on Hob,
-            see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#image-development-using-hob'>Image Development Using Hob</ulink>"
-           section in the Yocto Project Development Manual.
-        </para>
-    </note>
-
-    <section id='intro-modes'>
-        <title>Toaster Operational Modes</title>
-
-        <para>
-            You can use Toaster in Analysis Mode or Build Mode:
+            Toaster allows you to configure and run builds, and it
+            provides extensive information about the build process.
             <itemizedlist>
-                <listitem><para id='toaster-analysis-mode'><emphasis>Analysis Mode:</emphasis>
-                    In Analysis Mode, you can record builds and statistics.
-                    In this Mode, you directly access the
-                    <filename>bitbake</filename> command, which you then use to
-                    build images.</para>
-                    <para>Analysis Mode requires you to have first started
-                    Toaster and then to initiate your build using the
-                    <filename>bitbake</filename> command from the shell.
-                    Toaster must be started before the build or it will not
-                    collect build data.</para>
-                    <para>Toaster has the following capabilities in
-                    Analysis Mode:
-                    <itemizedlist>
-                        <listitem><para>
-                            See what was built (recipes and packages) and what
-                            packages were installed into your final image.
-                            </para></listitem>
-                        <listitem><para>
-                            Browse the directory structure of your image.
-                            </para></listitem>
-                        <listitem><para>
-                            See the value of all variables in your build
-                            configuration, and which files set each value.
-                            </para></listitem>
-                        <listitem><para>
-                            Examine error, warning and trace messages to aid
-                            in debugging.
-                            </para></listitem>
-                        <listitem><para>
-                            See information about the BitBake tasks executed
-                            and reused during your build, including those that
-                            used shared state.
-                            </para></listitem>
-                        <listitem><para>
-                            See dependency relationships between recipes,
-                            packages and tasks
-                            </para></listitem>
-                        <listitem><para>
-                            See performance information such as build time,
-                            task time, CPU usage, and disk I/O.
-                            </para></listitem>
-                    </itemizedlist>
-                    </para></listitem>
-                <listitem><para id='toaster-build-mode'><emphasis>Build Mode:</emphasis>
-                    In Build Mode, Toaster handles the build configuration,
-                    scheduling and execution.
-                    In this mode, all your interaction with the build system
-                    happens through the web interface.
-                    You do not have direct access to the
-                    <filename>bitbake</filename> command.</para>
-                    <para>Using this mode, you configure and start your builds
-                    within Toaster's GUI.
-                    Each project can be configured for a specific version
-                    of the build system.
-                    As shipped, Toaster supports Yocto Project Releases 1.7 and
-                    beyond.</para>
-                    <para>Toaster has all the same capabilities in Build Mode
-                    as it does in Analysis Mode plus the following:
+                <listitem><para id='toaster-build-features'>
+                    <emphasis>Configure and Run Builds:</emphasis>
+                    You can use the Toaster web interface to configure and
+                    start your builds.
+                    Builds started using the Toaster web interface are
+                    organized into projects.
+                    When you create a project, you are asked to select a
+                    release, or version of the build system you want to
+                    use for the project builds.
+                    As shipped, Toaster supports Yocto Project releases 1.8
+                    and beyond.
+                    With the Toaster web interface, you can:
                     <itemizedlist>
                         <listitem><para>
                             Browse layers listed in the various
@@ -106,6 +42,10 @@
                             <ulink url='http://layers.openembedded.org/layerindex/'></ulink>).
                             </para></listitem>
                         <listitem><para>
+                            Browse images, recipes, and machines provided by
+                            those layers.
+                            </para></listitem>
+                        <listitem><para>
                             Import your own layers for building.
                             </para></listitem>
                         <listitem><para>
@@ -121,6 +61,53 @@
                             Start your builds.
                             </para></listitem>
                     </itemizedlist>
+                    Toaster also allows you to configure and run your builds
+                    from the command line, and switch between the command line and
+                    the web interface at any time.
+                    Builds started from  the command line appear within a special
+                    Toaster project called "Command line builds".
+                    </para></listitem>
+                <listitem><para id='toaster-analysis-features'>
+                    <emphasis>Information About the Build Process:</emphasis>
+                    Toaster also records extensive information about your builds.
+                    Toaster collects data for builds you start from the web
+                    interface and from the command line as long as Toaster
+                    is running.
+                    <note>
+                        You must start Toaster before the build or it will not
+                        collect build data.
+                    </note></para>
+                    <para>With Toaster you can:
+                    <itemizedlist>
+                        <listitem><para>
+                            See what was built (recipes and packages) and what
+                            packages were installed into your final image.
+                            </para></listitem>
+                        <listitem><para>
+                            Browse the directory structure of your image.
+                            </para></listitem>
+                        <listitem><para>
+                            See the value of all variables in your build
+                            configuration, and which files set each value.
+                            </para></listitem>
+                        <listitem><para>
+                            Examine error, warning, and trace messages to aid
+                            in debugging.
+                            </para></listitem>
+                        <listitem><para>
+                            See information about the BitBake tasks executed
+                            and reused during your build, including those that
+                            used shared state.
+                            </para></listitem>
+                        <listitem><para>
+                            See dependency relationships between recipes,
+                            packages, and tasks.
+                            </para></listitem>
+                        <listitem><para>
+                            See performance information such as build time,
+                            task time, CPU usage, and disk I/O.
+                            </para></listitem>
+                    </itemizedlist>
                     </para></listitem>
             </itemizedlist>
         </para>
@@ -132,8 +119,6 @@
         <para>
             You can set Toaster up to run as a local instance or as a shared
             hosted service.
-            Regardless of how you set up Toaster, both Analysis and Build
-            Modes are available.
         </para>
 
         <para>

yocto-poky/documentation/toaster-manual/toaster-manual-reference.xml

diff --git a/yocto-poky/documentation/toaster-manual/toaster-manual-reference.xml b/yocto-poky/documentation/toaster-manual/toaster-manual-reference.xml
index faca4ca..3a46b61 100644
--- a/yocto-poky/documentation/toaster-manual/toaster-manual-reference.xml
+++ b/yocto-poky/documentation/toaster-manual/toaster-manual-reference.xml
@@ -159,25 +159,24 @@
                     </para>
 
                     <para>
-                        When you set up Toaster in Build Mode, you are prompted
-                        to select a Toaster configuration file.
+                        The Toaster startup script in
+                        <filename>/bitbake/bin/toaster</filename> specifies
+                        the location of a Toaster configuration file
+                        <filename>toasterconf.json</filename> as the value of
+                        the <filename>TOASTER_CONF</filename> variable.
                         This configuration file is used to set up the initial
                         configuration values within the Toaster database
                         including the layer sources.
-                        Three versions of the configuration file exist:
+                        Two versions of the configuration file exist:
                         <itemizedlist>
                             <listitem><para>
                                 The first version of the file is found in the
                                 <filename>conf</filename> directory of the
-                                <filename>meta-yocto</filename> layer
+                                <filename>meta-poky</filename> layer
                                 (i.e.
-                                <filename>meta-yocto/conf/toasterconf.json</filename>).
+                                <filename>meta-poky/conf/toasterconf.json</filename>).
                                 This version contains the default Yocto Project
                                 configuration for Toaster.
-                                You are prompted to select this file during the
-                                Toaster set up process if you had cloned the
-                                <filename>poky</filename> repository (i.e.
-                                <filename>git://git.yoctoproject.org/poky</filename>).
                                 </para></listitem>
                             <listitem><para>
                                 The second version of the file is in the
@@ -186,19 +185,6 @@
                                 (i.e. <filename>meta/conf/toasterconf.json</filename>).
                                 This version contains the default OpenEmbedded
                                 configuration for Toaster.
-                                You are prompted to select this file during the
-                                Toaster set up process if you had cloned the
-                                <filename>openembedded-core</filename> repository
-                                (i.e.
-                                <filename>git://git.openembedded.org/openembedded-core</filename>).
-                                </para></listitem>
-                            <listitem><para>
-                                The third version is a sample configuration
-                                useful for when you want to set up a hosted
-                                service in Build Mode.
-                                You can find this version on the
-                                <ulink url='https://wiki.yoctoproject.org/wiki/File:Toasterconf.json.txt.patch'>File:Toasterconf.json.txt.patch</ulink>
-                                wiki page.
                                 </para></listitem>
                         </itemizedlist>
                     </para>
@@ -228,10 +214,10 @@
                     "dirpath": "meta"
                 },
                 {
-                    "name": "meta-yocto",
-                    "local_path": "meta-yocto",
+                    "name": "meta-poky",
+                    "local_path": "meta-poky",
                     "vcs_url": "remote:origin",
-                    "dirpath": "meta-yocto"
+                    "dirpath": "meta-poky"
                 },
                 {
                     "name": "meta-yocto-bsp",
@@ -307,10 +293,10 @@
                         <filename>toasterconf.json</filename> file you just edited.
                         For example, if you cloned the
                         <filename>poky</filename> repository and you edited the
-                        <filename>meta-yocto/conf/toasterconf.json</filename> file,
+                        <filename>meta-poky/conf/toasterconf.json</filename> file,
                         you would type something like the following:
                         <literallayout class='monospaced'>
-     $ bitbake/lib/toaster/manage.py loadconf /home/scottrif/poky/meta-yocto/conf/toasterconf.json
+     $ bitbake/lib/toaster/manage.py loadconf /home/scottrif/poky/meta-poky/conf/toasterconf.json
                         </literallayout>
                         After entering this command, you need to update the
                         Toaster database with the information coming from your
@@ -550,8 +536,7 @@
         <title>JSON Files</title>
 
         <para>
-            If you are going to be using Toaster in Build Mode, it must
-            be initially configured before use.
+            You must configure Toaster before using it.
             Configuration customizes layer source settings and Toaster defaults
             for all users and is performed by the person responsible for
             Toaster Configuration (i.e  the Toaster Administrator).
@@ -577,23 +562,22 @@
             <filename>toasterconf.json</filename>.
             The Toaster Administrator can customize the file prior to loading
             it into Toaster.
-            When you set up Toaster locally to run in Build Mode, the system
-            startup script actively looks for compatible configuration files
-            and prompts you to select a file to load if it detects that the
-            database has not been configured.
+            The <filename>TOASTER_CONF</filename> variable in the
+            Toaster startup script at <filename>bitbake/bin/toaster</filename>
+            specifies the location of the <filename>toasterconf.json</filename> file.
         </para>
 
         <section id='json-file-choices'>
             <title>Configuration File Choices</title>
 
             <para>
-                Three versions of the configuration file exist:
+                Two versions of the configuration file exist:
                 <itemizedlist>
                     <listitem><para>
                         The
-                        <filename>meta-yocto/conf/toasterconf.json</filename>
+                        <filename>meta-poky/conf/toasterconf.json</filename>
                         in the <filename>conf</filename> directory of the
-                        Yocto Project's <filename>meta-yocto</filename> layer.
+                        Yocto Project's <filename>meta-poky</filename> layer.
                         This version contains the default Yocto Project
                         configuration for Toaster.
                         You are prompted to select this file during the Toaster
@@ -613,15 +597,6 @@
                         <filename>openembedded-core</filename> repository (i.e.
                         <filename>git://git.openembedded.org/openembedded-core</filename>).
                         </para></listitem>
-                    <listitem><para>
-                        The <filename>Toasterconf.json.txt.patch</filename>
-                        located on the
-                        <ulink url='https://wiki.yoctoproject.org/wiki/File:Toasterconf.json.txt.patch'>File:Toasterconf.json.txt.patch</ulink>
-                        wiki page.
-                        This version of the file is useful as a sample
-                        configuration for when you want to set up Toaster as a
-                        hosted service in Build Mode.
-                        </para></listitem>
                 </itemizedlist>
             </para>
         </section>
@@ -723,10 +698,10 @@
                     "dirpath": "meta"
                 },
                 {
-                    "name": "meta-yocto",
-                    "local_path": "meta-yocto",
+                    "name": "meta-poky",
+                    "local_path": "meta-poky",
                     "vcs_url": "remote:origin",
-                    "dirpath": "meta-yocto"
+                    "dirpath": "meta-poky"
                 },
                 {
                     "name": "meta-yocto-bsp",
@@ -842,7 +817,7 @@
              "description": "Yocto Project master",
              "bitbake": "master",
              "branch": "master",
-             "defaultlayers": [ "openembedded-core", "meta-yocto", "meta-yocto-bsp"],
+             "defaultlayers": [ "openembedded-core", "meta-poky", "meta-yocto-bsp"],
              "layersourcepriority": { "Imported layers": 99, "Local Yocto Project" : 10, "OpenEmbedded" :  0 },
              "helptext": "Toaster will run your builds using the tip of the &lt;a href=\"http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/\"&gt;Yocto Project master branch&lt;/a&gt;, where active development takes place. This is not a stable branch, so your builds might not work as expected."
          },
@@ -851,7 +826,7 @@
              "description": "Yocto Project 2.0 Jethro",
              "bitbake": "jethro",
              "branch": "jethro",
-             "defaultlayers": [ "openembedded-core", "meta-yocto", "meta-yocto-bsp"],
+             "defaultlayers": [ "openembedded-core", "meta-poky", "meta-yocto-bsp"],
              "layersourcepriority": { "Imported layers": 99, "Local Yocto Project" : 10, "OpenEmbedded" :  0 },
              "helptext": "Toaster will run your builds with the tip of the &lt;a href=\"http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=jethro\"&gt;Yocto Project 2.0 \"Jethro\"&lt;/a&gt; branch."
          },
@@ -860,7 +835,7 @@
              "description": "Yocto Project 1.8 Fido",
              "bitbake": "fido",
              "branch": "fido",
-             "defaultlayers": [ "openembedded-core", "meta-yocto", "meta-yocto-bsp"],
+             "defaultlayers": [ "openembedded-core", "meta-poky", "meta-yocto-bsp"],
              "layersourcepriority": { "Imported layers": 99, "Local Yocto Project" : 10, "OpenEmbedded" :  0 },
              "helptext": "Toaster will run your builds with the tip of the &lt;a href=\"http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=fido\"&gt;Yocto Project 1.8 \"Fido\"&lt;/a&gt; branch."
          },
@@ -869,7 +844,7 @@
              "description": "Local Yocto Project",
              "bitbake": "HEAD",
              "branch": "HEAD",
-             "defaultlayers": [ "openembedded-core", "meta-yocto", "meta-yocto-bsp"],
+             "defaultlayers": [ "openembedded-core", "meta-poky", "meta-yocto-bsp"],
              "layersourcepriority": { "Imported layers": 99, "Local Yocto Project" : 10, "OpenEmbedded" :  0 },
              "helptext": "Toaster will run your builds with the version of the Yocto Project you have cloned or downloaded to your computer."
          }
@@ -1008,7 +983,7 @@
                 <literallayout class='monospaced'>
      $ bitbake/lib/toaster/manage.py checksettings
                 </literallayout>
-                In Build Mode, Toaster uses settings that are based on the
+                Toaster uses settings that are based on the
                 database to configure the building tasks.
                 The <filename>checksettings</filename> command verifies that
                 the database settings are valid in the sense that they have

yocto-poky/documentation/toaster-manual/toaster-manual-setup-and-use.xml

diff --git a/yocto-poky/documentation/toaster-manual/toaster-manual-setup-and-use.xml b/yocto-poky/documentation/toaster-manual/toaster-manual-setup-and-use.xml
index 2693569..963b211 100644
--- a/yocto-poky/documentation/toaster-manual/toaster-manual-setup-and-use.xml
+++ b/yocto-poky/documentation/toaster-manual/toaster-manual-setup-and-use.xml
@@ -17,32 +17,12 @@
         </para>
 
         <para>
-            If you want to configure and start your builds using the
-            Toaster web interface
-            (i.e. "<link linkend='toaster-build-mode'>Build Mode</link>"),
-            navigate to the root of your
+            Navigate to the root of your
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
             (e.g. <filename>poky</filename>):
             <literallayout class='monospaced'>
      $ cd poky
             </literallayout>
-            Next, start Toaster:
-            <literallayout class='monospaced'>
-     $ bitbake/bin/toaster
-            </literallayout>
-            Open your favourite browser and enter the following:
-            <literallayout class='monospaced'>
-     http://127.0.0.1:8000
-            </literallayout>
-            If you would rather configure and start your builds
-            using the command line
-            (i.e. <link linkend='toaster-analysis-mode'>Analysis Mode</link>),
-            you can get Toaster to "listen"
-            to your builds and collect information about them.
-            To do that, navigate to the root of your Source Directory:
-            <literallayout class='monospaced'>
-     $ cd poky
-            </literallayout>
             Once in that directory, source the build environment script:
             <literallayout class='monospaced'>
      $ source oe-init-build-env
@@ -53,12 +33,14 @@
             <literallayout class='monospaced'>
      $ source ../bitbake/bin/toaster
             </literallayout>
-            You can now run builds normally.
+            You can now run your builds from the command line, or with
+            Toaster as explained in section
+            "<link linkend='using-the-toaster-web-interface'>Using the Toaster Web Interface</link>".
         </para>
 
         <para>
-            To see the build information provided by Toaster, open your
-            favorite browser and enter the following:
+            To access the Toaster web interface, open your favorite
+            browser and enter the following:
             <literallayout class='monospaced'>
      http://127.0.0.1:8000
             </literallayout>
@@ -72,12 +54,7 @@
             By default, Toaster starts on port 8000.
             You can use the <filename>WEBPORT</filename> parameter to
             set a different port.
-            For example, either of the following commands sets the
-            port to "8400":
-            <literallayout class='monospaced'>
-     $ bitbake/bin/toaster webport=8400
-            </literallayout>
-            or
+            For example, the following command sets the port to "8400":
             <literallayout class='monospaced'>
      $ source ../bitbake/bin/toaster webport=8400
             </literallayout>
@@ -88,18 +65,10 @@
         <title>The Directory for Cloning Layers</title>
 
         <para>
-            If you are running Toaster in
-            <link linkend='toaster-build-mode'>Build Mode</link>,
             Toaster creates a <filename>_toaster_clones</filename>
             directory inside your Source Directory
-            (i.e. <filename>poky</filename>).
-            For example, suppose you use this command to start Toaster:
-            <literallayout class='monospaced'>
-     poky/bitbake/bin/toaster
-            </literallayout>
-            In this example, Toaster creates and uses the
-            <filename>poky/_toaster_clones</filename>
-            directory to clone any layers needed for your builds.
+            (i.e. <filename>poky</filename>) to clone any layers
+            needed for your builds.
         </para>
 
         <para>
@@ -117,17 +86,9 @@
         <title>The Build Directory</title>
 
         <para>
-            If you are running Toaster in
-            <link linkend='toaster-build-mode'>Build Mode</link>,
             Toaster creates a build directory within your Source
-            Directory (e.g. <filename>poky</filename>).
-            For example, suppose you use this command to start Toaster:
-            <literallayout class='monospaced'>
-     poky/bitbake/bin/toaster
-            </literallayout>
-            In this example, Toaster creates and uses the
-            <filename>poky/build</filename>
-            directory to execute the builds.
+            Directory (e.g. <filename>poky</filename>) to execute
+            the builds.
         </para>
 
         <para>
@@ -136,7 +97,7 @@
             the <filename>TOASTER_DIR</filename> environment variable,
             which takes precedence over your current working directory.
             Setting this environment variable causes Toaster to use
-            <filename>$TOASTER_DIR./build</filename> as the build directory.
+            <filename>$TOASTER_DIR/build</filename> as the build directory.
         </para>
     </section>
 
@@ -154,1267 +115,519 @@
             To access the Django administration interface, you must
             create a superuser by following these steps:
             <orderedlist>
-                <listitem><para>
-                    If you used <filename>virtualenv</filename>, which is
-                    recommended, to set up the Toaster system dependencies,
-                    you need be sure the virtual environment is activated.
-                    To activate this environment, use the following:
-                    <literallayout class='monospaced'>
-     $ source venv/bin/activate
-                    </literallayout>
-                    </para></listitem>
-                <listitem><para>
-                    From the root of your checkout directory, invoke the
-                    following command from <filename>manage.py</filename>:
-                    <literallayout class='monospaced'>
-     $ ./bitbake/lib/toaster/manage.py createsuperuser
-                    </literallayout>
-                    </para></listitem>
-                <listitem><para>
-                    Django prompts you for the username, which you need to
-                    provide.
-                    </para></listitem>
-                <listitem><para>
-                    Django prompts you for an email address, which is
-                    optional.
-                    </para></listitem>
-                <listitem><para>
-                    Django prompts you for a password, which you must provide.
-                    </para></listitem>
-                <listitem><para>
-                    Django prompts you to re-enter your password for verification.
-                    </para></listitem>
-            </orderedlist>
-            After completing these steps, the following confirmation message
-            appears:
-            <literallayout class='monospaced'>
-     Superuser created successfully.
-            </literallayout>
-        </para>
+              <listitem><para>
+                  If you used <filename>virtualenv</filename>, which is
+                  recommended, to set up the Toaster system dependencies,
+                  you need be sure the virtual environment is activated.
+                  To activate this environment, use the following command:
+                  <literallayout class='monospaced'>
+   $ source venv/bin/activate
+                  </literallayout>
+                  </para></listitem>
+              <listitem><para>
+                  From the directory containing the Toaster database,
+                  which by default is the
+                  <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                  invoke the <filename>createsuperuser</filename> command
+                  from <filename>manage.py</filename>:
+                  <literallayout class='monospaced'>
+   $ cd ~/poky/build
+   $ ../bitbake/lib/toaster/manage.py createsuperuser
+                  </literallayout>
+                  </para></listitem>
+              <listitem><para>
+                  Django prompts you for the username, which you need to
+                  provide.
+                  </para></listitem>
+              <listitem><para>
+                  Django prompts you for an email address, which is
+                  optional.
+                  </para></listitem>
+              <listitem><para>
+                  Django prompts you for a password, which you must provide.
+                  </para></listitem>
+              <listitem><para>
+                  Django prompts you to re-enter your password for verification.
+                  </para></listitem>
+          </orderedlist>
+          After completing these steps, the following confirmation message
+          appears:
+          <literallayout class='monospaced'>
+   Superuser created successfully.
+          </literallayout>
+      </para>
 
-        <para>
-            Creating a superuser allows you to access the Django administration
-            interface through a browser.
-            The URL for this interface is the same as the URL used for the
-            Toaster instance with "/admin" on the end.
-            For example, if you are running Toaster locally, use the
-            following URL:
-            <literallayout class='monospaced'>
-     http://127.0.0.1:8000/admin
-            </literallayout>
-            You can use the Django administration interface to set Toaster
-            configuration parameters such as the build directory, layer sources,
-            default variable values, and BitBake versions.
-        </para>
-    </section>
+      <para>
+          Creating a superuser allows you to access the Django administration
+          interface through a browser.
+          The URL for this interface is the same as the URL used for the
+          Toaster instance with "/admin" on the end.
+          For example, if you are running Toaster locally, use the
+          following URL:
+          <literallayout class='monospaced'>
+   http://127.0.0.1:8000/admin
+          </literallayout>
+          You can use the Django administration interface to set Toaster
+          configuration parameters such as the build directory, layer sources,
+          default variable values, and BitBake versions.
+      </para>
+  </section>
 
-    <section id='toaster-setting-up-a-production-instance-of-toaster'>
-        <title>Setting Up a Production Instance of Toaster</title>
+  <section id='toaster-setting-up-a-production-instance-of-toaster'>
+      <title>Setting Up a Production Instance of Toaster</title>
 
-        <para>
-            You can use a production instance of Toaster to share the
-            Toaster instance with remote users, multiple users, or both.
-            The production instance is also the setup that can cope with
-            heavier loads on the web service.
-            Use the instructions in the following sections to set up
-            Toaster in
-            <link linkend='toaster-build-mode'>Build Mode</link>
-            where builds and projects are run,
-            viewed, and defined through the Toaster web interface.
-        </para>
+      <para>
+          You can use a production instance of Toaster to share the
+          Toaster instance with remote users, multiple users, or both.
+          The production instance is also the setup that can handle
+          heavier loads on the web service.
+          Use the instructions in the following sections to set up
+          Toaster to run builds through the Toaster web interface.
+      </para>
 
-        <section id='toaster-production-instance-requirements'>
-            <title>Requirements</title>
+      <section id='toaster-production-instance-requirements'>
+          <title>Requirements</title>
 
-            <para>
-                Be sure you meet the following requirements:
-                <note>
-                    You must comply with all Apache,
-                    <filename>mod-wsgi</filename>, and Mysql requirements.
-                </note>
-                <itemizedlist>
-                    <listitem><para>
-                        Have all the build requirements as described in
-                        "<link linkend='toaster-setting-up-the-basic-system-requirements'>Setting Up the Basic System Requirements</link>"
-                        chapter.
-                        </para></listitem>
-                    <listitem><para>
-                        Have an Apache webserver.
-                        </para></listitem>
-                    <listitem><para>
-                        Have <filename>mod-wsgi</filename> for the Apache
-                        webserver.
-                        </para></listitem>
-                    <listitem><para>
-                        Use the Mysql database server.
-                        </para></listitem>
-                    <listitem><para>
-                        If you are using Ubuntu 14.04.3, run the following:
-                        <literallayout class='monospaced'>
-     $ sudo apt-get install apache2 libapache2-mod-wsgi mysql-server virtualenv libmysqlclient-dev
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        If you are using Fedora 22 or a RedHat distribution, run
-                        the following:
-                        <literallayout class='monospaced'>
-     $ sudo dnf install httpd mod_wsgi python-virtualenv gcc mysql-devel
-                        </literallayout>
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-        </section>
+          <para>
+              Be sure you meet the following requirements:
+              <note>
+                  You must comply with all Apache,
+                  <filename>mod-wsgi</filename>, and Mysql requirements.
+              </note>
+              <itemizedlist>
+                  <listitem><para>
+                      Have all the build requirements as described in
+                      "<link linkend='toaster-setting-up-the-basic-system-requirements'>Setting Up the Basic System Requirements</link>"
+                      chapter.
+                      </para></listitem>
+                  <listitem><para>
+                      Have an Apache webserver.
+                      </para></listitem>
+                  <listitem><para>
+                      Have <filename>mod-wsgi</filename> for the Apache
+                      webserver.
+                      </para></listitem>
+                  <listitem><para>
+                      Use the Mysql database server.
+                      </para></listitem>
+                  <listitem><para>
+                      If you are using Ubuntu 14.04.3, run the following:
+                      <literallayout class='monospaced'>
+   $ sudo apt-get install apache2 libapache2-mod-wsgi mysql-server virtualenv libmysqlclient-dev
+                      </literallayout>
+                      </para></listitem>
+                  <listitem><para>
+                      If you are using Fedora 22 or a RedHat distribution, run
+                      the following:
+                      <literallayout class='monospaced'>
+   $ sudo dnf install httpd mod_wsgi python-virtualenv gcc mysql-devel
+                      </literallayout>
+                      </para></listitem>
+              </itemizedlist>
+          </para>
+      </section>
 
-        <section id='toaster-installation-steps'>
-            <title>Installation</title>
+      <section id='toaster-installation-steps'>
+          <title>Installation</title>
 
-            <para>
-                Perform the following steps to install Toaster:
-                <orderedlist>
-                    <listitem><para>
-                        Checkout a copy of <filename>poky</filename>
-                        into the web server directory.
-                        You will be using <filename>/var/www/toaster</filename>:
-                        <literallayout class='monospaced'>
-     $ mkdir -p /var/www/toaster
-     $ cd /var/www/toaster/
-     $ git clone git://git.yoctoproject.org/poky
-     $ git checkout &DISTRO_NAME;
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        Initialize a virtual environment and install Toaster
-                        dependencies.
-                        Using a virtual environment keeps the Python packages
-                        isolated from your system-provided packages:
-                        <literallayout class='monospaced'>
-     $ cd /var/www/toaster/
-     $ virtualenv venv
-     $ source ./venv/bin/activate
-     $ pip install -r ./poky/bitbake/toaster-requirements.txt
-     $ pip install mysql
-     $ pip install MySQL-python
-                        </literallayout>
-                        <note>
-                            Isolating these packages is not required but is
-                            recommended.
-                            Alternatively, you can use your operating system's
-                            package manager to install the packages.
-                        </note>
-                        </para></listitem>
-                    <listitem><para>
-                        Configure Toaster by editing
-                        <filename>/var/www/toaster/poky/bitbake/lib/toaster/toastermain/settings.py</filename>
-                        as follows:
-                        <itemizedlist>
-                            <listitem><para>
-                                Edit the <filename>DATABASE</filename> settings:
-                                <literallayout class='monospaced'>
-     DATABASES = {
-         'default': {
-             'ENGINE': 'django.db.backends.mysql',
-             'NAME': 'toaster_data',
-             'USER': 'toaster',
-             'PASSWORD': 'yourpasswordhere',
-             'HOST': 'localhost',
-             'PORT': '3306',
-        }
-     }
-                                </literallayout>
-                                </para></listitem>
-                            <listitem><para>
-                                Edit the <filename>SECRET_KEY</filename>:
-                                <literallayout class='monospaced'>
-     SECRET_KEY = '<replaceable>your_secret_key</replaceable>'
-                                </literallayout>
-                                </para></listitem>
-                            <listitem><para>
-                                Edit the <filename>STATIC_ROOT</filename>:
-                                <literallayout class='monospaced'>
-     STATIC_ROOT = '/var/www/toaster/static_files/'
-                                </literallayout>
-                                </para></listitem>
-                            <listitem><para>
-                                Enable Build Mode by adding the following
-                                line to <filename>settings.py</filename>:
-                                <literallayout class='monospaced'>
-     BUILD_MODE=True
-                                </literallayout>
-                                </para></listitem>
-                        </itemizedlist>
-                        </para></listitem>
-                    <listitem><para>
-                        Add the database and user to the <filename>mysql</filename>
-                        server defined earlier:
-                        <literallayout class='monospaced'>
-     $ mysql -u root -p
-     mysql> CREATE DATABASE toaster_data;
-     mysql> CREATE USER 'toaster'@'localhost' identified by 'yourpasswordhere';
-     mysql> GRANT all on toaster_data.* to 'toaster'@'localhost';
-     mysql> quit
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        Get Toaster to create the database schema,
-                        default data, and gather the statically-served files:
-                        <literallayout class='monospaced'>
-     $ cd  /var/www/toaster/poky/
-     $ ./bitbake/lib/toaster/manage.py syncdb
-     $ ./bitbake/lib/toaster/manage.py migrate
-     $ TOASTER_DIR=`pwd` TOASTER_CONF=./meta-yocto/conf/toasterconf.json ./bitbake/lib/toaster/manage.py checksettings
-     $ ./bitbake/lib/toaster/manage.py collectstatic
-                        </literallayout>
-                        </para>
+          <para>
+              Perform the following steps to install Toaster:
+              <orderedlist>
+                  <listitem><para>
+                      Checkout a copy of <filename>poky</filename>
+                      into the web server directory.
+                      You will be using <filename>/var/www/toaster</filename>:
+                      <literallayout class='monospaced'>
+   $ mkdir -p /var/www/toaster
+   $ cd /var/www/toaster/
+   $ git clone git://git.yoctoproject.org/poky
+   $ git checkout &DISTRO_NAME_NO_CAP;
+                      </literallayout>
+                      </para></listitem>
+                  <listitem><para>
+                      Initialize a virtual environment and install Toaster
+                      dependencies.
+                      Using a virtual environment keeps the Python packages
+                      isolated from your system-provided packages:
+                      <literallayout class='monospaced'>
+   $ cd /var/www/toaster/
+   $ virtualenv venv
+   $ source ./venv/bin/activate
+   $ pip install -r ./poky/bitbake/toaster-requirements.txt
+   $ pip install mysql
+   $ pip install MySQL-python
+                      </literallayout>
+                      <note>
+                          Isolating these packages is not required but is
+                          recommended.
+                          Alternatively, you can use your operating system's
+                          package manager to install the packages.
+                      </note>
+                      </para></listitem>
+                  <listitem><para>
+                      Configure Toaster by editing
+                      <filename>/var/www/toaster/poky/bitbake/lib/toaster/toastermain/settings.py</filename>
+                      as follows:
+                      <itemizedlist>
+                          <listitem><para>
+                              Edit the <filename>DATABASE</filename> settings:
+                              <literallayout class='monospaced'>
+   DATABASES = {
+       'default': {
+           'ENGINE': 'django.db.backends.mysql',
+           'NAME': 'toaster_data',
+           'USER': 'toaster',
+           'PASSWORD': 'yourpasswordhere',
+           'HOST': 'localhost',
+           'PORT': '3306',
+      }
+   }
+                              </literallayout>
+                              </para></listitem>
+                          <listitem><para>
+                              Edit the <filename>SECRET_KEY</filename>:
+                              <literallayout class='monospaced'>
+   SECRET_KEY = '<replaceable>your_secret_key</replaceable>'
+                              </literallayout>
+                              </para></listitem>
+                          <listitem><para>
+                              Edit the <filename>STATIC_ROOT</filename>:
+                              <literallayout class='monospaced'>
+   STATIC_ROOT = '/var/www/toaster/static_files/'
+                              </literallayout>
+                              </para></listitem>
+                      </itemizedlist>
+                      </para></listitem>
+                  <listitem><para>
+                      Add the database and user to the <filename>mysql</filename>
+                      server defined earlier:
+                      <literallayout class='monospaced'>
+   $ mysql -u root -p
+   mysql> CREATE DATABASE toaster_data;
+   mysql> CREATE USER 'toaster'@'localhost' identified by 'yourpasswordhere';
+   mysql> GRANT all on toaster_data.* to 'toaster'@'localhost';
+   mysql> quit
+                      </literallayout>
+                      </para></listitem>
+                  <listitem><para>
+                      Get Toaster to create the database schema,
+                      default data, and gather the statically-served files:
+                      <literallayout class='monospaced'>
+   $ cd  /var/www/toaster/poky/
+   $ ./bitbake/lib/toaster/manage.py syncdb
+   $ ./bitbake/lib/toaster/manage.py migrate
+   $ TOASTER_DIR=`pwd` TOASTER_CONF=./meta-poky/conf/toasterconf.json ./bitbake/lib/toaster/manage.py checksettings
+   $ ./bitbake/lib/toaster/manage.py collectstatic
+                      </literallayout>
+                      </para>
 
-                        <para>
-                            For the above set of commands, after moving to the
-                            <filename>poky</filename> directory,
-                            the <filename>syncdb</filename> and <filename>migrate</filename>
-                            commands ensure the database
-                            schema has had changes propagated correctly (i.e.
-                            migrations).
-                        </para>
+                      <para>
+                          For the above set of commands, after moving to the
+                          <filename>poky</filename> directory,
+                          the <filename>syncdb</filename> and <filename>migrate</filename>
+                          commands ensure the database
+                          schema has had changes propagated correctly (i.e.
+                          migrations).
+                      </para>
 
-                        <para>
-                            The next line sets the Toaster root directory
-                            <filename>TOASTER_DIR</filename> and the location of
-                            the Toaster configuration file
-                            <filename>TOASTER_CONF</filename>, which is
-                            relative to the Toaster root directory
-                            <filename>TOASTER_DIR</filename>.
-                            For more information on the Toaster configuration file
-                            <filename>TOASTER_CONF</filename>, see the
-                            <link linkend='toaster-json-files'>JSON Files</link>
-                            section of this manual.
-                        </para>
+                      <para>
+                          The next line sets the Toaster root directory
+                          <filename>TOASTER_DIR</filename> and the location of
+                          the Toaster configuration file
+                          <filename>TOASTER_CONF</filename>, which is
+                          relative to the Toaster root directory
+                          <filename>TOASTER_DIR</filename>.
+                          For more information on the Toaster configuration file
+                          <filename>TOASTER_CONF</filename>, see the
+                          <link linkend='toaster-json-files'>JSON Files</link>
+                          section of this manual.
+                      </para>
 
-                        <para>
-                            This line also runs the <filename>checksettings</filename>
-                            command, which configures the location of the Toaster
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build directory</ulink>.
-                            The Toaster root directory <filename>TOASTER_DIR</filename>
-                            determines where the Toaster build directory
-                            is created on the file system.
-                            In the example above,
-                            <filename>TOASTER_DIR</filename> is set as follows:
-                            <literallayout class="monospaced">
-     /var/www/toaster/poky
-                            </literallayout>
-                            This setting causes the Toaster build directory to be:
-                            <literallayout class="monospaced">
-     /var/www/toaster/poky/build
-                            </literallayout>
-                        </para>
+                      <para>
+                          This line also runs the <filename>checksettings</filename>
+                          command, which configures the location of the Toaster
+                          <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build directory</ulink>.
+                          The Toaster root directory <filename>TOASTER_DIR</filename>
+                          determines where the Toaster build directory
+                          is created on the file system.
+                          In the example above,
+                          <filename>TOASTER_DIR</filename> is set as follows:
+                          <literallayout class="monospaced">
+   /var/www/toaster/poky
+                          </literallayout>
+                          This setting causes the Toaster build directory to be:
+                          <literallayout class="monospaced">
+   /var/www/toaster/poky/build
+                          </literallayout>
+                      </para>
 
-                        <para>
-                            Finally, the <filename>collectstatic</filename> command
-                            is a Django framework command that collects all the
-                            statically served files into a designated directory to
-                            be served up by the Apache web server.
-                        </para></listitem>
-                    <listitem><para>
-                        Add an Apache configuration file for Toaster to your Apache web
-                        server's configuration directory.
-                        If you are using Ubuntu or Debian, put the file here:
-                        <literallayout class='monospaced'>
-     /etc/apache2/conf-available/toaster.conf
-                        </literallayout>
-                        If you are using Fedora or RedHat, put it here:
-                        <literallayout class='monospaced'>
-     /etc/httpd/conf.d/toaster.conf
-                        </literallayout>
-                        Following is a sample Apache configuration for Toaster
-                        you can follow:
-                        <literallayout class='monospaced'>
-     Alias /static /var/www/toaster/static_files
-     &lt;Directory /var/www/toaster/static_files&gt;
-             Order allow,deny
-             Allow from all
-             Require all granted
-     &lt;/Directory&gt;
+                      <para>
+                          Finally, the <filename>collectstatic</filename> command
+                          is a Django framework command that collects all the
+                          statically served files into a designated directory to
+                          be served up by the Apache web server.
+                      </para></listitem>
+                  <listitem><para>
+                      Add an Apache configuration file for Toaster to your Apache web
+                      server's configuration directory.
+                      If you are using Ubuntu or Debian, put the file here:
+                      <literallayout class='monospaced'>
+   /etc/apache2/conf-available/toaster.conf
+                      </literallayout>
+                      If you are using Fedora or RedHat, put it here:
+                      <literallayout class='monospaced'>
+   /etc/httpd/conf.d/toaster.conf
+                      </literallayout>
+                      Following is a sample Apache configuration for Toaster
+                      you can follow:
+                      <literallayout class='monospaced'>
+   Alias /static /var/www/toaster/static_files
+   &lt;Directory /var/www/toaster/static_files&gt;
+           Order allow,deny
+           Allow from all
+           Require all granted
+   &lt;/Directory&gt;
 
-     WSGIDaemonProcess toaster_wsgi python-path=/var/www/toaster/poky/bitbake/lib/toaster:/var/www/toaster/venv/lib/python2.7/site-packages
+   WSGIDaemonProcess toaster_wsgi python-path=/var/www/toaster/poky/bitbake/lib/toaster:/var/www/toaster/venv/lib/python2.7/site-packages
 
-     WSGIScriptAlias / "/var/www/toaster/poky/bitbake/lib/toaster/toastermain/wsgi.py"
-     &lt;Location /&gt;
-         WSGIProcessGroup toastern_wsgi
-     &lt;/Location&gt;
-                        </literallayout>
-                        If you are using Ubuntu or Debian,
-                        you will need to enable the config and module for Apache:
-                        <literallayout class='monospaced'>
-     $ sudo a2enmod wsgi
-     $ sudo a2enconf toaster
-     $ chmod +x bitbake/lib/toaster/toastermain/wsgi.py
-                        </literallayout>
-                        Finally, restart Apache to make sure all new configuration
-                        is loaded.
-                        For Ubuntu and Debian use:
-                        <literallayout class='monospaced'>
-     $ sudo service apache2 restart
-                        </literallayout>
-                        For Fedora and RedHat use:
-                        <literallayout class='monospaced'>
-     $ sudo service httpd restart
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        Install the build runner service.
-                        This service needs to be running in order to dispatch
-                        builds.
-                        Use this command:
-                        <literallayout class='monospaced'>
-     /var/www/toaster/poky/bitbake/lib/toaster/manage.py runbuilds
-                        </literallayout>
-                        Here is an example:
-                        <literallayout class='monospaced'>
-     #!/bin/sh
-     # toaster run builds dispatcher
-     cd /var/www/toaster/
-     source ./venv/bin/activate
-     ./bitbake/lib/toaster/manage.py runbuilds
-                        </literallayout>
-                        </para></listitem>
-                </orderedlist>
-                You can now open up a browser and start using Toaster.
-            </para>
-        </section>
-    </section>
+   WSGIScriptAlias / "/var/www/toaster/poky/bitbake/lib/toaster/toastermain/wsgi.py"
+   &lt;Location /&gt;
+       WSGIProcessGroup toastern_wsgi
+   &lt;/Location&gt;
+                      </literallayout>
+                      If you are using Ubuntu or Debian,
+                      you will need to enable the config and module for Apache:
+                      <literallayout class='monospaced'>
+   $ sudo a2enmod wsgi
+   $ sudo a2enconf toaster
+   $ chmod +x bitbake/lib/toaster/toastermain/wsgi.py
+                      </literallayout>
+                      Finally, restart Apache to make sure all new configuration
+                      is loaded.
+                      For Ubuntu and Debian use:
+                      <literallayout class='monospaced'>
+   $ sudo service apache2 restart
+                      </literallayout>
+                      For Fedora and RedHat use:
+                      <literallayout class='monospaced'>
+   $ sudo service httpd restart
+                      </literallayout>
+                      </para></listitem>
+                  <listitem><para>
+                      Install the build runner service.
+                      This service needs to be running in order to dispatch
+                      builds.
+                      Use this command:
+                      <literallayout class='monospaced'>
+   /var/www/toaster/poky/bitbake/lib/toaster/manage.py runbuilds
+                      </literallayout>
+                      Here is an example:
+                      <literallayout class='monospaced'>
+   #!/bin/sh
+   # toaster run builds dispatcher
+   cd /var/www/toaster/
+   source ./venv/bin/activate
+   ./bitbake/lib/toaster/manage.py runbuilds
+                      </literallayout>
+                      </para></listitem>
+              </orderedlist>
+              You can now open up a browser and start using Toaster.
+          </para>
+      </section>
+  </section>
 
+  <section id='using-the-toaster-web-interface'>
+      <title>Using the Toaster Web Interface</title>
 
+      <para>
+          The Toaster web interface allows you to do the following:
+          <itemizedlist>
+              <listitem><para>
+                  Browse published layers in the
+                  <ulink url='http://layers.openembedded.org'>OpenEmbedded Metadata Index</ulink>
+                  that are available for your selected version of the build
+                  system.
+                  </para></listitem>
+              <listitem><para>
+                  Import your own layers for building.
+                  </para></listitem>
+              <listitem><para>
+                  Add and remove layers from your configuration.
+                  </para></listitem>
+              <listitem><para>
+                  Set configuration variables.
+                  </para></listitem>
+              <listitem><para>
+                  Select a target or multiple targets to build.
+                  </para></listitem>
+              <listitem><para>
+                  Start your builds.
+                  </para></listitem>
+              <listitem><para>
+                  See what was built (recipes and packages) and what
+                  packages were installed into your final image.
+                  </para></listitem>
+              <listitem><para>
+                  Browse the directory structure of your image.
+                  </para></listitem>
+              <listitem><para>
+                  See the value of all variables in your build configuration,
+                  and which files set each value.
+                  </para></listitem>
+              <listitem><para>
+                  Examine error, warning and trace messages to aid in
+                  debugging.
+                  </para></listitem>
+              <listitem><para>
+                  See information about the BitBake tasks executed and
+                  reused during your build, including those that used
+                  shared state.
+                  </para></listitem>
+              <listitem><para>
+                  See dependency relationships between recipes, packages
+                  and tasks.
+                  </para></listitem>
+              <listitem><para>
+                  See performance information such as build time, task time,
+                  CPU usage, and disk I/O.
+                  </para></listitem>
+          </itemizedlist>
+      </para>
 
+      <section id='web-interface-videos'>
+          <title>Toaster Web Interface Videos</title>
 
-<!--    <section id='using-toaster-in-analysis-mode'>
-        <title>Using Toaster in Analysis Mode</title>
+          <para>
+              Following are several videos that show how to use the Toaster GUI:
+              <itemizedlist>
+                  <listitem><para><emphasis>Build Configuration:</emphasis>
+                      This
+                      <ulink url='https://www.youtube.com/watch?v=qYgDZ8YzV6w'>video</ulink>
+                      overviews and demonstrates build configuration for Toaster.
+                      </para></listitem>
+                  <listitem><para><emphasis>Build Custom Layers:</emphasis>
+                      This
+                      <ulink url='https://www.youtube.com/watch?v=QJzaE_XjX5c'>video</ulink>
+                      shows you how to build custom layers that are used with
+                      Toaster.
+                      </para></listitem>
+                  <listitem><para><emphasis>Toaster Homepage and Table Controls:</emphasis>
+                      This
+                      <ulink url='https://www.youtube.com/watch?v=QEARDnrR1Xw'>video</ulink>
+                      goes over the Toaster entry page, and provides
+                      an overview of the data manipulation capabilities of
+                      Toaster, which include search, sorting and filtering by
+                      different criteria.
+                      </para></listitem>
+                  <listitem><para><emphasis>Build Dashboard:</emphasis>
+                      This
+                      <ulink url='https://www.youtube.com/watch?v=KKqHYcnp2gE'>video</ulink>
+                      shows you the build dashboard, a page providing an
+                      overview of the information available for a selected build.
+                      </para></listitem>
+                  <listitem><para><emphasis>Image Information:</emphasis>
+                      This
+                      <ulink url='https://www.youtube.com/watch?v=XqYGFsmA0Rw'>video</ulink>
+                      walks through the information Toaster provides
+                      about images: packages installed and root file system.
+                      </para></listitem>
+                  <listitem><para><emphasis>Configuration:</emphasis>
+                      This
+                      <ulink url='https://www.youtube.com/watch?v=UW-j-T2TzIg'>video</ulink>
+                      provides Toaster build configuration information.
+                      </para></listitem>
+                  <listitem><para><emphasis>Tasks:</emphasis>
+                      This
+                      <ulink url='https://www.youtube.com/watch?v=D4-9vGSxQtw'>video</ulink>
+                      shows the information Toaster provides about the
+                      tasks run by the build system.
+                      </para></listitem>
+                  <listitem><para><emphasis>Recipes and Packages Built:</emphasis>
+                      This
+                      <ulink url='https://www.youtube.com/watch?v=x-6dx4huNnw'>video</ulink>
+                      shows the information Toaster provides about recipes
+                      and packages built.
+                      </para></listitem>
+                  <listitem><para><emphasis>Performance Data:</emphasis>
+                      This
+                      <ulink url='https://www.youtube.com/watch?v=qWGMrJoqusQ'>video</ulink>
+                      shows the build performance data provided by
+                      Toaster.
+                      </para></listitem>
+              </itemizedlist>
+          </para>
+      </section>
 
+      <section id='a-note-on-the-local-yocto-project-release'>
+          <title>Additional Information About the Local Yocto Project Release</title>
 
-        <para>
-            This section describes how to use Toaster in Analysis Mode
-            after setting Toaster up as a local instance or as a hosted
-            service.
-        </para>
+          <para>
+              This section only applies if you have set up Toaster
+              for local development, as explained in the
+              "<link linkend='starting-toaster-for-local-development'>Starting Toaster for Local Development</link>"
+              section.
+          </para>
 
-        <section id='setting-up-locally-and-running-in-analysis-mode'>
-            <title>Setting Up Locally and Running in Analysis Mode</title>
+          <para>
+              When you create a project in Toaster, you will be asked to
+              provide a name and to select a Yocto Project release.
+              One of the release options you will find is called
+              "Local Yocto Project".
+              <imagedata fileref="figures/new-project.png" align="center" width="9in" />
+          </para>
 
-            <para>
-                Follow these steps to set up a local instance of Toaster and
-                then run in Analysis Mode:
-                <orderedlist>
-                    <listitem><para><emphasis>Prepare your Build System:</emphasis>
-                        Be sure your system has the Toaster requirements
-                        by following the steps in the
-                        "<link linkend='toaster-establishing-toaster-system-dependencies'>Establishing Toaster System Dependencies</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Get Set Up to Use the Yocto Project:</emphasis>
-                        Get the requirements set up so that you can use the
-                        Yocto Project to build images.
-                        See the
-                        "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>Setting Up to Use the Yocto Project</ulink>"
-                        section in the Yocto Project Quick Start for information.
-                        </para></listitem>
-                    <listitem><para><emphasis>Source your Build Environment Setup Script:</emphasis>
-                        From your
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
-                        (e.g. <filename>poky/build</filename>), source the build
-                        environment setup script
-                        <ulink url="&YOCTO_DOCS_REF_URL;#structure-core-script"><filename>&OE_INIT_FILE;</filename></ulink>
-                        or
-                        <ulink url="&YOCTO_DOCS_REF_URL;#structure-memres-core-script"><filename>oe-init-build-env-memres</filename></ulink>.
-                        </para></listitem>
-                    <listitem><para><emphasis>Start Toaster:</emphasis>
-                        From the
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
-                        start Toaster:
-                        <literallayout class='monospaced'>
-     $ source toaster start
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Start Your Build Using BitBake:</emphasis>
-                        Use the <filename>bitbake</filename> command to start your
-                        build.
-                        Here is an example that builds the
-                        <filename>core-image-minimal</filename> image:
-                        <literallayout class='monospaced'>
-     $ bitbake core-image-minimal
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Open Your Browser:</emphasis>
-                        Open your browser and visit
-                        <filename>http://host:port/toastergui</filename>.
-                        For host and port values, see the output of the
-                        <filename>source toaster start</filename> command.
-                        For information on how to use Toaster, see the
-                        "<link linkend='using-the-toaster-web-interface'>Using the Toaster Web Interface</link>"
-                        section.
-                        </para></listitem>
-                </orderedlist>
-            </para>
+          <para>
+              When you select the "Local Yocto Project" release, Toaster
+              will run your builds using the local Yocto
+              Project clone you have in your computer: the same clone
+              you are using to run Toaster.
+              Unless you manually update
+              this clone, your builds will always use the same Git revision.
+          </para>
 
-            <para>
+          <para>
+              If you select any of the other release options, Toaster
+              will fetch the tip of your selected release from the upstream
+              <ulink url='https://git.yoctoproject.org'>Yocto Project repository</ulink>
+              every time you run a build.
+              Fetching this tip effectively
+              means that if your selected release is updated upstream, the
+              Git revision you are using for your builds will change.
+              If you are doing development locally, you might not want this
+              change to happen.
+              In that case, the "Local Yocto Project"
+              release might be the right choice.
+          </para>
 
-            </para>
-        </section>
+          <para>
+              However, the "Local Yocto Project" release
+              will not provide you with any compatible layers, other than the
+              three core layers that come with the Yocto Project:
+              <itemizedlist>
+                  <listitem><para>
+                      <ulink url='http://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/'>openembedded-core</ulink>
+                  </para></listitem>
+                  <listitem><para>
+                      <ulink url='http://layers.openembedded.org/layerindex/branch/master/layer/meta-poky/'>meta-poky</ulink>
+                  </para></listitem>
+                  <listitem><para>
+                      <ulink url='http://layers.openembedded.org/layerindex/branch/master/layer/meta-yocto-bsp/'>meta-yocto-bsp</ulink>
+                  </para></listitem>
+              </itemizedlist>
+              <imagedata fileref="figures/compatible-layers.png" align="center" width="9in" />
+          </para>
 
-        <section id='setting-up-a-hosted-service-and-running-in-analysis-mode'>
-            <title>Setting Up a Hosted Service and Running in Analysis Mode</title>
-
-            <para>
-                A hosted service resides on a shared server and allows
-                multiple users to take advantage of Toaster.
-            </para>
-
-            <para>
-                In a production environment, you might want to have multiple
-                local instances of the Toaster Logging Interface running on
-                various remote build machines, and have those local instances
-                access and use a single web server.
-                To do this, you need to do the following:
-                <itemizedlist>
-                    <listitem><para>
-                        Maintain a common SQL database.
-                        </para></listitem>
-                    <listitem><para>
-                        Set up separate instances of BitBake servers
-                        and Toaster Logging Interfaces for each of those
-                        separate BitBake servers.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                The common SQL database allows the Web server to show data from
-                all the various BitBake builds.
-                Setting the SQL database outside of any
-                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-                maintains a separation between the various builds.
-                The BitBake servers, the SQL server, and the Web server or
-                servers can be run on separate machines.
-            </para>
-
-            <para>
-                Follow these steps to set up and run a hosted service and run
-                Toaster in Analysis Mode:
-                <note>
-                    The steps assume a Toaster installation path of
-                    <filename>/opt/bitbake/</filename>.
-                </note>
-                <orderedlist>
-                    <listitem><para><emphasis>Prepare your Build System:</emphasis>
-                        Be sure your system has the Toaster requirements
-                        by following the steps in the
-                        "<link linkend='toaster-establishing-toaster-system-dependencies'>Establishing Toaster System Dependencies</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Get Set Up to Use the Yocto Project:</emphasis>
-                        Get the requirements set up so that you can use the
-                        Yocto Project to build images.
-                        See the
-                        "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>Setting Up to Use the Yocto Project</ulink>"
-                        section in the Yocto Project Quick Start for information.
-                        </para></listitem>
-                    <listitem><para><emphasis>Install and Set up the Database Server:</emphasis>
-                        You can use any SQL server out of the box.
-                        It is recommended that you use
-                        <filename>mysql-server</filename> because it has
-                        the advantages of advanced SQL features along with a
-                        fast and reliable database.
-                        However, setting up <filename>mysql-server</filename>
-                        is more complex and might require a Database
-                        Administrator to tune it.</para>
-                        <para>Another supported database backend is
-                        <filename>sqlite3</filename>.
-                        With <filename>sqlite3</filename>, you have the
-                        advantage of no configuration and an easy installation.
-                        However, Toaster still requires direct access to the
-                        backend.
-                        The <filename>sqlite</filename> backend is also slower
-                        as compared to <filename>mysql-server</filename>, and
-                        has no transactional support.</para>
-                        <para>You should set up proper username and password
-                        access on the shared database for everyone that will
-                        be using Toaster.
-                        You need administrator rights for the root account,
-                        which is not the same thing as root access on the
-                        machine.
-                        Here is an example that installs
-                        <filename>mysql-server</filename> and sets up
-                        some user accounts and the database.
-                        <literallayout class='monospaced'>
-     $ apt-get install mysql-server
-     $ mysql -u root
-     mysql> CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'password';
-     mysql> GRANT ALL PRIVILEGES ON * . * TO 'newuser'@'localhost';
-     mysql> GRANT ALL PRIVILEGES ON * . * TO 'newuser'@'localhost';
-     mysql> CREATE DATABASE 'toaster';
-                        </literallayout>
-                        You need a separate clone of the
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>
-                        for the Database Server.
-                        This clone is only used for getting the latest Toaster
-                        files.
-                        You can set this up using the following Git command.
-                        Be sure to set up the directory outside of any
-                        Build Directories.
-                        <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/poky
-                        </literallayout>
-                        In the separately cloned tree for the Database Server,
-                        edit the
-                        <filename>bitbake/lib/toaster/toastermain/settings.py</filename>
-                        file so that the <filename>DATABASES</filename> value
-                        points to the previously created database server.
-                        Use the username and password established
-                        earlier.
-                        Here is an example:
-                        <literallayout class='monospaced'>
-     $ cat /opt/bitbake/lib/toaster/toastermain/settings.py
-        ...
-     DATABASES = {
-         'default': {
-             'ENGINE': 'django.db.backends.mysql',
-             'NAME': 'toaster',
-             'USER': 'newuser',
-             'PASSWORD': 'password',
-             'HOST': '192.168.0.25',
-             'PORT': '3306',
-         }
-        ...
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Install and Set Up the Web Server:</emphasis>
-                        For a production environment, it is recommended that
-                        you install and set up a front-end web server.
-                        This server allows for load balancing and
-                        multi-threading over Toaster and
-                        <ulink url='https://docs.djangoproject.com/en/1.7/howto/deployment/wsgi/'><filename>django</filename> WSGI</ulink>.
-                        Here is an example that uses Apache web server.
-                        <literallayout class='monospaced'>
-     $ apt-get install apache2 libapache2-mod-wsgi
-     $ a2enmod wsgi
-     $ cat /etc/apache2/sites-available/000-default.conf
-
-        ...
-
-     # the WSGIPythonPath is global
-     WSGIPythonPath /opt/bitbake/lib/toaster/
-
-        ...
-
-     #snip - in VirtualHost
-     WSGIScriptAlias / /opt/bitbake/lib/toaster/toastermain/wsgi.py
-
-     &lt;Directory //opt/bitbake/lib/toaster/toastermain/&gt;
-         &lt;Files wsgi.py&gt;
-             Require all granted
-         &lt;/Files&gt;
-     &lt;/Directory&gt;
-
-        ...
-                        </literallayout>
-                        You need to collect static media from Toaster and
-                        continue configuring Apache to serve that static
-                        media:
-                        <literallayout class='monospaced'>
-     $ mkdir /var/www.html/static &amp;&amp; cd /var/www.html/static
-     $ /opt/bitbake/lib/toaster/manage.py collectstatic
-     $ cat /etc/apache2/sites-available/000-default.conf
-
-        ...
-
-     # in VirtualHost, AHEAD of the WSGIScriptAlias definition
-     Alias /static/ /var/www.html/static/
-
-     &lt;Directory /var/www.html/static/&gt;
-     Require all granted
-     &lt;/Directory&gt;
-
-        ...
-
-     WSGIScript Alias / /opt/bitbake/lib/toaster/toastermain/wsgi.py
-
-        ...
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Start Toaster:</emphasis>
-                        Synchronize the databases for toaster, and then start
-                        up the web server.
-                        Here is an example that continues with the assumed
-                        components from the previous steps:
-                        <literallayout class='monospaced'>
-     $ /opt/bitbake/lib/toaster/manage.py syncdb
-     $ /opt/bitbake/lib/toaster/manage.py migrate orm
-     $ /opt/bitbake/lib/toaster/manage.py migrate bldcontrol
-
-     $ service apache2 restart
-                        </literallayout>
-                        You can find general documentation on
-                        <filename>manage.py</filename> at the
-                        <ulink url='https://docs.djangoproject.com/en/1.7/ref/django-admin/'>Django</ulink>
-                        site.
-                        For reference information on Toaster-specific
-                        <filename>manage.py</filename> commands,
-                        see the
-                        "<link linkend='toaster-useful-commands'>Useful Commands</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Enable Build Logging to the Common SQL Server for Each Build Directory you are Using:</emphasis>
-                        You need to make sure that the
-                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-toaster'><filename>toaster</filename></ulink>
-                        class and build history are enabled.
-                        This is done in a
-                        <filename>toaster.conf</filename> file that is
-                        created automatically by the toaster
-                        <filename>start</filename> command,
-                        and that lives inside the
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-                        in <filename>/conf/toaster.conf</filename>.</para>
-                        <para>That file should include the following line:
-                        <literallayout class='monospaced'>
-     INHERIT += "toaster buildhistory"
-                        </literallayout>
-                        For information on build history, see the
-                        "<ulink url='&YOCTO_DOCS_REF_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
-                        section in the Yocto Project Development
-                        Manual.</para>
-                        <para>You also need to point to the database that you set
-                        up in step 3.
-                        You can do this by exporting the <filename>DATABASE_URL</filename>
-                        variable as follows:
-                        <literallayout class='monospaced'>
-     export DATABASE_URL=mysql://newuser:password@192.168.0.25:3306/toaster
-                        </literallayout>
-                        This example assumes that you are using
-                        <filename>mysql-server</filename>.
-                        The IP address should be the IP address of your
-                        database server.
-                        </para></listitem>
-                    <listitem><para><emphasis>Source your Build Environment Setup Script:</emphasis>
-                        From your
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
-                        on each of the build systems,
-                        (e.g. <filename>poky/build</filename>), source the
-                        build environment setup script (i.e.
-                        <ulink url="&YOCTO_DOCS_REF_URL;#structure-core-script"><filename>&OE_INIT_FILE;</filename></ulink>
-                        or
-                        <ulink url="&YOCTO_DOCS_REF_URL;#structure-memres-core-script"><filename>oe-init-build-env-memres</filename></ulink>).
-                        </para></listitem>
-                    <listitem><para><emphasis>Start the BitBake Server:</emphasis>
-                        Start the BitBake server using the following command:
-                        <literallayout class='monospaced'>
-     $ bitbake &dash;&dash;postread conf/toaster.conf &dash;&dash;server-only -t xmlrpc -B localhost:0 &amp;&amp; export BBSERVER=localhost:-1
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Start the Logging Server:</emphasis>
-                        Start the Toaster Logging Interface using the following
-                        command:
-                        <literallayout class='monospaced'>
-     $ nohup bitbake &dash;&dash;observe-only -u toasterui >toaster_ui.log &amp;
-                        </literallayout>
-                        <note>
-                            No hard-coded ports are used in the BitBake options
-                            as there is enough code to run
-                            <filename>autodiscovery</filename> for BitBake
-                            ports.
-                            Doing so prevents collisions.
-                        </note>
-                        </para></listitem>
-                    <listitem><para><emphasis>Start Builds Using BitBake:</emphasis>
-                        Use the <filename>bitbake</filename> command to start a
-                        build on a build system.
-                        Here is an example that builds the
-                        <filename>core-image-minimal</filename> image:
-                        <literallayout class='monospaced'>
-     $ bitbake core-image-minimal
-                        </literallayout>
-                        When you are finished with a build in a given
-                        Build Directory, be sure to <filename>kill</filename>
-                        the BitBake server for that build area:
-                        <literallayout class='monospaced'>
-     $ bitbake -m
-                        </literallayout>
-                        </para></listitem>
-                </orderedlist>
-            </para>
-
-            <para>
-                For information on how to use the Toaster web interface,
-                see the
-                "<link linkend='using-the-toaster-web-interface'>Using the Toaster Web Interface</link>"
-                section.
-            </para>
-        </section>
-    </section>
-
-    <section id='using-toaster-in-build-mode'>
-        <title>Using Toaster in Build Mode</title>
-
-        <para>
-            This section describes how to use Toaster in Build Mode
-            after setting Toaster up as a local instance or as a hosted
-            service.
-        </para>
-
-        <section id='setting-up-locally-and-running-in-build-mode'>
-            <title>Setting Up Locally and Running in Build Mode</title>
-
-            <para>
-                Follow these steps to set up a local instance of Toaster and
-                then run in Build Mode:
-                <orderedlist>
-                    <listitem><para><emphasis>Prepare your Build System:</emphasis>
-                        Be sure your system has the Toaster requirements
-                        by following the steps in the
-                        "<link linkend='toaster-establishing-toaster-system-dependencies'>Establishing Toaster System Dependencies</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Get Set Up to Use the Yocto Project:</emphasis>
-                        Get the requirements set up so that you can use the
-                        Yocto Project to build images.
-                        See the
-                        "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>Setting Up to Use the Yocto Project</ulink>"
-                        section in the Yocto Project Quick Start for information.
-                        </para></listitem>
-                    <listitem><para><emphasis>Start Toaster:</emphasis>
-                        From the root of the source directory (e.g
-                        <filename>poky/</filename>), run the following command:
-                        <literallayout class='monospaced'>
-     $ bitbake/bin/toaster
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Create a Superuser:</emphasis>
-                        Django will ask you if you want to create a superuser.
-                        You can skip this step, but it is recommended that you
-                        create a superuser.
-                        You can use the superuser to access the Django
-                        administration interface and make changes to the
-                        Toaster configuration.
-                        </para></listitem>
-                    <listitem><para><emphasis>Select the Build Log Directory:</emphasis>
-                        Toaster asks you to specify the directory where you
-                        want to store the build log files.
-                        Choosing a directory for these files makes sure they
-                        are always available to you.
-                        If you do not choose a directory, the logs can
-                        disappear (e.g. deleting the Build Directory).</para>
-                        <para>When Toaster prompts you for the Build Log
-                        directory, you can select the suggested default
-                        or provide a path to a different directory.
-                        </para></listitem>
-                    <listitem><para><emphasis>Specify the Layer Checkout Directory:</emphasis>
-                        Toaster asks you to specify the directory into which
-                        layers are checked out.
-                        Toaster clones any layers needed for your builds
-                        inside this directory.</para>
-                        <para>When Toaster prompts you for the Layer
-                        checkout directory, you can select the suggested
-                        default or provide a path to a different directory.
-                        </para></listitem>
-                    <listitem><para><emphasis>Specify the Build Directory Path:</emphasis>
-                        Toaster asks you to specify the path to the
-                        Build Directory.
-                        You can select the suggested default or provide a
-                        path to a different directory.
-                        </para></listitem>
-                    <listitem><para><emphasis>Choose Whether or not to Import a Default Toaster Configuration File:</emphasis>
-                        Toaster asks you if you want to import a default
-                        Toaster configuration file.
-                        Toaster configurations are stored in
-                        JSON files called
-                        <filename>toasterconf.json</filename>.
-                        For information on JSON files, see the
-                        "<link linkend='toaster-json-files'>JSON Files</link>"
-                        section.</para>
-                        <para>You can skip importing a configuration file
-                        by entering "0" at the prompt.
-                        However, it is recommended that you import one of the
-                        configuration files listed during this step.
-                        You can always amend the imported configuration during
-                        a later stage through the Django administration
-                        interface.</para>
-                        <para>For general information on Django, see the
-                        available
-                        <ulink url='https://docs.djangoproject.com/en/1.7/'>documentation</ulink>.
-                        You can also find information on Toaster-specific
-                        <filename>manage.py</filename> commands in the
-                        "<link linkend='toaster-useful-commands'>Useful Commands</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Open the Browser:</emphasis>
-                        If no browser window appears, open your favorite
-                        browser and enter the following:
-                        <literallayout class='monospaced'>
-     http://localhost:8000/toastergui
-                        </literallayout>
-                        You can now use the Toaster web interface.
-                        </para></listitem>
-                </orderedlist>
-            </para>
-        </section>
-
-        <section id='setting-up-a-hosted-service-and-running-in-build-mode'>
-            <title>Setting Up a Hosted Service and Running in Build Mode</title>
-
-            <para>
-                Follow these steps to set up a hosted service and run Toaster
-                in Build Mode:
-                <orderedlist>
-                    <listitem><para><emphasis>Prepare your Build System:</emphasis>
-                        Be sure your system has the Toaster requirements
-                        by following the steps in the
-                        "<link linkend='toaster-establishing-toaster-system-dependencies'>Establishing Toaster System Dependencies</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Get Set Up to Use the Yocto Project:</emphasis>
-                        Get the requirements set up so that you can use the
-                        Yocto Project to build images.
-                        See the
-                        "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>Setting Up to Use the Yocto Project</ulink>"
-                        section in the Yocto Project Quick Start for information.
-                        </para></listitem>
-                    <listitem><para><emphasis>Be Sure Management is Enabled:</emphasis>
-                        If you are running Toaster under Apache, you need to
-                        be sure management is enabled.
-                        To enable management, set
-                        <filename>MANAGED</filename> to "True" by adding
-                        the following to the
-                        <filename>bitbake/lib/toaster/settings.py</filename>
-                        file:
-                        <literallayout class='monospaced'>
-     MANAGED="True"
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Set Up Toaster for Normal Usage:</emphasis>
-                        You need to configure each build environment, layer
-                        sources, and BitBake versions.</para>
-                        <para>Verify that your releases have been loaded correctly by
-                        using the Toaster web interface to create a new
-                        project.
-                        Check the "Releases" dropdown menu to be sure your
-                        newly specified releases exist.</para>
-                        <para>If you want to use the administration interface
-                        for this step, here is a set of example commands
-                        with some descriptions as an example:
-                        <literallayout class='monospaced'>
-     # Create the user under which the builds will run
-     $ adduser poky
-
-     # Bring up the administration interface
-     $xdg-open http://<replaceable>server-address</replaceable>/admin/
-
-     # Login with the admin user previously created
-
-     # Go to the BuildEnvironment object in Build Environments and
-     # set address to local host, sourcedir to /home/poky, and
-     # builddir to /home/pokybuild.
-     #
-     # Save your changes and exit
-
-     # Go to Home, Layer Sources and select add Layer Source
-     # Name: OpenEmbedded, Sourcetype: layerindex,
-     # Apiurl: http://layers openembedded.org/layerindex/api/
-     # Save your changes and exit
-
-     # Go to Home, Bitbake Versions, Add bitbake version;
-     # Take version information from: http://git.openembedded.org/bitbake/refs/heads,
-     # This example assumes "master" version.
-     # set Name: master, Giturl git://git.openembedded.org/bitbake
-     # branch master, dirpath /
-     # Save your changes and exit
-                        </literallayout>
-                        You also need to configure the project releases, the
-                        default variables, and update information from the
-                        layer index.
-                        Continuing with the example:
-                        <literallayout class='monospaced'>
-     # Go to Home, Releases, Add release
-     # set Name: master, Description: Current master release, select Bitbake Version,
-     # and Branch: master
-     # Save your changes and exit
-
-     # Go to Home, Toaster Settings, select the Setting for DEFAULT_RELEASE
-     # set Helptext: This selects the default release., Value: master
-     # Save your changes and exit
-
-     # Go to Home, Bitbake Versions, Add bitbake version;
-     # take version information from : http://git.openembedded.org/bitbake/refs/heads,
-     # this manual assumes the master version
-     # set Name: master, Giturl git://git.openembedded.org/bitbake
-     # branch master, dirpath /
-     # Save your changes and exit
-
-     # Update the information
-     # bitbake/lib/toaster/manage.py lsupdates
-                        </literallayout>
-                        For reference information on Toaster-specific
-                        <filename>manage.py</filename> commands, see the
-                        "<link linkend='toaster-useful-commands'>Useful Commands</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Install and Set up the Database Server:</emphasis>
-                        You can use any SQL server out of the box.
-                        It is recommended that you use
-                        <filename>mysql-server</filename> because it has
-                        the advantages of advanced SQL features along with a
-                        fast and reliable database.
-                        However, setting up <filename>mysql-server</filename>
-                        is more complex and might require a Database
-                        Administrator to tune it.</para>
-                        <para>Another supported database backend is
-                        <filename>sqlite3</filename>.
-                        With <filename>sqlite3</filename>, you have the
-                        advantage of no configuration and an easy installation.
-                        However, Toaster still requires direct access to the
-                        backend.
-                        The <filename>sqlite</filename> backend is also slower
-                        as compared to <filename>mysql-server</filename>, and
-                        has no transactional support.</para>
-                        <para>You should set up proper username and password
-                        access on the shared database for everyone that will
-                        be using Toaster.
-                        You need administrator rights for the root account,
-                        which is not the same thing as root access on the
-                        machine.
-                        Here is an example that installs
-                        <filename>mysql-server</filename> and sets up
-                        some user accounts and the database.
-                        <literallayout class='monospaced'>
-     $ apt-get install mysql-server
-     $ mysql -u root
-     mysql> CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'password';
-     mysql> GRANT ALL PRIVILEGES ON * . * TO 'newuser'@'localhost';
-     mysql> GRANT ALL PRIVILEGES ON * . * TO 'newuser'@'localhost';
-     mysql> CREATE DATABASE 'toaster';
-                        </literallayout>
-                        You need a separate clone of the
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>
-                        for the Database Server.
-                        This clone is only used for getting the latest Toaster
-                        files.
-                        You can set this up using the following Git command.
-                        Be sure to set up the directory outside of any
-                        Build Directories.
-                        <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/poky
-                        </literallayout>
-                        In the separately cloned tree for the Database Server,
-                        edit the
-                        <filename>bitbake/lib/toaster/toastermain/settings.py</filename>
-                        file so that the <filename>DATABASES</filename> value
-                        points to the previously created database server.
-                        Use the username and password established
-                        earlier.
-                        Here is an example:
-                        <literallayout class='monospaced'>
-     $ cat /opt/bitbake/lib/toaster/toastermain/settings.py
-        ...
-     DATABASES = {
-         'default': {
-             'ENGINE': 'django.db.backends.mysql',
-             'NAME': 'toaster',
-             'USER': 'newuser',
-             'PASSWORD': 'password',
-             'HOST': '192.168.0.25',
-             'PORT': '3306',
-         }
-        ...
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Create the Database</emphasis>
-                        Use the following commands to create the default
-                        database structure:
-                        <literallayout class='monospaced'>
-     $ bitbake/lib/toaster/manage.py syncdb
-     $ bitbake/lib/toaster/manage.py migrate orm
-     $ bitbake/lib/toaster/manage.py migrate bldcontrol
-                        </literallayout>
-                        The interface asks you if you want to create a
-                        superuser.
-                        Do not skip this step.
-                        You will use the superuser account to access the
-                        administration interface and make changes to the
-                        Toaster configuration.
-                        </para></listitem>
-                    <listitem><para><emphasis>Select Where the Build Process Takes Place:</emphasis>
-                        You need to create three directories for storing
-                        build artifacts, downloading sources, and running
-                        builds.
-                        All three directories need to be writable by
-                        the user, which is "poky" in this example.
-                        The build artifacts directory needs to readable by the
-                        apache user.
-                        You also need free disk space in the range of
-                        100 Gbytes.
-                        Following are three suggested directories:
-                        <literallayout class='monospaced'>
-     /home/poky/buildartifacts/
-     /home/poky/build/
-     /home/poky/sources/
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Set Up the <filename>toasterconf.json</filename> File:</emphasis>
-                        <ulink url='https://wiki.yoctoproject.org/wiki/File:Toasterconf.json.txt.patch'>Download the hosted <filename>toasterconf.json</filename> file</ulink>
-                        from the Yocto Project wiki and edit it to suit your
-                        environment.
-                        For information on the relevant sections of the file,
-                        see the
-                        "<link linkend='toaster-json-files'>JSON Files</link>"
-                        section.</para>
-                        <para>After editing the file, load it by running
-                        the following:
-                        <literallayout class='monospaced'>
-     $ bitbake/lib/toaster/manage.py loadconf path-to-toasterconf.json-file
-                        </literallayout>
-                        For reference information on Toaster-specific
-                        <filename>manage.py</filename>, see the
-                        "<link linkend='toaster-useful-commands'>Useful Commands</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Check the Toaster Settings:</emphasis>
-                        Configure the build environment by running the
-                        following:
-                        <literallayout class='monospaced'>
-     $ bitbake/lib/toaster/manage.py checksettings
-                        </literallayout>
-                        When prompted, paste in the directory paths created
-                        previously during Step 7.
-                        For reference information on Toaster-specific
-                        <filename>manage.py</filename>, see the
-                        "<link linkend='toaster-useful-commands'>Useful Commands</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Install and Set Up the Web Server:</emphasis>
-                        For a production environment, it is recommended that
-                        you install and set up a front-end web server.
-                        This server allows for load balancing and
-                        multi-threading over Toaster and
-                        <ulink url='https://docs.djangoproject.com/en/1.7/howto/deployment/wsgi/'><filename>django</filename> WSGI</ulink>.
-                        Here is an example that uses Apache web server:
-                        <literallayout class='monospaced'>
-     $ apt-get install apache2 libapache2-mod-wsgi
-     $ a2enmod wsgi
-     $ cat /etc/apache2/sites-available/000-default.conf
-
-        ...
-
-     # the WSGIPythonPath is global
-     WSGIPythonPath /opt/bitbake/lib/toaster/
-
-        ...
-
-     #snip - in VirtualHost
-     WSGIScriptAlias / /opt/bitbake/lib/toaster/toastermain/wsgi.py
-
-     &lt;Directory //opt/bitbake/lib/toaster/toastermain/&gt;
-         &lt;Files wsgi.py&gt;
-             Require all granted
-         &lt;/Files&gt;
-     &lt;/Directory&gt;
-
-        ...
-                        </literallayout>
-                        You need to collect static media from Toaster and
-                        continue configuring Apache to serve that static
-                        media:
-                        <literallayout class='monospaced'>
-     $ mkdir /var/www.html/static &amp;&amp; cd /var/www.html/static
-     $ /opt bitbake/lib/toaster/manage.py collectstatic
-     $ cat /etc/apache2/sites-available/000-default.conf
-
-        ...
-
-     # in VirtualHost, AHEAD of the WSGIScriptAlias definition
-     Alias /static/ /var/www.html/static/
-
-     &lt;Directory /var/www.html/static/&gt;
-     Require all granted
-     &lt;/Directory&gt;
-
-        ...
-
-     WSGIScript Alias / /opt/bitbake/lib/toaster/toastermain/wsgi.py
-
-        ...
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Start Toaster:</emphasis>
-                        Synchronize the databases for Toaster, and then start
-                        up the web server.
-                        Here is an example that continues with the assumed
-                        components from the previous steps:
-                        <literallayout class='monospaced'>
-     $ /opt/bitbake/lib/toaster/manage.py syncdb
-     $ /opt/bitbake/lib/toaster/manage.py migrate orm
-     $ /opt/bitbake/lib/toaster/manage.py migrate bldcontrol
-
-     $ service apache2 restart
-                        </literallayout>
-                        For reference information on the
-                        <filename>manage.py</filename> commands used here,
-                        see the
-                        "<link linkend='toaster-useful-commands'>Useful Commands</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><emphasis>Set up Build Control and Open the Web Interface:</emphasis>
-                        You need to run the build control manager.
-                        You can do this as shown in the following example:
-                        <literallayout class='monospaced'>
-     # as the "poky" user, start the runbuilds command in a loop (or put it in crontab!)
-     $ sudo -i -u poky
-     $ while true; do /opt/bitbake/lib/toaster/manage.py runbuilds; sleep 10; done
-
-     # open up the web interface
-     $ xdg-open http://[server-address]/toastergui/
-                        </literallayout>
-                        It is suggested that you enable build control by
-                        setting <filename>runbuilds</filename> in the
-                        <filename>crontab</filename> as follows:
-                        <literallayout class='monospaced'>
-     $ crontab -l
-     * * * * *  /opt/bitbake/lit/toaster/manage.py runbuilds
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para><emphasis>Open the Browser:</emphasis>
-                        Once the Apache server is running, connect to it with
-                        your favorite browser and verify that the Toaster
-                        interface comes up:
-                        <literallayout class='monospaced'>
-     http://localhost:8000/toastergui
-                        </literallayout>
-                        You can track accesses and errors in the Apache
-                        service logs.
-                        </para></listitem>
-                </orderedlist>
-            </para>
-        </section>
-    </section>
--->
-
-    <section id='using-the-toaster-web-interface'>
-        <title>Using the Toaster Web Interface</title>
-
-        <para>
-            The Toaster web interface allows you to do the following:
-            <itemizedlist>
-                <listitem><para>
-                    Browse published layers in the
-                    <ulink url='http://layers.openembedded.org'>OpenEmbedded Metadata Index</ulink>
-                    that are available for your selected version of the build
-                    system.
-                    </para></listitem>
-                <listitem><para>
-                    Import your own layers for building.
-                    </para></listitem>
-                <listitem><para>
-                    Add and remove layers from your configuration.
-                    </para></listitem>
-                <listitem><para>
-                    Set configuration variables.
-                    </para></listitem>
-                <listitem><para>
-                    Select a target or multiple targets to build.
-                    </para></listitem>
-                <listitem><para>
-                    Start your builds.
-                    </para></listitem>
-                <listitem><para>
-                    See what was built (recipes and packages) and what
-                    packages were installed into your final image.
-                    </para></listitem>
-                <listitem><para>
-                    Browse the directory structure of your image.
-                    </para></listitem>
-                <listitem><para>
-                    See the value of all variables in your build configuration,
-                    and which files set each value.
-                    </para></listitem>
-                <listitem><para>
-                    Examine error, warning and trace messages to aid in
-                    debugging.
-                    </para></listitem>
-                <listitem><para>
-                    See information about the BitBake tasks executed and
-                    reused during your build, including those that used
-                    shared state.
-                    </para></listitem>
-                <listitem><para>
-                    See dependency relationships between recipes, packages
-                    and tasks.
-                    </para></listitem>
-                <listitem><para>
-                    See performance information such as build time, task time,
-                    CPU usage, and disk I/O.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-
-        <section id='web-interface-videos'>
-            <title>Toaster Web Interface Videos</title>
+          <para>
+              If you want to build any other layers, you will need to
+              manually import them into your Toaster project, using the
+              "Import layer" page.
+              <imagedata fileref="figures/import-layer.png" align="center" width="9in" />
+          </para>
 
-            <para>
-                Following are several videos that show how to use the Toaster GUI:
-                <itemizedlist>
-                    <listitem><para><emphasis>Build Configuration:</emphasis>
-                        This
-                        <ulink url='https://www.youtube.com/watch?v=qYgDZ8YzV6w'>video</ulink>
-                        overviews and demonstrates build configuration for Toaster.
-                        </para></listitem>
-                    <listitem><para><emphasis>Build Custom Layers:</emphasis>
-                        This
-                        <ulink url='https://www.youtube.com/watch?v=QJzaE_XjX5c'>video</ulink>
-                        shows you how to build custom layers that are used with
-                        Toaster.
-                        </para></listitem>
-                    <listitem><para><emphasis>Toaster Homepage and Table Controls:</emphasis>
-                        This
-                        <ulink url='https://www.youtube.com/watch?v=QEARDnrR1Xw'>video</ulink>
-                        goes over the Toaster entry page, and provides
-                        an overview of the data manipulation capabilities of
-                        Toaster, which include search, sorting and filtering by
-                        different criteria.
-                        </para></listitem>
-                    <listitem><para><emphasis>Build Dashboard:</emphasis>
-                        This
-                        <ulink url='https://www.youtube.com/watch?v=KKqHYcnp2gE'>video</ulink>
-                        shows you the build dashboard, a page providing an
-                        overview of the information available for a selected build.
-                        </para></listitem>
-                    <listitem><para><emphasis>Image Information:</emphasis>
-                        This
-                        <ulink url='https://www.youtube.com/watch?v=XqYGFsmA0Rw'>video</ulink>
-                        walks through the information Toaster provides
-                        about images: packages installed and root file system.
-                        </para></listitem>
-                    <listitem><para><emphasis>Configuration:</emphasis>
-                        This
-                        <ulink url='https://www.youtube.com/watch?v=UW-j-T2TzIg'>video</ulink>
-                        provides Toaster build configuration information.
-                        </para></listitem>
-                    <listitem><para><emphasis>Tasks:</emphasis>
-                        This
-                        <ulink url='https://www.youtube.com/watch?v=D4-9vGSxQtw'>video</ulink>
-                        shows the information Toaster provides about the
-                        tasks run by the build system.
-                        </para></listitem>
-                    <listitem><para><emphasis>Recipes and Packages Built:</emphasis>
-                        This
-                        <ulink url='https://www.youtube.com/watch?v=x-6dx4huNnw'>video</ulink>
-                        shows the information Toaster provides about recipes
-                        and packages built.
-                        </para></listitem>
-                    <listitem><para><emphasis>Performance Data:</emphasis>
-                        This
-                        <ulink url='https://www.youtube.com/watch?v=qWGMrJoqusQ'>video</ulink>
-                        shows the build performance data provided by
-                        Toaster.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-        </section>
+      </section>
 
-        <section id='toaster-web-interface-preferred-version'>
-            <title>Building a Specific Recipe Given Multiple Versions</title>
+      <section id='toaster-web-interface-preferred-version'>
+          <title>Building a Specific Recipe Given Multiple Versions</title>
 
             <para>
                 Occasionally, a layer might provide more than one version of
@@ -1461,105 +674,4 @@
             </para>
         </section>
     </section>
-
-<!--
-        <section id='toaster-gui-vids-1'>
-            <title>Toaster Homepage and Table Controls</title>
-
-            <para>
-                This video goes over the Toaster entry page, and provides
-                an overview of the data manipulation capabilities of Toaster,
-                which include search, sorting and filtering by different
-                criteria.
-                <mediaobject>
-                    <videoobject>
-                        <videodata width="640" height="480" fileref="http://www.youtube.com/v/QEARDnrR1Xw"></videodata>
-                    </videoobject>
-                </mediaobject>
-            </para>
-        </section>
-
-        <section id='toaster-gui-vids-2'>
-            <title>Build Dashboard</title>
-
-            <para>
-                This video shows you the build dashboard, a page providing an
-                overview of the information available for a selected build.
-                <mediaobject>
-                    <videoobject>
-                        <videodata width="640px" height="480px" fileref="http://www.youtube.com/v/KKqHYcnp2gE"></videodata>
-                    </videoobject>
-                </mediaobject>
-            </para>
-        </section>
-
-        <section id='toaster-gui-vids-3'>
-            <title>Image Information</title>
-
-            <para>
-                This video walks through the information Toaster provides
-                about images: packages installed and root file system.
-                <mediaobject>
-                    <videoobject>
-                        <videodata width="640px" height="480px" fileref="http://www.youtube.com/v/XqYGFsmA0Rw"></videodata>
-                    </videoobject>
-                </mediaobject>
-            </para>
-        </section>
-
-        <section id='toaster-gui-vids-4'>
-            <title>Configuration</title>
-
-            <para>
-                This video shows the information Toaster provides about build
-                configuration.
-                <mediaobject>
-                    <videoobject>
-                        <videodata width="640px" height="480px" fileref="http://www.youtube.com/v/UW-j-T2TzIg"></videodata>
-                    </videoobject>
-                </mediaobject>
-            </para>
-        </section>
-
-        <section id='toaster-gui-vids-5'>
-            <title>Tasks</title>
-
-            <para>
-                This video shows the information Toaster provides about the
-                tasks run by the build system.
-                <mediaobject>
-                    <videoobject>
-                        <videodata width="640px" height="480px" fileref="http://www.youtube.com/v/D4-9vGSxQtw"></videodata>
-                    </videoobject>
-                </mediaobject>
-            </para>
-        </section>
-
-        <section id='toaster-gui-vids-6'>
-            <title>Recipes and Packages Built</title>
-
-            <para>
-                This video shows the information Toaster provides about recipes
-                and packages built.
-                <mediaobject>
-                    <videoobject>
-                        <videodata width="640px" height="480px" fileref="http://www.youtube.com/v/x-6dx4huNnw"></videodata>
-                    </videoobject>
-                </mediaobject>qYgDZ8YzV6w
-            </para>
-        </section>
-        <section id='toaster-gui-vids-7'>
-            <title>Performance Data</title>
-
-            <para>
-                This video shows the build performance data provided by
-                Toaster.
-                <mediaobject>
-                    <videoobject>
-                        <videodata width="640px" height="480px" fileref="http://www.youtube.com/v/qWGMrJoqusQ"></videodata>
-                    </videoobject>
-                </mediaobject>
-            </para>
-        </section>
--->
 </chapter>

yocto-poky/documentation/toaster-manual/toaster-manual.xml

diff --git a/yocto-poky/documentation/toaster-manual/toaster-manual.xml b/yocto-poky/documentation/toaster-manual/toaster-manual.xml
index 59dca8f..7a8912a 100644
--- a/yocto-poky/documentation/toaster-manual/toaster-manual.xml
+++ b/yocto-poky/documentation/toaster-manual/toaster-manual.xml
@@ -41,6 +41,11 @@
                 <date>October 2015</date>
                 <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>April 2016</date>
+                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>

yocto-poky/documentation/tools/mega-manual.sed

diff --git a/yocto-poky/documentation/tools/mega-manual.sed b/yocto-poky/documentation/tools/mega-manual.sed
index 088a99b..5a3bdf9 100644
--- a/yocto-poky/documentation/tools/mega-manual.sed
+++ b/yocto-poky/documentation/tools/mega-manual.sed
@@ -2,32 +2,32 @@
 # This style is for manual folders like "yocto-project-qs" and "poky-ref-manual".
 # This is the old way that did it.  Can't do that now that we have "bitbake-user-manual" strings
 # in the mega-manual.
-# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/poky-ref-manual\/poky-ref-manual.html#/\"link\" href=\"#/g
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/poky-ref-manual\/poky-ref-manual.html#/\"link\" href=\"#/g
 
 # Processes all other manuals (<word>-<word> style) except for the BitBake User Manual because
 # it is not included in the mega-manual.
 # This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual").
 # This was the one-liner that worked before we introduced the BitBake User Manual, which is
 # not in the mega-manual.
-# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
 
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/adt-manual\/adt-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/toaster-manual\/toaster-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/sdk-manual\/sdk-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/toaster-manual\/toaster-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
 
 # Process cases where just an external manual is referenced without an id anchor
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/kernel-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/toaster-manual\/toaster-manual.html\" target=\"_top\">Toaster User Manual<\/a>/Toaster User Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/sdk-manual\/sdk-manual.html\" target=\"_top\">Yocto Project Software Development Kit (SDK) Developer's Guide<\/a>/Yocto Project Software Development Kit (SDK) Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/kernel-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.1\/toaster-manual\/toaster-manual.html\" target=\"_top\">Toaster User Manual<\/a>/Toaster User Manual/g

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

diff --git a/yocto-poky/documentation/yocto-project-qs/yocto-project-qs.xml b/yocto-poky/documentation/yocto-project-qs/yocto-project-qs.xml
index 5315dfe..c09e971 100644
--- a/yocto-poky/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/yocto-poky/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -60,7 +60,7 @@
         </para>
 
         <para>
-            This quick start is written so that you can quickly get a host
+            This quick start is written so that you can quickly get a
             build host set up to use the Yocto Project and then build some
             Linux images.
             Rather than go into great detail about the Yocto Project and its
@@ -71,7 +71,7 @@
             basic understanding of what the Yocto Project is and how to use
             some of its core components.
             You will also have worked through steps to produce two images:
-            one suitable for emulation and one that can be used on actual
+            one that is suitable for emulation and one that boots on actual
             hardware.
             The examples highlight the ease with which you can use the
             Yocto Project to create images for multiple types of hardware.
@@ -249,7 +249,7 @@
                 Git, tar, and Python.
                 <itemizedlist>
                     <listitem><para>
-                        Git 1.7.8 or greater
+                        Git 1.8.3.1 or greater
                         </para></listitem>
                     <listitem><para>
                         tar 1.24 or greater
@@ -360,7 +360,7 @@
      remote: Total 226790 (delta 165212), reused 225887 (delta 164327)
      Receiving objects: 100% (226790/226790), 100.98 MiB | 263 KiB/s, done.
      Resolving deltas: 100% (165212/165212), done.
-     $ git checkout &DISTRO_NAME;
+     $ git checkout &DISTRO_NAME_NO_CAP;
                 </literallayout>
                 You can also get the Yocto Project Files by downloading
                 Yocto Project releases from the
@@ -381,8 +381,19 @@
 
         <para>
             Now that you have your system requirements in order, you can give
-            the Yocto Project a try.
-            This section presents steps that let you do the following:
+            Yocto Project a try.
+            You can try out Yocto Project using either the command-line
+            interface or using Toaster, which uses a graphical user
+            interface.
+            If you want to try out the Yocto Project using a GUI, see the
+            <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>
+            for information on how to install and set up Toaster.
+        </para>
+
+        <para>
+            You can try out the Yocto Project using the command-line interface
+            by finishing this quick start, which presents steps that let you
+            do the following:
             <itemizedlist>
                 <listitem><para>
                     Build a <filename>qemux86</filename> reference image
@@ -453,12 +464,12 @@
                     Release:
                     <literallayout class='monospaced'>
      $ cd ~/poky
-     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
                     </literallayout>
                     Git's <filename>checkout</filename> command checks out
                     the current Yocto Project release into a local branch
                     whose name matches the release (i.e.
-                    <filename>&DISTRO_NAME;</filename>).
+                    <filename>&DISTRO_NAME_NO_CAP;</filename>).
                     The local branch tracks the upstream branch of the
                     same name.
                     Creating your own branch based on the released
@@ -539,7 +550,7 @@
                             in the target image.</para>
                             <para>For additional package manager selection
                             information, see the
-                            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'><filename>package*.bbclass</filename></ulink>"
+                            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'><filename>package.bbclass</filename></ulink>"
                             section in the Yocto Project Reference Manual.
                             </para></listitem>
                     </itemizedlist>
@@ -587,7 +598,7 @@
             </orderedlist>
         </para>
 
-        <para>
+        <para id='qs-minnowboard-example'>
             The following steps show how easy it is to set up to build an
             image for a new machine.
             These steps build an image for the MinnowBoard MAX, which is
@@ -610,17 +621,36 @@
                     Building an image for the MinnowBoard MAX requires the
                     <filename>meta-intel</filename> layer.
                     Use the <filename>git clone</filename> command to create
-                    a local copy of the repository:
+                    a local copy of the repository inside your
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                    which is <filename>poky</filename> in this example:
                     <literallayout class='monospaced'>
+     $ cd $HOME/poky
      $ git clone git://git.yoctoproject.org/meta-intel
      Cloning into 'meta-intel'...
-     remote: Counting objects: 10824, done.
-     remote: Compressing objects: 100% (3508/3508), done.
-     remote: Total 10824 (delta 6219), reused 10580 (delta 5975)
-     Receiving objects: 100% (10824/10824), 2.72 MiB | 482.00 KiB/s, done.
-     Resolving deltas: 100% (6219/6219), done.
+     remote: Counting objects: 11988, done.
+     remote: Compressing objects: 100% (3884/3884), done.
+     Receiving objects: 100% (11988/11988), 2.93 MiB | 2.51 MiB/s, done.
+     remote: Total 11988 (delta 6881), reused 11752 (delta 6645)
+     Resolving deltas: 100% (6881/6881), done.
      Checking connectivity... done.
                     </literallayout>
+                    By default when you clone a Git repository, the
+                    "master" branch is checked out.
+                    Before you build your image that uses the
+                    <filename>meta-intel</filename> layer, you must be
+                    sure that both repositories
+                    (<filename>meta-intel</filename> and
+                    <filename>poky</filename>) are using the same releases.
+                    Consequently, you need to checkout out the
+                    "<filename>&DISTRO_NAME_NO_CAP;</filename>" release after
+                    cloning <filename>meta-intel</filename>:
+                    <literallayout class='monospaced'>
+     $ cd $HOME/poky/meta-intel
+     $ git checkout &DISTRO_NAME_NO_CAP;
+     Branch &DISTRO_NAME_NO_CAP; set up to track remote branch &DISTRO_NAME_NO_CAP; from origin.
+     Switched to a new branch '&DISTRO_NAME_NO_CAP;'
+                    </literallayout>
                     </para></listitem>
                 <listitem><para><emphasis>Configure the Build:</emphasis>
                     To configure the build, you edit the
@@ -639,7 +669,8 @@
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
                     variable.
                     <literallayout class='monospaced'>
-     $ bitbake-layers add-layer "$HOME/source/poky/meta-intel"
+     $ cd $HOME/poky/build
+     $ bitbake-layers add-layer "$HOME/poky/meta-intel"
      $ echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf
                     </literallayout>
                     <note><title>Notes</title>
@@ -725,7 +756,7 @@
 
         <para>
             If you completed all the steps in the previous section then
-            congratulations to you!
+            congratulations!
             What now?
         </para>
 
@@ -740,37 +771,42 @@
                     Visiting this site is a good way to familiarize yourself
                     with the overall project.
                     </para></listitem>
-                <listitem><para><emphasis>Explore Development Models:</emphasis>
-                    You can see the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-model'>Common Development Models</ulink>"
-                    section in the Yocto Project Development Manual
-                    to get an overview of the various ways by which
-                    you can use the Yocto Project to develop projects.
+                <listitem><para><emphasis>Look Through the Yocto Project Development Manual:</emphasis>
+                    The
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-intro'>Yocto Project Development Manual</ulink>
+                    is a great place to get a feel for how to use the Yocto
+                    Project.
+                    The manual contains conceptual and procedural information
+                    that covers
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-model'>common development models</ulink>
+                    and introduces
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-newbie'>the Yocto Project open source development environment</ulink>.
+                    The manual also contains several targeted sections that
+                    cover specific
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#extendpoky'>common tasks</ulink>
+                    such as understanding and creating layers, customizing
+                    images, writing new recipes, working with libraries, and
+                    configuring and patching the kernel.
                     </para></listitem>
-                <listitem><para><emphasis>Learn Some Open Source Basics:</emphasis>
-                    If you are new to the open source environment, you might
-                    read the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-newbie'>The Yocto Project Open Source Development Environment</ulink>"
-                    chapter of the Yocto Project Development Manual.
-                    This chapter presents overview material for open source
-                    development in the context of the Yocto Project.
-                    </para></listitem>
-                <listitem><para><emphasis>Learn About Application Development:</emphasis>
-                    If your primary interests lie in developing applications,
-                    you can reference the
-                    <ulink url='&YOCTO_DOCS_ADT_URL;#adt-manual-intro'>Yocto Project Application Developer's Guide</ulink>.
+                <listitem><para><emphasis>Look Through the Yocto Project Software Development Kit (SDK) Developer's Guide:</emphasis>
+                    The
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>
+                    describes how to use both the
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-using-the-standard-sdk'>standard SDK</ulink>
+                    and the
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>extensible SDK</ulink>,
+                    which are used primarily for application development.
+                    This manual also provides an example workflow that uses
+                    the popular <trademark class='trade'>Eclipse</trademark>
+                    development environment.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_SDK_URL;#workflow-using-eclipse'>Workflow using Eclipse™</ulink>"
+                    section.
                     </para></listitem>
                 <listitem><para><emphasis>Learn About Board Support Packages (BSPs):</emphasis>
                     If you want to learn about BSPs, see the
                     <ulink url='&YOCTO_DOCS_BSP_URL;#bsp'>Yocto Project Board Support Packages (BSP) Developer's Guide</ulink>.
                     </para></listitem>
-                <listitem><para><emphasis>Learn About Using Eclipse With the Yocto Project:</emphasis>
-                    If you are an Eclipse user, you can learn about using the
-                    Yocto Project in that development environment by reading
-                    the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#workflow-using-the-adt-and-eclipse'>Workflow Using the ADT and Eclipse™</ulink>"
-                    section in the Yocto Project Development Manual.
-                    </para></listitem>
                 <listitem><para><emphasis>Learn About Toaster:</emphasis>
                     Toaster is a web interface to the Yocto Project's
                     OpenEmbedded build system.
@@ -778,13 +814,30 @@
                     create images, see the
                     <ulink url='&YOCTO_DOCS_TOAST_URL;#toaster-manual-intro'>Toaster User Manual</ulink>.
                     </para></listitem>
-                <listitem><para><emphasis>Explore Yocto Project Common Tasks and Technical Details:</emphasis>
-                    If you are interested in a mix of common tasks that have to
-                    do with project develop using the Yocto Project, see the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#extendpoky'>Common Tasks</ulink>"
-                    section of the Yocto Project Development Manual.
-                    If you want more detail, see the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-manual-intro'>Yocto Project Reference Manual</ulink>.
+                <listitem><para><emphasis>Have Available the Yocto Project Reference Manual</emphasis>
+                    The
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-manual-intro'>Yocto Project Reference Manual</ulink>,
+                    unlike the rest of the Yocto Project manual set, is
+                    comprised of material suited for reference rather than
+                    procedures.
+                    You can get
+                    <ulink url='&YOCTO_DOCS_REF_URL;#usingpoky'>build details</ulink>,
+                    a
+                    <ulink url='&YOCTO_DOCS_REF_URL;#closer-look'>closer look</ulink>
+                    at how the pieces of the Yocto Project development
+                    environment work together, information on various
+                    <ulink url='&YOCTO_DOCS_REF_URL;#technical-details'>technical details</ulink>,
+                    guidance on
+                    <ulink url='&YOCTO_DOCS_REF_URL;#migration'>migrating to a newer Yocto Project release</ulink>,
+                    reference material on the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-structure'>directory structure</ulink>,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes'>classes</ulink>,
+                    and
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks'>tasks</ulink>.
+                    The Yocto Project Reference Manual also contains a fairly
+                    comprehensive
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-variables-glossary'>glossary of variables</ulink>
+                    used within the Yocto Project.
                     </para></listitem>
             </itemizedlist>
         </para>