Documentation: Removing three unwanted files.

(From yocto-docs rev: b9b69da0c1f264388481817e988b5d131a0bb804) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
author: Scott Rifenbark <scott.m.rifenbark@intel.com> 2012-12-12 09:31:39 -0600
committer: Richard Purdie <richard.purdie@linuxfoundation.org> 2013-01-07 14:43:26 +0000
commit: 2855f7e92f656ee1517ef5733b5b6fdcac1cddc8 (patch)
tree: d0eb34fdce79a5a8e63dc5fd4dcfe15437023c77 /documentation/ref-manual
parent: 8753c6b2888cbe64760800cba1e55e4ce53309d2 (diff)
download: ast2050-yocto-poky-2855f7e92f656ee1517ef5733b5b6fdcac1cddc8.zip
ast2050-yocto-poky-2855f7e92f656ee1517ef5733b5b6fdcac1cddc8.tar.gz
3 files changed, 0 insertions, 5283 deletions
diff --git a/documentation/ref-manual/ref-manual.html b/documentation/ref-manual/ref-manual.html
deleted file mode 100644
index d491bd0..0000000
--- a/documentation/ref-manual/ref-manual.html
+++ /dev/null
@@ -1,5283 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><link rel="stylesheet" type="text/css" href="ref-style.css" /><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></head><body><div xml:lang="en" class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="ref-manual"></a></h1></div><div><div class="authorgroup">
-            <div class="author"><h3 class="author"><span class="firstname">Richard</span> <span class="surname">Purdie</span></h3><div class="affiliation">
-                    <span class="orgname">Linux Foundation<br /></span>
-                </div><code class="email">&lt;<a class="email" href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>&gt;</code></div>
-
-        </div></div><div><p class="copyright">Copyright © 2010-2013 Linux Foundation</p></div><div><div class="legalnotice" title="Legal Notice"><a id="idm153280"></a>
-      <p>
-        Permission is granted to copy, distribute and/or modify this document under
-        the terms of the <a class="ulink" href="http://creativecommons.org/licenses/by-sa/2.0/uk/" target="_top">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</a> as published by Creative Commons.
-      </p>
-      <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-          Due to production processes, there could be differences between the Yocto Project
-          documentation bundled in the release tarball and the
-          <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/ref-manual/ref-manual.html" target="_top">Yocto Project Reference Manual</a> on
-          the <a class="ulink" href="http://www.yoctoproject.org" target="_top">Yocto Project</a> website.
-          For the latest version of this manual, see the manual on the website.
-      </div>
-    </div></div><div><div class="revhistory"><table border="1" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="2"><strong>Revision History</strong></th></tr>
-            <tr><td align="left">Revision 4.0+git</td><td align="left">24 November 2010</td></tr><tr><td align="left" colspan="2">Released with the Yocto Project 0.9 Release</td></tr>
-            <tr><td align="left">Revision 1.0</td><td align="left">6 April 2011</td></tr><tr><td align="left" colspan="2">Released with the Yocto Project 1.0 Release.</td></tr>
-            <tr><td align="left">Revision 1.0.1</td><td align="left">23 May 2011</td></tr><tr><td align="left" colspan="2">Released with the Yocto Project 1.0.1 Release.</td></tr>
-            <tr><td align="left">Revision 1.1</td><td align="left">6 October 2011</td></tr><tr><td align="left" colspan="2">Released with the Yocto Project 1.1 Release.</td></tr>
-            <tr><td align="left">Revision 1.2</td><td align="left">April 2012</td></tr><tr><td align="left" colspan="2">Released with the Yocto Project 1.2 Release.</td></tr>
-            <tr><td align="left">Revision 1.3</td><td align="left">October 2012</td></tr><tr><td align="left" colspan="2">Released with the Yocto Project 1.3 Release.</td></tr>
-            <tr><td align="left">Revision 1.4</td><td align="left">Sometime in 2013</td></tr><tr><td align="left" colspan="2">Released with the Yocto Project 1.4 Release.</td></tr>
-        </table></div></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="chapter"><a href="#intro">1. Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#intro-welcome">1.1. Introduction</a></span></dt><dt><span class="section"><a href="#intro-manualoverview">1.2. Documentation Overview</a></span></dt><dt><span class="section"><a href="#intro-requirements">1.3. System Requirements</a></span></dt><dd><dl><dt><span class="section"><a href="#detailed-supported-distros">1.3.1. Supported Linux Distributions</a></span></dt><dt><span class="section"><a href="#required-packages-for-the-host-development-system">1.3.2. Required Packages for the Host Development System</a></span></dt></dl></dd><dt><span class="section"><a href="#intro-getit">1.4. Obtaining the Yocto Project</a></span></dt><dt><span class="section"><a href="#intro-getit-dev">1.5. Development Checkouts</a></span></dt></dl></dd><dt><span class="chapter"><a href="#usingpoky">2. Using the Yocto Project</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-build">2.1. Running a Build</a></span></dt><dd><dl><dt><span class="section"><a href="#build-overview">2.1.1. Build Overview</a></span></dt><dt><span class="section"><a href="#building-an-image-using-gpl-components">2.1.2. Building an Image Using GPL Components</a></span></dt></dl></dd><dt><span class="section"><a href="#usingpoky-install">2.2. Installing and Using the Result</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging">2.3. Debugging Build Failures</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-debugging-taskfailures">2.3.1. Task Failures</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-taskrunning">2.3.2. Running Specific Tasks</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-dependencies">2.3.3. Dependency Graphs</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-bitbake">2.3.4. General BitBake Problems</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-buildfile">2.3.5. Building with No Dependencies</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-variables">2.3.6. Variables</a></span></dt><dt><span class="section"><a href="#recipe-logging-mechanisms">2.3.7. Recipe Logging Mechanisms</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-others">2.3.8. Other Tips</a></span></dt></dl></dd><dt><span class="section"><a href="#maintaining-build-output-quality">2.4. Maintaining Build Output Quality</a></span></dt><dd><dl><dt><span class="section"><a href="#enabling-and-disabling-build-history">2.4.1. Enabling and Disabling Build History</a></span></dt><dt><span class="section"><a href="#understanding-what-the-build-history-contains">2.4.2. Understanding What the Build History Contains</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#technical-details">3. Technical Details</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-components">3.1. Yocto Project Components</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-components-bitbake">3.1.1. BitBake</a></span></dt><dt><span class="section"><a href="#usingpoky-components-metadata">3.1.2. Metadata (Recipes)</a></span></dt><dt><span class="section"><a href="#usingpoky-components-classes">3.1.3. Classes</a></span></dt><dt><span class="section"><a href="#usingpoky-components-configuration">3.1.4. Configuration</a></span></dt></dl></dd><dt><span class="section"><a href="#shared-state-cache">3.2. Shared State Cache</a></span></dt><dd><dl><dt><span class="section"><a href="#overall-architecture">3.2.1. Overall Architecture</a></span></dt><dt><span class="section"><a href="#checksums">3.2.2. Checksums (Signatures)</a></span></dt><dt><span class="section"><a href="#shared-state">3.2.3. Shared State</a></span></dt><dt><span class="section"><a href="#tips-and-tricks">3.2.4. Tips and Tricks</a></span></dt></dl></dd><dt><span class="section"><a href="#x32">3.3. x32</a></span></dt><dd><dl><dt><span class="section"><a href="#support">3.3.1. Support</a></span></dt><dt><span class="section"><a href="#future-development-and-limitations">3.3.2. Future Development and Limitations</a></span></dt><dt><span class="section"><a href="#using-x32-right-now">3.3.3. Using x32 Right Now</a></span></dt></dl></dd><dt><span class="section"><a href="#licenses">3.4. Licenses</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-configuring-LIC_FILES_CHKSUM">3.4.1. Tracking License Changes</a></span></dt><dt><span class="section"><a href="#enabling-commercially-licensed-recipes">3.4.2. Enabling Commercially Licensed Recipes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#migration">4. Migrating to a Newer Yocto Project Release</a></span></dt><dd><dl><dt><span class="section"><a href="#moving-to-the-yocto-project-1.3-release">4.1. Moving to the Yocto Project 1.3 Release</a></span></dt><dd><dl><dt><span class="section"><a href="#1.3-local-configuration">4.1.1. Local Configuration</a></span></dt><dt><span class="section"><a href="#1.3-recipes">4.1.2. Recipes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#ref-structure">5. Source Directory Structure</a></span></dt><dd><dl><dt><span class="section"><a href="#structure-core">5.1. Top level core components</a></span></dt><dd><dl><dt><span class="section"><a href="#structure-core-bitbake">5.1.1. <code class="filename">bitbake/</code></a></span></dt><dt><span class="section"><a href="#structure-core-build">5.1.2. <code class="filename">build/</code></a></span></dt><dt><span class="section"><a href="#handbook">5.1.3. <code class="filename">documentation</code></a></span></dt><dt><span class="section"><a href="#structure-core-meta">5.1.4. <code class="filename">meta/</code></a></span></dt><dt><span class="section"><a href="#structure-core-meta-yocto">5.1.5. <code class="filename">meta-yocto/</code></a></span></dt><dt><span class="section"><a href="#structure-core-meta-yocto-bsp">5.1.6. <code class="filename">meta-yocto-bsp/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-hob">5.1.7. <code class="filename">meta-hob/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-skeleton">5.1.8. <code class="filename">meta-skeleton/</code></a></span></dt><dt><span class="section"><a href="#structure-core-scripts">5.1.9. <code class="filename">scripts/</code></a></span></dt><dt><span class="section"><a href="#structure-core-script">5.1.10. <code class="filename">oe-init-build-env</code></a></span></dt><dt><span class="section"><a href="#structure-basic-top-level">5.1.11. <code class="filename">LICENSE, README, and README.hardware</code></a></span></dt></dl></dd><dt><span class="section"><a href="#structure-build">5.2. The Build Directory - <code class="filename">build/</code></a></span></dt><dd><dl><dt><span class="section"><a href="#structure-build-pseudodone">5.2.1. <code class="filename">build/pseudodone</code></a></span></dt><dt><span class="section"><a href="#structure-build-conf-local.conf">5.2.2. <code class="filename">build/conf/local.conf</code></a></span></dt><dt><span class="section"><a href="#structure-build-conf-bblayers.conf">5.2.3. <code class="filename">build/conf/bblayers.conf</code></a></span></dt><dt><span class="section"><a href="#structure-build-conf-sanity_info">5.2.4. <code class="filename">build/conf/sanity_info</code></a></span></dt><dt><span class="section"><a href="#structure-build-downloads">5.2.5. <code class="filename">build/downloads/</code></a></span></dt><dt><span class="section"><a href="#structure-build-sstate-cache">5.2.6. <code class="filename">build/sstate-cache/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp">5.2.7. <code class="filename">build/tmp/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-buildstats">5.2.8. <code class="filename">build/tmp/buildstats/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-cache">5.2.9. <code class="filename">build/tmp/cache/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy">5.2.10. <code class="filename">build/tmp/deploy/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-deb">5.2.11. <code class="filename">build/tmp/deploy/deb/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-rpm">5.2.12. <code class="filename">build/tmp/deploy/rpm/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-licenses">5.2.13. <code class="filename">build/tmp/deploy/licenses/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-images">5.2.14. <code class="filename">build/tmp/deploy/images/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-ipk">5.2.15. <code class="filename">build/tmp/deploy/ipk/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-sysroots">5.2.16. <code class="filename">build/tmp/sysroots/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-stamps">5.2.17. <code class="filename">build/tmp/stamps/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-log">5.2.18. <code class="filename">build/tmp/log/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-pkgdata">5.2.19. <code class="filename">build/tmp/pkgdata/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-work">5.2.20. <code class="filename">build/tmp/work/</code></a></span></dt></dl></dd><dt><span class="section"><a href="#structure-meta">5.3. The Metadata - <code class="filename">meta/</code></a></span></dt><dd><dl><dt><span class="section"><a href="#structure-meta-classes">5.3.1. <code class="filename">meta/classes/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-conf">5.3.2. <code class="filename">meta/conf/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-conf-machine">5.3.3. <code class="filename">meta/conf/machine/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-conf-distro">5.3.4. <code class="filename">meta/conf/distro/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-bsp">5.3.5. <code class="filename">meta/recipes-bsp/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-connectivity">5.3.6. <code class="filename">meta/recipes-connectivity/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-core">5.3.7. <code class="filename">meta/recipes-core/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-devtools">5.3.8. <code class="filename">meta/recipes-devtools/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-extended">5.3.9. <code class="filename">meta/recipes-extended/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-gnome">5.3.10. <code class="filename">meta/recipes-gnome/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-graphics">5.3.11. <code class="filename">meta/recipes-graphics/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-kernel">5.3.12. <code class="filename">meta/recipes-kernel/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-multimedia">5.3.13. <code class="filename">meta/recipes-multimedia/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-qt">5.3.14. <code class="filename">meta/recipes-qt/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-rt">5.3.15. <code class="filename">meta/recipes-rt/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-sato">5.3.16. <code class="filename">meta/recipes-sato/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-support">5.3.17. <code class="filename">meta/recipes-support/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-site">5.3.18. <code class="filename">meta/site/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-txt">5.3.19. <code class="filename">meta/recipes.txt</code></a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#ref-bitbake">6. BitBake</a></span></dt><dd><dl><dt><span class="section"><a href="#ref-bitbake-parsing">6.1. Parsing</a></span></dt><dt><span class="section"><a href="#ref-bitbake-providers">6.2. Preferences and Providers</a></span></dt><dt><span class="section"><a href="#ref-bitbake-dependencies">6.3. Dependencies</a></span></dt><dt><span class="section"><a href="#ref-bitbake-tasklist">6.4. The Task List</a></span></dt><dt><span class="section"><a href="#ref-bitbake-runtask">6.5. Running a Task</a></span></dt><dt><span class="section"><a href="#ref-bitbake-commandline">6.6. BitBake Command Line</a></span></dt><dt><span class="section"><a href="#ref-bitbake-fetchers">6.7. Fetchers</a></span></dt></dl></dd><dt><span class="chapter"><a href="#ref-classes">7. Classes</a></span></dt><dd><dl><dt><span class="section"><a href="#ref-classes-base">7.1. The base class - <code class="filename">base.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-autotools">7.2. Autotooled Packages - <code class="filename">autotools.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-update-alternatives">7.3. Alternatives - <code class="filename">update-alternatives.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-update-rc.d">7.4. Initscripts - <code class="filename">update-rc.d.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-binconfig">7.5. Binary config scripts - <code class="filename">binconfig.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-debian">7.6. Debian renaming - <code class="filename">debian.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-pkgconfig">7.7. Pkg-config - <code class="filename">pkgconfig.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-src-distribute">7.8. Distribution of sources - <code class="filename">src_distribute_local.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-perl">7.9. Perl modules - <code class="filename">cpan.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-distutils">7.10. Python extensions - <code class="filename">distutils.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-devshell">7.11. Developer Shell - <code class="filename">devshell.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-packagegroup">7.12. Package Groups - <code class="filename">packagegroup.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-package">7.13. Packaging - <code class="filename">package*.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-kernel">7.14. Building kernels - <code class="filename">kernel.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-image">7.15. Creating images - <code class="filename">image.bbclass</code> and <code class="filename">rootfs*.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-sanity">7.16. Host System sanity checks - <code class="filename">sanity.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-insane">7.17. Generated output quality assurance checks - <code class="filename">insane.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-siteinfo">7.18. Autotools configuration data cache - <code class="filename">siteinfo.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-useradd">7.19. Adding Users - <code class="filename">useradd.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-externalsrc">7.20. Using External Source - <code class="filename">externalsrc.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-others">7.21. Other Classes</a></span></dt></dl></dd><dt><span class="chapter"><a href="#ref-images">8. Images</a></span></dt><dt><span class="chapter"><a href="#ref-features">9. Reference: Features</a></span></dt><dd><dl><dt><span class="section"><a href="#ref-features-distro">9.1. Distro</a></span></dt><dt><span class="section"><a href="#ref-features-machine">9.2. Machine</a></span></dt><dt><span class="section"><a href="#ref-features-image">9.3. Images</a></span></dt><dt><span class="section"><a href="#ref-features-backfill">9.4. Feature Backfilling</a></span></dt></dl></dd><dt><span class="chapter"><a href="#ref-variables-glos">10. Variables Glossary</a></span></dt><dd><dl><dt><span class="glossary"><a href="#ref-variables-glossary">Glossary</a></span></dt></dl></dd><dt><span class="chapter"><a href="#ref-varlocality">11. Variable Context</a></span></dt><dd><dl><dt><span class="section"><a href="#ref-varlocality-configuration">11.1. Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#ref-varlocality-config-distro">11.1.1. Distribution (Distro)</a></span></dt><dt><span class="section"><a href="#ref-varlocality-config-machine">11.1.2. Machine</a></span></dt><dt><span class="section"><a href="#ref-varlocality-config-local">11.1.3. Local</a></span></dt></dl></dd><dt><span class="section"><a href="#ref-varlocality-recipes">11.2. Recipes</a></span></dt><dd><dl><dt><span class="section"><a href="#ref-varlocality-recipe-required">11.2.1. Required</a></span></dt><dt><span class="section"><a href="#ref-varlocality-recipe-dependencies">11.2.2. Dependencies</a></span></dt><dt><span class="section"><a href="#ref-varlocality-recipe-paths">11.2.3. Paths</a></span></dt><dt><span class="section"><a href="#ref-varlocality-recipe-build">11.2.4. Extra Build Information</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#faq">12. FAQ</a></span></dt><dt><span class="chapter"><a href="#resources">13. Contributing to the Yocto Project</a></span></dt><dd><dl><dt><span class="section"><a href="#resources-intro">13.1. Introduction</a></span></dt><dt><span class="section"><a href="#resources-bugtracker">13.2. Tracking Bugs</a></span></dt><dt><span class="section"><a href="#resources-mailinglist">13.3. Mailing lists</a></span></dt><dt><span class="section"><a href="#resources-irc">13.4. Internet Relay Chat (IRC)</a></span></dt><dt><span class="section"><a href="#resources-links">13.5. Links</a></span></dt><dt><span class="section"><a href="#resources-contributions">13.6. Contributions</a></span></dt></dl></dd></dl></div>
-    
-
-    <div class="chapter" title="Chapter 1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a id="intro"></a>Chapter 1. Introduction</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#intro-welcome">1.1. Introduction</a></span></dt><dt><span class="section"><a href="#intro-manualoverview">1.2. Documentation Overview</a></span></dt><dt><span class="section"><a href="#intro-requirements">1.3. System Requirements</a></span></dt><dd><dl><dt><span class="section"><a href="#detailed-supported-distros">1.3.1. Supported Linux Distributions</a></span></dt><dt><span class="section"><a href="#required-packages-for-the-host-development-system">1.3.2. Required Packages for the Host Development System</a></span></dt></dl></dd><dt><span class="section"><a href="#intro-getit">1.4. Obtaining the Yocto Project</a></span></dt><dt><span class="section"><a href="#intro-getit-dev">1.5. Development Checkouts</a></span></dt></dl></div><div class="section" title="1.1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="intro-welcome"></a>1.1. Introduction</h2></div></div></div><p>
-        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
-        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/yocto-project-qs/yocto-project-qs.html" target="_top">Yocto Project Quick Start</a>.
-        For task-based information using the Yocto Project, see the
-        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html" target="_top">Yocto Project Development Manual</a>.
-        You can also find lots of information on the Yocto Project on the
-        <a class="ulink" href="http://www.yoctoproject.org" target="_top">Yocto Project website</a>.
-    </p></div><div class="section" title="1.2. Documentation Overview"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="intro-manualoverview"></a>1.2. Documentation Overview</h2></div></div></div><p>
-        This reference manual consists of the following:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#usingpoky" title="Chapter 2. Using the Yocto Project">Using the Yocto Project</a>:</em></span> This chapter
-                provides an overview of the components that make up the Yocto Project
-                followed by information about debugging images created in the Yocto Project.
-                </p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#technical-details" title="Chapter 3. Technical Details">Technical Details</a>:</em></span>
-                This chapter describes fundamental Yocto Project components as well as an explanation
-                behind how the Yocto Project uses shared state (sstate) cache to speed build time.
-                </p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#ref-structure" title="Chapter 5. Source Directory Structure">Directory Structure</a>:</em></span>
-                This chapter describes the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">source directory</a> created
-                either by unpacking a released Yocto Project tarball on your host development system,
-                or by cloning the upstream
-                <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#poky" target="_top">Poky</a> Git repository.
-                </p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#ref-bitbake" title="Chapter 6. BitBake">BitBake</a>:</em></span>
-                This chapter provides an overview of the BitBake tool and its role within
-                the Yocto Project.</p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#ref-classes" title="Chapter 7. Classes">Classes</a>:</em></span>
-                This chapter describes the classes used in the Yocto Project.</p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#ref-images" title="Chapter 8. Images">Images</a>:</em></span>
-                This chapter describes the standard images that the Yocto Project supports.
-                </p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#ref-features" title="Chapter 9. Reference: Features">Features</a>:</em></span>
-                This chapter describes mechanisms for creating distribution, machine, and image
-                features during the build process using the OpenEmbedded build system.</p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#ref-variables-glos" title="Chapter 10. Variables Glossary">Variables Glossary</a>:</em></span>
-                This chapter presents most variables used by the OpenEmbedded build system, which
-                using BitBake.
-                Entries describe the function of the variable and how to apply them.
-                </p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#ref-varlocality" title="Chapter 11. Variable Context">Variable Context</a>:</em></span>
-                This chapter provides variable locality or context.</p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#faq" title="Chapter 12. FAQ">FAQ</a>:</em></span>
-                This chapter provides answers for commonly asked questions in the Yocto Project
-                development environment.</p></li><li class="listitem"><p><span class="emphasis"><em>
-                <a class="link" href="#resources" title="Chapter 13. Contributing to the Yocto Project">Contributing to the Yocto Project</a>:</em></span>
-                This chapter provides guidance on how you can contribute back to the Yocto
-                Project.</p></li></ul></div><p>
-    </p></div><div class="section" title="1.3. System Requirements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="intro-requirements"></a>1.3. System Requirements</h2></div></div></div><p>
-        For general Yocto Project system requirements, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/yocto-project-qs/yocto-project-qs.html#yp-resources" target="_top">What You Need and How You Get It</a>" section
-        in the Yocto Project Quick Start.
-        The remainder of this section provides details on system requirements
-        not covered in the Yocto Project Quick Start.
-    </p><div class="section" title="1.3.1. Supported Linux Distributions"><div class="titlepage"><div><div><h3 class="title"><a id="detailed-supported-distros"></a>1.3.1. Supported Linux Distributions</h3></div></div></div><p>
-            Currently, the Yocto Project is supported on the following distributions:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Ubuntu 10.04.4 LTS</p></li><li class="listitem"><p>Ubuntu 11.10</p></li><li class="listitem"><p>Ubuntu 12.04.1 LTS</p></li><li class="listitem"><p>Ubuntu 12.04.1 LTS</p></li><li class="listitem"><p>Ubuntu 12.10</p></li><li class="listitem"><p>Fedora release 16 (Verne)</p></li><li class="listitem"><p>Fedora release 17 (Beefy Miracle)</p></li><li class="listitem"><p>Fedora release 18 (Spherical Cow)</p></li><li class="listitem"><p>CentOS release 5.6 (Final)</p></li><li class="listitem"><p>CentOS release 5.7 (Final)</p></li><li class="listitem"><p>CentOS release 5.8 (Final)</p></li><li class="listitem"><p>CentOS release 6.3 (Final)</p></li><li class="listitem"><p>Debian GNU/Linux 6.0.6 (squeeze)</p></li><li class="listitem"><p>openSUSE 11.4</p></li><li class="listitem"><p>openSUSE 12.1</p></li><li class="listitem"><p>openSUSE 12.2</p></li></ul></div><p>
-        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-            For additional information on distributions that support the
-            Yocto Project, see the
-            <a class="ulink" href="https://wiki.yoctoproject.org/wiki/Distribution_Support" target="_top">Distribution Support</a> wiki page.
-        </div></div><div class="section" title="1.3.2. Required Packages for the Host Development System"><div class="titlepage"><div><div><h3 class="title"><a id="required-packages-for-the-host-development-system"></a>1.3.2. Required Packages for the Host Development System</h3></div></div></div><p>
-            The list of packages you need on the host development system can
-            be large when covering all build scenarios using the Yocto Project.
-            This section provides required packages by Linux distribution and
-            further categorized by function.
-        </p><div class="section" title="1.3.2.1. Ubuntu"><div class="titlepage"><div><div><h4 class="title"><a id="ubuntu-packages"></a>1.3.2.1. Ubuntu</h4></div></div></div><p>
-                The following list shows the required packages by function
-                given a supported Ubuntu Linux distribution:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Essentials:</em></span>
-                        Packages needed to build an image on a headless
-                        system:
-                        </p><pre class="literallayout">
-     $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \
-     build-essential chrpath
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>Graphical Extras:</em></span>
-                        Packages recommended if the host system has graphics support:
-                        </p><pre class="literallayout">
-     $ sudo apt-get install libsdl1.2-dev xterm
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>Documentation:</em></span>
-                        Packages needed if you are going to build out the
-                        Yocto Project documentation manuals:
-                        </p><pre class="literallayout">
-     $ sudo apt-get install make xsltproc docbook-utils fop
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>ADT Installer Extras:</em></span>
-                        Packages needed if you are going to be using the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/adt-manual/adt-manual.html#using-the-adt-installer" target="_top">Application Development Toolkit (ADT) Installer</a>:
-                        </p><pre class="literallayout">
-     $ sudo apt-get install autoconf automake libtool libglib2.0-dev
-                        </pre></li></ul></div><p>
-            </p></div><div class="section" title="1.3.2.2. Fedora Packages"><div class="titlepage"><div><div><h4 class="title"><a id="fedora-packages"></a>1.3.2.2. Fedora Packages</h4></div></div></div><p>
-                The following list shows the required packages by function
-                given a supported Fedora Linux distribution:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Essentials:</em></span>
-                        Packages needed to build an image for a headless
-                        system:
-                        </p><pre class="literallayout">
-     $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
-     diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \
-     ccache
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>Graphical Extras:</em></span>
-                        Packages recommended if the host system has graphics support:
-                        </p><pre class="literallayout">
-     $ sudo yum install SDL-devel xterm
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>Documentation:</em></span>
-                        Packages needed if you are going to build out the
-                        Yocto Project documentation manuals:
-                        </p><pre class="literallayout">
-     $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
-     docbook-dtds docbook-utils fop libxslt
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>ADT Installer Extras:</em></span>
-                        Packages needed if you are going to be using the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/adt-manual/adt-manual.html#using-the-adt-installer" target="_top">Application Development Toolkit (ADT) Installer</a>:
-                        </p><pre class="literallayout">
-     $ sudo yum install autoconf automake libtool glib2-devel
-                        </pre></li></ul></div><p>
-            </p></div><div class="section" title="1.3.2.3. OpenSUSE Packages"><div class="titlepage"><div><div><h4 class="title"><a id="opensuse-packages"></a>1.3.2.3. OpenSUSE Packages</h4></div></div></div><p>
-                The following list shows the required packages by function
-                given a supported OpenSUSE Linux distribution:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Essentials:</em></span>
-                        Packages needed to build an image for a headless
-                        system:
-                        </p><pre class="literallayout">
-     $ sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \
-     diffstat texinfo python-curses
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>Graphical Extras:</em></span>
-                        Packages recommended if the host system has graphics support:
-                        </p><pre class="literallayout">
-     $ sudo zypper install libSDL-devel xterm
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>Documentation:</em></span>
-                        Packages needed if you are going to build out the
-                        Yocto Project documentation manuals:
-                        </p><pre class="literallayout">
-     $ sudo zypper install make fop xsltproc
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>ADT Installer Extras:</em></span>
-                        Packages needed if you are going to be using the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/adt-manual/adt-manual.html#using-the-adt-installer" target="_top">Application Development Toolkit (ADT) Installer</a>:
-                        </p><pre class="literallayout">
-     $ sudo zypper install autoconf automake libtool glib2-devel
-                        </pre></li></ul></div><p>
-            </p></div><div class="section" title="1.3.2.4. CentOS Packages"><div class="titlepage"><div><div><h4 class="title"><a id="centos-packages"></a>1.3.2.4. CentOS Packages</h4></div></div></div><p>
-                The following list shows the required packages by function
-                given a supported CentOS Linux distribution:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Essentials:</em></span>
-                        Packages needed to build an image for a headless
-                        system:
-                        </p><pre class="literallayout">
-     $ sudo yum -y install gawk make wget tar bzip2 gzip python unzip perl patch \
-     diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>Graphical Extras:</em></span>
-                        Packages recommended if the host system has graphics support:
-                        </p><pre class="literallayout">
-     $ sudo yum -y install SDL-devel xterm
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>Documentation:</em></span>
-                        Packages needed if you are going to build out the
-                        Yocto Project documentation manuals:
-                        </p><pre class="literallayout">
-     $ sudo yum -y install make docbook-style-dsssl docbook-style-xsl \
-     docbook-dtds docbook-utils fop libxslt
-                        </pre></li><li class="listitem"><p><span class="emphasis"><em>ADT Installer Extras:</em></span>
-                        Packages needed if you are going to be using the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/adt-manual/adt-manual.html#using-the-adt-installer" target="_top">Application Development Toolkit (ADT) Installer</a>:
-                        </p><pre class="literallayout">
-     $ sudo yum -y install autoconf automake libtool glib2-devel
-                        </pre></li></ul></div><p>
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>Depending on the CentOS version you are using, other requirements
-                    and dependencies might exist.
-                    For details, you should look at the CentOS sections on the
-                    <a class="ulink" href="https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies" target="_top">Poky/GettingStarted/Dependencies</a>
-                    wiki page.</div><p>
-            </p></div></div></div><div class="section" title="1.4. Obtaining the Yocto Project"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="intro-getit"></a>1.4. Obtaining the Yocto Project</h2></div></div></div><p>
-        The Yocto Project development team makes the Yocto Project available through a number
-        of methods:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Releases:</em></span> Stable, tested releases are available through
-                <a class="ulink" href="http://downloads.yoctoproject.org/releases/yocto/" target="_top">http://downloads.yoctoproject.org/releases/yocto/</a>.</p></li><li class="listitem"><p><span class="emphasis"><em>Nightly Builds:</em></span> These releases are available at
-                <a class="ulink" href="http://autobuilder.yoctoproject.org/nightly" target="_top">http://autobuilder.yoctoproject.org/nightly</a>.
-                These builds include Yocto Project releases, meta-toolchain tarball installation scripts, and
-                experimental builds.</p></li><li class="listitem"><p><span class="emphasis"><em>Yocto Project Website:</em></span> You can find releases
-                of the Yocto Project and supported BSPs at the
-                <a class="ulink" href="http://www.yoctoproject.org" target="_top">Yocto Project website</a>.
-                Along with these downloads, you can find lots of other information at this site.
-                </p></li></ul></div><p>
-    </p></div><div class="section" title="1.5. Development Checkouts"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="intro-getit-dev"></a>1.5. Development Checkouts</h2></div></div></div><p>
-        Development using the Yocto Project requires a local
-        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-        You can set up the source directory by downloading a Yocto Project release tarball and unpacking it,
-        or by cloning a copy of the upstream
-        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#poky" target="_top">Poky</a> Git repository.
-        For information on both these methods, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#getting-setup" target="_top">Getting Setup</a>"
-        section in the Yocto Project Development Manual.
-    </p></div></div>
-
-    <div class="chapter" title="Chapter 2. Using the Yocto Project"><div class="titlepage"><div><div><h2 class="title"><a id="usingpoky"></a>Chapter 2. Using the Yocto Project</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#usingpoky-build">2.1. Running a Build</a></span></dt><dd><dl><dt><span class="section"><a href="#build-overview">2.1.1. Build Overview</a></span></dt><dt><span class="section"><a href="#building-an-image-using-gpl-components">2.1.2. Building an Image Using GPL Components</a></span></dt></dl></dd><dt><span class="section"><a href="#usingpoky-install">2.2. Installing and Using the Result</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging">2.3. Debugging Build Failures</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-debugging-taskfailures">2.3.1. Task Failures</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-taskrunning">2.3.2. Running Specific Tasks</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-dependencies">2.3.3. Dependency Graphs</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-bitbake">2.3.4. General BitBake Problems</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-buildfile">2.3.5. Building with No Dependencies</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-variables">2.3.6. Variables</a></span></dt><dt><span class="section"><a href="#recipe-logging-mechanisms">2.3.7. Recipe Logging Mechanisms</a></span></dt><dt><span class="section"><a href="#usingpoky-debugging-others">2.3.8. Other Tips</a></span></dt></dl></dd><dt><span class="section"><a href="#maintaining-build-output-quality">2.4. Maintaining Build Output Quality</a></span></dt><dd><dl><dt><span class="section"><a href="#enabling-and-disabling-build-history">2.4.1. Enabling and Disabling Build History</a></span></dt><dt><span class="section"><a href="#understanding-what-the-build-history-contains">2.4.2. Understanding What the Build History Contains</a></span></dt></dl></dd></dl></div><p>
-        This chapter describes common usage for the Yocto Project.
-        The information is introductory in nature as other manuals in the Yocto Project
-        documentation set provide more details on how to use the Yocto Project.
-    </p><div class="section" title="2.1. Running a Build"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="usingpoky-build"></a>2.1. Running a Build</h2></div></div></div><p>
-        This section provides a summary of the build process and provides information
-        for less obvious aspects of the build process.
-        For general information on how to build an image using the OpenEmbedded build
-        system, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/yocto-project-qs/yocto-project-qs.html#building-image" target="_top">Building an Image</a>"
-        section of the Yocto Project Quick Start.
-    </p><div class="section" title="2.1.1. Build Overview"><div class="titlepage"><div><div><h3 class="title"><a id="build-overview"></a>2.1.1. Build Overview</h3></div></div></div><p>
-            The first thing you need to do is set up the OpenEmbedded build environment by sourcing
-            the <a class="link" href="#structure-core-script" title="5.1.10. oe-init-build-env">environment setup script</a> as follows:
-            </p><pre class="literallayout">
-     $ source oe-init-build-env [build_dir]
-            </pre><p>
-        </p><p>
-            The <code class="filename">build_dir</code> is optional and specifies the directory the
-            OpenEmbedded build system uses for the build -
-            the <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-            If you do not specify a Build Directory it defaults to <code class="filename">build</code>
-            in your current working directory.
-            A common practice is to use a different Build Directory for different targets.
-            For example, <code class="filename">~/build/x86</code> for a <code class="filename">qemux86</code>
-            target, and <code class="filename">~/build/arm</code> for a <code class="filename">qemuarm</code> target.
-            See <a class="link" href="#structure-core-script" title="5.1.10. oe-init-build-env">oe-init-build-env</a>
-            for more information on this script.
-        </p><p>
-            Once the build environment is set up, you can build a target using:
-            </p><pre class="literallayout">
-     $ bitbake &lt;target&gt;
-            </pre><p>
-        </p><p>
-            The <code class="filename">target</code> is the name of the recipe you want to build.
-            Common targets are the images in <code class="filename">meta/recipes-core/images</code>,
-            <code class="filename">/meta/recipes-sato/images</code>, etc. all found in the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-            Or, the target can be the name of a recipe for a specific piece of software such as
-            <span class="application">busybox</span>.
-            For more details about the images the OpenEmbedded build system supports, see the
-            "<a class="link" href="#ref-images" title="Chapter 8. Images">Images</a>" chapter.
-        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-            Building an image without GNU General Public License Version 3 (GPLv3) components
-            is only supported for minimal and base images.
-            See the "<a class="link" href="#ref-images" title="Chapter 8. Images">Images</a>" chapter for more information.
-        </div></div><div class="section" title="2.1.2. Building an Image Using GPL Components"><div class="titlepage"><div><div><h3 class="title"><a id="building-an-image-using-gpl-components"></a>2.1.2. Building an Image Using GPL Components</h3></div></div></div><p>
-            When building an image using GPL components, you need to maintain your original
-            settings and not switch back and forth applying different versions of the GNU
-            General Public License.
-            If you rebuild using different versions of GPL, dependency errors might occur
-            due to some components not being rebuilt.
-        </p></div></div><div class="section" title="2.2. Installing and Using the Result"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="usingpoky-install"></a>2.2. Installing and Using the Result</h2></div></div></div><p>
-        Once an image has been built, it often needs to be installed.
-        The images and kernels built by the OpenEmbedded build system are placed in the
-        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a> in
-        <code class="filename">tmp/deploy/images</code>.
-        For information on how to run pre-built images such as <code class="filename">qemux86</code>
-        and <code class="filename">qemuarm</code>, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/yocto-project-qs/yocto-project-qs.html#using-pre-built" target="_top">Using Pre-Built Binaries and QEMU</a>"
-        section in the Yocto Project Quick Start.
-        For information about how to install these images, see the documentation for your
-        particular board/machine.
-    </p></div><div class="section" title="2.3. Debugging Build Failures"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="usingpoky-debugging"></a>2.3. Debugging Build Failures</h2></div></div></div><p>
-        The exact method for debugging build failures depends on the nature of the
-        problem and on the system's area from which the bug originates.
-        Standard debugging practices such as comparison against the last
-        known working version with examination of the changes and the re-application of steps
-        to identify the one causing the problem are
-        valid for the Yocto Project just as they are for any other system.
-        Even though it is impossible to detail every possible potential failure,
-        this section provides some general tips to aid in debugging.
-    </p><div class="section" title="2.3.1. Task Failures"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-debugging-taskfailures"></a>2.3.1. Task Failures</h3></div></div></div><p>The log file for shell tasks is available in
-            <code class="filename">${WORKDIR}/temp/log.do_taskname.pid</code>.
-            For example, the <code class="filename">compile</code> task for the QEMU minimal image for the x86
-            machine (<code class="filename">qemux86</code>) might be
-            <code class="filename">tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile.20830</code>.
-            To see what BitBake runs to generate that log, look at the corresponding
-            <code class="filename">run.do_taskname.pid</code> file located in the same directory.
-        </p><p>
-            Presently, the output from Python tasks is sent directly to the console.
-        </p></div><div class="section" title="2.3.2. Running Specific Tasks"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-debugging-taskrunning"></a>2.3.2. Running Specific Tasks</h3></div></div></div><p>
-            Any given package consists of a set of tasks.
-            The standard BitBake behavior in most cases is: <code class="filename">fetch</code>,
-            <code class="filename">unpack</code>,
-            <code class="filename">patch</code>, <code class="filename">configure</code>,
-            <code class="filename">compile</code>, <code class="filename">install</code>, <code class="filename">package</code>,
-            <code class="filename">package_write</code>, and <code class="filename">build</code>.
-            The default task is <code class="filename">build</code> and any tasks on which it depends
-            build first.
-            Some tasks exist, such as <code class="filename">devshell</code>, that are not part of the
-            default build chain.
-            If you wish to run a task that is not part of the default build chain, you can use the
-            <code class="filename">-c</code> option in BitBake as follows:
-            </p><pre class="literallayout">
-     $ bitbake matchbox-desktop -c devshell
-            </pre><p>
-        </p><p>
-            If you wish to rerun a task, use the <code class="filename">-f</code> force option.
-            For example, the following sequence forces recompilation after changing files in the
-            working directory.
-            </p><pre class="literallayout">
-     $ bitbake matchbox-desktop
-               .
-               .
-        [make some changes to the source code in the working directory]
-               .
-               .
-     $ bitbake matchbox-desktop -c compile -f
-     $ bitbake matchbox-desktop
-            </pre><p>
-        </p><p>
-            This sequence first builds <code class="filename">matchbox-desktop</code> and then recompiles it.
-            The last command reruns all tasks (basically the packaging tasks) after the compile.
-            BitBake recognizes that the <code class="filename">compile</code> task was rerun and therefore
-            understands that the other tasks also need to be run again.
-        </p><p>
-            You can view a list of tasks in a given package by running the
-            <code class="filename">listtasks</code> task as follows:
-            </p><pre class="literallayout">
-     $ bitbake matchbox-desktop -c listtasks
-            </pre><p>
-            The results are in the file <code class="filename">${WORKDIR}/temp/log.do_listtasks</code>.
-        </p></div><div class="section" title="2.3.3. Dependency Graphs"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-debugging-dependencies"></a>2.3.3. Dependency Graphs</h3></div></div></div><p>
-            Sometimes it can be hard to see why BitBake wants to build some other packages before a given
-            package you have specified.
-            The <code class="filename">bitbake -g targetname</code> command creates the
-            <code class="filename">depends.dot</code>, <code class="filename">package-depends.dot</code>,
-            and <code class="filename">task-depends.dot</code> files in the current directory.
-            These files show the package and task dependencies and are useful for debugging problems.
-            You can use the <code class="filename">bitbake -g -u depexp targetname</code> command to
-            display the results in a more human-readable form.
-        </p></div><div class="section" title="2.3.4. General BitBake Problems"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-debugging-bitbake"></a>2.3.4. General BitBake Problems</h3></div></div></div><p>
-            You can see debug output from BitBake by using the <code class="filename">-D</code> option.
-            The debug output gives more information about what BitBake
-            is doing and the reason behind it.
-            Each <code class="filename">-D</code> option you use increases the logging level.
-            The most common usage is <code class="filename">-DDD</code>.
-        </p><p>
-            The output from <code class="filename">bitbake -DDD -v targetname</code> can reveal why
-            BitBake chose a certain version of a package or why BitBake
-            picked a certain provider.
-            This command could also help you in a situation where you think BitBake did something
-            unexpected.
-        </p></div><div class="section" title="2.3.5. Building with No Dependencies"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-debugging-buildfile"></a>2.3.5. Building with No Dependencies</h3></div></div></div><p>
-            If you really want to build a specific <code class="filename">.bb</code> file, you can use
-            the command form <code class="filename">bitbake -b &lt;somepath/somefile.bb&gt;</code>.
-            This command form does not check for dependencies so you should use it
-            only when you know its dependencies already exist.
-            You can also specify fragments of the filename.
-            In this case, BitBake checks for a unique match.
-        </p></div><div class="section" title="2.3.6. Variables"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-debugging-variables"></a>2.3.6. Variables</h3></div></div></div><p>
-            The <code class="filename">-e</code> option dumps the resulting environment for
-            either the configuration (no package specified) or for a
-            specific package when specified; or <code class="filename">-b recipename</code>
-            to show the environment from parsing a single recipe file only.
-        </p></div><div class="section" title="2.3.7. Recipe Logging Mechanisms"><div class="titlepage"><div><div><h3 class="title"><a id="recipe-logging-mechanisms"></a>2.3.7. Recipe Logging Mechanisms</h3></div></div></div><p>
-            Best practices exist while writing recipes that both log build progress and
-            act on build conditions such as warnings and errors.
-            Both Python and Bash language bindings exist for the logging mechanism:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Python:</em></span> For Python functions, BitBake
-                    supports several loglevels: <code class="filename">bb.fatal</code>,
-                    <code class="filename">bb.error</code>, <code class="filename">bb.warn</code>,
-                    <code class="filename">bb.note</code>, <code class="filename">bb.plain</code>,
-                    and <code class="filename">bb.debug</code>.</p></li><li class="listitem"><p><span class="emphasis"><em>Bash:</em></span> For Bash functions, the same set
-                    of loglevels exist and are accessed with a similar syntax:
-                    <code class="filename">bbfatal</code>, <code class="filename">bberror</code>,
-                    <code class="filename">bbwarn</code>, <code class="filename">bbnote</code>,
-                    <code class="filename">bbplain</code>, and <code class="filename">bbdebug</code>.</p></li></ul></div><p>
-        </p><p>
-            For guidance on how logging is handled in both Python and Bash recipes, see the
-            <code class="filename">logging.bbclass</code> file in the
-            <code class="filename">meta/classes</code> folder of the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-        </p><div class="section" title="2.3.7.1. Logging With Python"><div class="titlepage"><div><div><h4 class="title"><a id="logging-with-python"></a>2.3.7.1. Logging With Python</h4></div></div></div><p>
-                When creating recipes using Python and inserting code that handles build logs
-                keep in mind the goal is to have informative logs while keeping the console as
-                "silent" as possible.
-                Also, if you want status messages in the log use the "debug" loglevel.
-            </p><p>
-                Following is an example written in Python.
-                The code handles logging for a function that determines the number of tasks
-                needed to be run:
-                </p><pre class="literallayout">
-     python do_listtasks() {
-         bb.debug(2, "Starting to figure out the task list")
-         if noteworthy_condition:
-             bb.note("There are 47 tasks to run")
-         bb.debug(2, "Got to point xyz")
-         if warning_trigger:
-             bb.warn("Detected warning_trigger, this might be a problem later.")
-         if recoverable_error:
-             bb.error("Hit recoverable_error, you really need to fix this!")
-         if fatal_error:
-             bb.fatal("fatal_error detected, unable to print the task list")
-         bb.plain("The tasks present are abc")
-         bb.debug(2, "Finished figuring out the tasklist")
-     }
-                </pre><p>
-            </p></div><div class="section" title="2.3.7.2. Logging With Bash"><div class="titlepage"><div><div><h4 class="title"><a id="logging-with-bash"></a>2.3.7.2. Logging With Bash</h4></div></div></div><p>
-                When creating recipes using Bash and inserting code that handles build
-                logs you have the same goals - informative with minimal console output.
-                The syntax you use for recipes written in Bash is similar to that of
-                recipes written in Python described in the previous section.
-            </p><p>
-                Following is an example written in Bash.
-                The code logs the progress of the <code class="filename">do_my_function</code> function.
-                </p><pre class="literallayout">
-     do_my_function() {
-         bbdebug 2 "Running do_my_function"
-         if [ exceptional_condition ]; then
-             bbnote "Hit exceptional_condition"
-         fi
-         bbdebug 2  "Got to point xyz"
-         if [ warning_trigger ]; then
-             bbwarn "Detected warning_trigger, this might cause a problem later."
-         fi
-         if [ recoverable_error ]; then
-             bberror "Hit recoverable_error, correcting"
-         fi
-         if [ fatal_error ]; then
-             bbfatal "fatal_error detected"
-         fi
-         bbdebug 2 "Completed do_my_function"
-     }
-                </pre><p>
-            </p></div></div><div class="section" title="2.3.8. Other Tips"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-debugging-others"></a>2.3.8. Other Tips</h3></div></div></div><p>
-            Here are some other tips that you might find useful:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>When adding new packages, it is worth watching for
-                    undesirable items making their way into compiler command lines.
-                    For example, you do not want references to local system files like
-                    <code class="filename">/usr/lib/</code> or <code class="filename">/usr/include/</code>.
-                    </p></li><li class="listitem"><p>If you want to remove the psplash boot splashscreen,
-                    add <code class="filename">psplash=false</code> to  the kernel command line.
-                    Doing so prevents psplash from loading and thus allows you to see the console.
-                    It is also possible to switch out of the splashscreen by
-                    switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
-                    </p></li></ul></div><p>
-        </p></div></div><div class="section" title="2.4. Maintaining Build Output Quality"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="maintaining-build-output-quality"></a>2.4. Maintaining Build Output Quality</h2></div></div></div><p>
-        A build's quality can be influenced by many things.
-        For example, if you upgrade a recipe to use a new version of an upstream software
-        package or you experiment with some new configuration options, subtle changes
-        can occur that you might not detect until later.
-        Consider the case where your recipe is using a newer version of an upstream package.
-        In this case, a new version of a piece of software might introduce an optional
-        dependency on another library, which is auto-detected.
-        If that library has already been built when the software is building,
-        then the software will link to the built library and that library will be pulled
-        into your image along with the new software even if you did not want the
-        library.
-    </p><p>
-        The <code class="filename">buildhistory</code> class exists to help you maintain
-        the quality of your build output.
-        You can use the class to highlight unexpected and possibly unwanted
-        changes in the build output.
-        When you enable build history it records information about the contents of
-        each package and image and then commits that information to a local Git
-        repository where you can examine the information.
-    </p><p>
-        The remainder of this section describes the following:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>How you can enable and disable
-               build history</p></li><li class="listitem"><p>How to understand what the build history contains
-               </p></li><li class="listitem"><p>How to limit the information used for build history
-               </p></li><li class="listitem"><p>How to examine the build history from both a
-               command-line and web interface</p></li></ul></div><p>
-    </p><div class="section" title="2.4.1. Enabling and Disabling Build History"><div class="titlepage"><div><div><h3 class="title"><a id="enabling-and-disabling-build-history"></a>2.4.1. Enabling and Disabling Build History</h3></div></div></div><p>
-            Build history is disabled by default.
-            To enable it, add the following statements to the end of your
-            <code class="filename">conf/local.conf</code> file found in the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>:
-            </p><pre class="literallayout">
-     INHERIT += "buildhistory"
-     BUILDHISTORY_COMMIT = "1"
-            </pre><p>
-            Enabling build history as previously described
-            causes the build process to collect build
-            output information and commit it to a local
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#git" target="_top">Git</a> repository.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                Enabling build history increases your build times slightly,
-                particularly for images, and increases the amount of disk
-                space used during the build.
-            </div><p>
-        </p><p>
-            You can disable build history by removing the previous statements
-            from your <code class="filename">conf/local.conf</code> file.
-            However, you should realize that enabling and disabling
-            build history in this manner can change the
-            <code class="filename">do_package</code> task checksums, which if you
-            are using the OEBasicHash signature generator (the default
-            for many current distro configurations including
-            <code class="filename">DISTRO = "poky"</code> and
-            <code class="filename">DISTRO = ""</code>) will result in the packaging
-            tasks being re-run during the subsequent build.
-        </p><p>
-            To disable the build history functionality without causing the
-            packaging tasks to be re-run, add just this statement to your
-            <code class="filename">conf/local.conf</code> file:
-            </p><pre class="literallayout">
-     BUILDHISTORY_FEATURES = ""
-            </pre><p>
-        </p></div><div class="section" title="2.4.2. Understanding What the Build History Contains"><div class="titlepage"><div><div><h3 class="title"><a id="understanding-what-the-build-history-contains"></a>2.4.2. Understanding What the Build History Contains</h3></div></div></div><p>
-            Build history information is kept in
-            <a class="link" href="#var-TMPDIR" title="TMPDIR"><code class="filename">$TMPDIR</code></a><code class="filename">/buildhistory</code>
-            in the Build Directory.
-            The following is an example abbreviated listing:
-            </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 360px"><td align="center"><img src="figures/buildhistory.png" align="middle" width="540" /></td></tr></table><p>
-        </p><div class="section" title="2.4.2.1. Build History Package Information"><div class="titlepage"><div><div><h4 class="title"><a id="build-history-package-information"></a>2.4.2.1. Build History Package Information</h4></div></div></div><p>
-                The history for each package contains a text file that has
-                name-value pairs with information about the package.
-                For example, <code class="filename">buildhistory/packages/core2-poky-linux/busybox/busybox/latest</code>
-                contains the following:
-                </p><pre class="literallayout">
-     PV = 1.19.3
-     PR = r3
-     RDEPENDS = update-rc.d eglibc (&gt;= 2.13)
-     RRECOMMENDS = busybox-syslog busybox-udhcpc
-     PKGSIZE = 564701
-     FILES = /usr/bin/* /usr/sbin/* /usr/libexec/* /usr/lib/lib*.so.* \
-        /etc /com /var /bin/* /sbin/* /lib/*.so.* /usr/share/busybox \
-        /usr/lib/busybox/* /usr/share/pixmaps /usr/share/applications \
-        /usr/share/idl /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers
-     FILELIST = /etc/busybox.links /etc/init.d/hwclock.sh /bin/busybox /bin/sh
-                </pre><p>
-                Most of these name-value pairs corresponds to variables used
-                to produce the package.
-                The exceptions are <code class="filename">FILELIST</code>, which is the
-                actual list of files in the package, and
-                <code class="filename">PKGSIZE</code>, which is the total size of files
-                in the package in bytes.
-            </p><p>
-                There is also a file corresponding to the recipe from which the
-                package came (e.g.
-                <code class="filename">buildhistory/packages/core2-poky-linux/busybox/latest</code>):
-                </p><pre class="literallayout">
-     PV = 1.19.3
-     PR = r3
-     DEPENDS = virtual/i586-poky-linux-gcc virtual/i586-poky-linux-compilerlibs \
-        virtual/libc update-rc.d-native
-     PACKAGES = busybox-httpd busybox-udhcpd busybox-udhcpc busybox-syslog \
-        busybox-mdev busybox-dbg busybox busybox-doc busybox-dev \
-        busybox-staticdev busybox-locale
-                </pre><p>
-            </p></div><div class="section" title="2.4.2.2. Build History Image Information"><div class="titlepage"><div><div><h4 class="title"><a id="build-history-image-information"></a>2.4.2.2. Build History Image Information</h4></div></div></div><p>
-                The files produced for each image are as follows:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>build-id:</em></span>
-                        Human-readable information about the build configuration
-                        and metadata source revisions.</p></li><li class="listitem"><p><span class="emphasis"><em>*.dot:</em></span>
-                        Dependency graphs for the image that are
-                        compatible with <code class="filename">graphviz</code>.
-                        </p></li><li class="listitem"><p><span class="emphasis"><em>files-in-image.txt:</em></span>
- 	                    A list of files in the image with permissions,
-                        owner, group, size, and symlink information.
-                        </p></li><li class="listitem"><p><span class="emphasis"><em>image-info.txt:</em></span>
-                        A text file containing name-value pairs with information
-                        about the image.
-                        See the following listing example for more information.
-                        </p></li><li class="listitem"><p><span class="emphasis"><em>installed-package-names.txt:</em></span>
-                        A list of installed packages by name only.</p></li><li class="listitem"><p><span class="emphasis"><em>installed-package-sizes.txt:</em></span>
-                        A list of installed packages ordered by size.
-                        </p></li><li class="listitem"><p><span class="emphasis"><em>installed-packages.txt:</em></span>
-                        A list of installed packages with fuill package
-                        filenames.</p></li></ul></div><p>
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    Installed package information is able to be gathered and
-                    produced even if package management is disabled for the final
-                    image.
-                </div><p>
-            </p><p>
-                Here is an example of <code class="filename">image-info.txt</code>:
-                </p><pre class="literallayout">
-     DISTRO = poky
-     DISTRO_VERSION = 1.1+snapshot-20120207
-     USER_CLASSES = image-mklibs image-prelink
-     IMAGE_CLASSES = image_types
-     IMAGE_FEATURES = debug-tweaks x11-base apps-x11-core \
-        package-management ssh-server-dropbear package-management
-     IMAGE_LINGUAS = en-us en-gb
-     IMAGE_INSTALL = task-core-boot task-base-extended
-     BAD_RECOMMENDATIONS =
-     ROOTFS_POSTPROCESS_COMMAND = buildhistory_get_image_installed ;   rootfs_update_timestamp ;
-     IMAGE_POSTPROCESS_COMMAND = buildhistory_get_imageinfo ;
-     IMAGESIZE = 171816
-                </pre><p>
-                Other than <code class="filename">IMAGESIZE</code>, which is the
-                total size of the files in the image in Kbytes, the
-                name-value pairs are variables that may have influenced the
-                content of the image.
-                This information is often useful when you are trying to determine
-                why a change in the package or file listings has occurred.
-            </p></div><div class="section" title="2.4.2.3. Using Build History to Gather Image Information Only"><div class="titlepage"><div><div><h4 class="title"><a id="using-build-history-to-gather-image-information-only"></a>2.4.2.3. Using Build History to Gather Image Information Only</h4></div></div></div><p>
-                As you can see, build history produces image information,
-                including dependency graphs, so you can see why something
-                was pulled into the image.
-                If you are just interested in this information and not
-                interested in collecting history or any package information,
-                you can enable writing only image information without
-                any history by adding the following
-                to your <code class="filename">conf/local.conf</code> file found in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>:
-                </p><pre class="literallayout">
-     INHERIT += "buildhistory"
-     BUILDHISTORY_COMMIT = "0"
-     BUILDHISTORY_FEATURES = "image"
-                </pre><p>
-            </p></div><div class="section" title="2.4.2.4. Examining Build History Information"><div class="titlepage"><div><div><h4 class="title"><a id="examining-build-history-information"></a>2.4.2.4. Examining Build History Information</h4></div></div></div><p>
-                You can examine build history output from the command line or
-                from a web interface.
-            </p><p>
-                To see any changes that have occurred (assuming you have
-                <code class="filename">BUILDHISTORY_COMMIT = "1"</code>), you can simply
-                use any Git command that allows you to view the history of
-                a repository.
-                Here is one method:
-                </p><pre class="literallayout">
-      $ git log -p
-                </pre><p>
-                You need to realize, however, that this method does show
-                changes that are not significant (e.g. a package's size
-                changing by a few bytes).
-            </p><p>
-                A command-line tool called <code class="filename">buildhistory-diff</code>
-                does exist though that queries the Git repository and prints just
-                the differences that might be significant in human-readable form.
-                Here is an example:
-                </p><pre class="literallayout">
-     $ ~/poky/poky/scripts/buildhistory-diff . HEAD^
-     Changes to images/qemux86_64/eglibc/core-image-minimal (files-in-image.txt):
-        /etc/anotherpkg.conf was added
-        /sbin/anotherpkg was added
-        * (installed-package-names.txt):
-        *   anotherpkg was added
-     Changes to images/qemux86_64/eglibc/core-image-minimal (installed-package-names.txt):
-        anotherpkg was added
-     packages/qemux86_64-poky-linux/v86d: PACKAGES: added "v86d-extras"
-        * PR changed from "r0" to "r1"
-        * PV changed from "0.1.10" to "0.1.12"
-     packages/qemux86_64-poky-linux/v86d/v86d: PKGSIZE changed from 110579 to 144381 (+30%)
-        * PR changed from "r0" to "r1"
-        * PV changed from "0.1.10" to "0.1.12"
-                </pre><p>
-            </p><p>
-                To see changes to the build history using a web interface, follow
-                the instruction in the <code class="filename">README</code> file here.
-                <a class="ulink" href="http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/" target="_top">http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/</a>.
-            </p><p>
-                Here is a sample screenshot of the interface:
-                </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="130%"><tr><td align="center"><img src="figures/buildhistory-web.png" align="middle" height="468" /></td></tr></table><p>
-            </p></div></div></div></div>
-
-    <div class="chapter" title="Chapter 3. Technical Details"><div class="titlepage"><div><div><h2 class="title"><a id="technical-details"></a>Chapter 3. Technical Details</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#usingpoky-components">3.1. Yocto Project Components</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-components-bitbake">3.1.1. BitBake</a></span></dt><dt><span class="section"><a href="#usingpoky-components-metadata">3.1.2. Metadata (Recipes)</a></span></dt><dt><span class="section"><a href="#usingpoky-components-classes">3.1.3. Classes</a></span></dt><dt><span class="section"><a href="#usingpoky-components-configuration">3.1.4. Configuration</a></span></dt></dl></dd><dt><span class="section"><a href="#shared-state-cache">3.2. Shared State Cache</a></span></dt><dd><dl><dt><span class="section"><a href="#overall-architecture">3.2.1. Overall Architecture</a></span></dt><dt><span class="section"><a href="#checksums">3.2.2. Checksums (Signatures)</a></span></dt><dt><span class="section"><a href="#shared-state">3.2.3. Shared State</a></span></dt><dt><span class="section"><a href="#tips-and-tricks">3.2.4. Tips and Tricks</a></span></dt></dl></dd><dt><span class="section"><a href="#x32">3.3. x32</a></span></dt><dd><dl><dt><span class="section"><a href="#support">3.3.1. Support</a></span></dt><dt><span class="section"><a href="#future-development-and-limitations">3.3.2. Future Development and Limitations</a></span></dt><dt><span class="section"><a href="#using-x32-right-now">3.3.3. Using x32 Right Now</a></span></dt></dl></dd><dt><span class="section"><a href="#licenses">3.4. Licenses</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-configuring-LIC_FILES_CHKSUM">3.4.1. Tracking License Changes</a></span></dt><dt><span class="section"><a href="#enabling-commercially-licensed-recipes">3.4.2. Enabling Commercially Licensed Recipes</a></span></dt></dl></dd></dl></div><p>
-        This chapter provides technical details for various parts of the Yocto Project.
-        Currently, topics include Yocto Project components and shared state (sstate) cache.
-    </p><div class="section" title="3.1. Yocto Project Components"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="usingpoky-components"></a>3.1. Yocto Project Components</h2></div></div></div><p>
-        The BitBake task executor together with various types of configuration files form the
-        OpenEmbedded Core.
-        This section overviews the BitBake task executor and the
-        configuration files by describing what they are used for and how they interact.
-    </p><p>
-        BitBake handles the parsing and execution of the data files.
-        The data itself is of various types:
-    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Recipes:</em></span>  Provides details about particular
-            pieces of software</p></li><li class="listitem"><p><span class="emphasis"><em>Class Data:</em></span>  An abstraction of common build
-            information (e.g. how to build a Linux kernel).</p></li><li class="listitem"><p><span class="emphasis"><em>Configuration Data:</em></span>  Defines machine-specific settings,
-            policy decisions, etc.
-            Configuration data acts as the glue to bind everything together.</p></li></ul></div><p>
-        For more information on data, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#yocto-project-terms" target="_top">Yocto Project Terms</a>"
-        section in the Yocto Project Development Manual.
-    </p><p>
-        BitBake knows how to combine multiple data sources together and refers to each data source
-        as a layer.
-        For information on layers, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#understanding-and-creating-layers" target="_top">Understanding and
-        Creating Layers</a>" section of the Yocto Project Development Manual.
-    </p><p>
-        Following are some brief details on these core components.
-        For more detailed information on these components see the
-        "<a class="link" href="#ref-structure" title="Chapter 5. Source Directory Structure">Directory Structure</a>" chapter.
-    </p><div class="section" title="3.1.1. BitBake"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-components-bitbake"></a>3.1.1. BitBake</h3></div></div></div><p>
-            BitBake is the tool at the heart of the OpenEmbedded build system and is responsible
-            for parsing the metadata, generating a list of tasks from it,
-            and then executing those tasks.
-            To see a list of the options BitBake supports, use the following help command:
-            </p><pre class="literallayout">
-     $ bitbake --help
-            </pre><p>
-        </p><p>
-            The most common usage for BitBake is <code class="filename">bitbake &lt;packagename&gt;</code>, where
-            <code class="filename">packagename</code> is the name of the package you want to build
-            (referred to as the "target" in this manual).
-            The target often equates to the first part of a <code class="filename">.bb</code> filename.
-            So, to run the <code class="filename">matchbox-desktop_1.2.3.bb</code> file, you
-            might type the following:
-            </p><pre class="literallayout">
-     $ bitbake matchbox-desktop
-            </pre><p>
-            Several different versions of <code class="filename">matchbox-desktop</code> might exist.
-            BitBake chooses the one selected by the distribution configuration.
-            You can get more details about how BitBake chooses between different
-            target versions and providers in the
-            "<a class="link" href="#ref-bitbake-providers" title="6.2. Preferences and Providers">Preferences and Providers</a>" section.
-        </p><p>
-            BitBake also tries to execute any dependent tasks first.
-            So for example, before building <code class="filename">matchbox-desktop</code>, BitBake
-            would build a cross compiler and <code class="filename">eglibc</code> if they had not already
-            been built.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>This release of the Yocto Project does not support the <code class="filename">glibc</code>
-                GNU version of the Unix standard C library.  By default, the OpenEmbedded build system
-                builds with <code class="filename">eglibc</code>.</div><p>
-        </p><p>
-            A useful BitBake option to consider is the <code class="filename">-k</code> or
-            <code class="filename">--continue</code> option.
-            This option instructs BitBake to try and continue processing the job as much
-            as possible even after encountering an error.
-            When an error occurs, the target that
-            failed and those that depend on it cannot be remade.
-            However, when you use this option other dependencies can still be processed.
-        </p></div><div class="section" title="3.1.2. Metadata (Recipes)"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-components-metadata"></a>3.1.2. Metadata (Recipes)</h3></div></div></div><p>
-            The <code class="filename">.bb</code> files are usually referred to as "recipes."
-            In general, a recipe contains information about a single piece of software.
-            The information includes the location from which to download the source patches
-            (if any are needed), which special configuration options to apply,
-            how to compile the source files, and how to package the compiled output.
-        </p><p>
-            The term "package" can also be used to describe recipes.
-            However, since the same word is used for the packaged output from the OpenEmbedded
-            build system (i.e. <code class="filename">.ipk</code> or <code class="filename">.deb</code> files),
-            this document avoids using the term "package" when referring to recipes.
-        </p></div><div class="section" title="3.1.3. Classes"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-components-classes"></a>3.1.3. Classes</h3></div></div></div><p>
-            Class files (<code class="filename">.bbclass</code>) contain information that is useful to share
-            between metadata files.
-            An example is the Autotools class, which contains
-            common settings for any application that Autotools uses.
-            The "<a class="link" href="#ref-classes" title="Chapter 7. Classes">Classes</a>" chapter provides details
-            about common classes and how to use them.
-        </p></div><div class="section" title="3.1.4. Configuration"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-components-configuration"></a>3.1.4. Configuration</h3></div></div></div><p>
-            The configuration files (<code class="filename">.conf</code>) define various configuration variables
-            that govern the OpenEmbedded build process.
-            These files fall into several areas that define machine configuration options,
-            distribution configuration options, compiler tuning options, general common configuration
-            options and user configuration options (<code class="filename">local.conf</code>, which is found
-            in the <a class="ulink" href="build-directory" target="_top">Build Directory</a>).
-        </p></div></div><div class="section" title="3.2. Shared State Cache"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="shared-state-cache"></a>3.2. Shared State Cache</h2></div></div></div><p>
-        By design, the OpenEmbedded build system builds everything from scratch unless
-        BitBake can determine that parts don't need to be rebuilt.
-        Fundamentally, building from scratch is attractive as it means all parts are
-        built fresh and there is no possibility of stale data causing problems.
-        When developers hit problems, they typically default back to building from scratch
-        so they know the state of things from the start.
-    </p><p>
-        Building an image from scratch is both an advantage and a disadvantage to the process.
-        As mentioned in the previous paragraph, building from scratch ensures that
-        everything is current and starts from a known state.
-        However, building from scratch also takes much longer as it generally means
-        rebuilding things that don't necessarily need rebuilt.
-    </p><p>
-        The Yocto Project implements shared state code that supports incremental builds.
-        The implementation of the shared state code answers the following questions that
-        were fundamental roadblocks within the OpenEmbedded incremental build support system:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">What pieces of the system have changed and what pieces have not changed?</li><li class="listitem">How are changed pieces of software removed and replaced?</li><li class="listitem">How are pre-built components that don't need to be rebuilt from scratch
-                used when they are available?</li></ul></div><p>
-    </p><p>
-        For the first question, the build system detects changes in the "inputs" to a given task by
-        creating a checksum (or signature) of the task's inputs.
-        If the checksum changes, the system assumes the inputs have changed and the task needs to be
-        rerun.
-        For the second question, the shared state (sstate) code tracks which tasks add which output
-        to the build process.
-        This means the output from a given task can be removed, upgraded or otherwise manipulated.
-        The third question is partly addressed by the solution for the second question
-        assuming the build system can fetch the sstate objects from remote locations and
-        install them if they are deemed to be valid.
-    </p><p>
-        The rest of this section goes into detail about the overall incremental build
-        architecture, the checksums (signatures), shared state, and some tips and tricks.
-    </p><div class="section" title="3.2.1. Overall Architecture"><div class="titlepage"><div><div><h3 class="title"><a id="overall-architecture"></a>3.2.1. Overall Architecture</h3></div></div></div><p>
-            When determining what parts of the system need to be built, BitBake
-            uses a per-task basis and does not use a per-recipe basis.
-            You might wonder why using a per-task basis is preferred over a per-recipe basis.
-            To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
-            In this case, <code class="filename">do_install</code> and <code class="filename">do_package</code>
-            output are still valid.
-            However, with a per-recipe approach, the build would not include the
-            <code class="filename">.deb</code> files.
-            Consequently, you would have to invalidate the whole build and rerun it.
-            Rerunning everything is not the best situation.
-            Also in this case, the core must be "taught" much about specific tasks.
-            This methodology does not scale well and does not allow users to easily add new tasks
-            in layers or as external recipes without touching the packaged-staging core.
-        </p></div><div class="section" title="3.2.2. Checksums (Signatures)"><div class="titlepage"><div><div><h3 class="title"><a id="checksums"></a>3.2.2. Checksums (Signatures)</h3></div></div></div><p>
-            The shared state code uses a checksum, which is a unique signature of a task's
-            inputs, to determine if a task needs to be run again.
-            Because it is a change in a task's inputs that triggers a rerun, the process
-            needs to detect all the inputs to a given task.
-            For shell tasks, this turns out to be fairly easy because
-            the build process generates a "run" shell script for each task and
-            it is possible to create a checksum that gives you a good idea of when
-            the task's data changes.
-        </p><p>
-            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 <a class="link" href="#var-WORKDIR" title="WORKDIR"><code class="filename">WORKDIR</code></a>.
-            It does not matter if the working directory changes because it should not
-            affect the output for target packages.
-            Also, the build process has the objective of making native/cross packages relocatable.
-            The checksum therefore needs to exclude <code class="filename">WORKDIR</code>.
-            The simplistic approach for excluding the working directory is to set
-            <code class="filename">WORKDIR</code> to some fixed value and create the checksum
-            for the "run" script.
-        </p><p>
-            Another problem results from the "run" scripts containing functions that
-            might or might not get called.
-            The incremental build solution contains code that figures out dependencies
-            between shell functions.
-            This code is used to prune the "run" scripts down to the minimum set,
-            thereby alleviating this problem and making the "run" scripts much more
-            readable as a bonus.
-        </p><p>
-            So far we have solutions for shell scripts.
-            What about python tasks?
-            The same approach applies even though these tasks are more difficult.
-            The process needs to figure out what variables a python function accesses
-            and what functions it calls.
-            Again, the incremental build solution contains code that first figures out
-            the variable and function dependencies, and then creates a checksum for the data
-            used as the input to the task.
-        </p><p>
-            Like the <code class="filename">WORKDIR</code> case, situations exist where dependencies
-            should be ignored.
-            For these cases, you can instruct the build process to ignore a dependency
-            by using a line like the following:
-            </p><pre class="literallayout">
-     PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
-            </pre><p>
-            This example ensures that the <code class="filename">PACKAGE_ARCHS</code> variable does not
-            depend on the value of <code class="filename">MACHINE</code>, even if it does reference it.
-        </p><p>
-            Equally, there are cases where we need to add dependencies BitBake is not able to find.
-            You can accomplish this by using a line like the following:
-            </p><pre class="literallayout">
-      PACKAGE_ARCHS[vardeps] = "MACHINE"
-            </pre><p>
-            This example explicitly adds the <code class="filename">MACHINE</code> variable as a
-            dependency for <code class="filename">PACKAGE_ARCHS</code>.
-        </p><p>
-            Consider a case with inline python, for example, where BitBake is not
-            able to figure out dependencies.
-            When running in debug mode (i.e. using <code class="filename">-DDD</code>), BitBake
-            produces output when it discovers something for which it cannot figure out
-            dependencies.
-            The Yocto Project team has currently not managed to cover those dependencies
-            in detail and is aware of the need to fix this situation.
-        </p><p>
-            Thus far, this section has limited discussion to the direct inputs into a task.
-            Information based on direct inputs is referred to as the "basehash" in the
-            code.
-            However, there is still the question of a task's indirect inputs - the
-            things that were already built and present in the Build Directory.
-            The checksum (or signature) for a particular task needs to add the hashes
-            of all the tasks on which the particular task depends.
-            Choosing which dependencies to add is a policy decision.
-            However, the effect is to generate a master checksum that combines the basehash
-            and the hashes of the task's dependencies.
-        </p><p>
-            At the code level, there are a variety of ways both the basehash and the
-            dependent task hashes can be influenced.
-            Within the BitBake configuration file, we can give BitBake some extra information
-            to help it construct the basehash.
-            The following statements effectively result in a list of global variable
-            dependency excludes - variables never included in any checksum:
-            </p><pre class="literallayout">
-  BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH"
-  BB_HASHBASE_WHITELIST += "DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS"
-  BB_HASHBASE_WHITELIST += "FILE_DIRNAME HOME LOGNAME SHELL TERM USER"
-  BB_HASHBASE_WHITELIST += "FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
-            </pre><p>
-            The previous example actually excludes
-            <a class="link" href="#var-WORKDIR" title="WORKDIR"><code class="filename">WORKDIR</code></a>
-            since it is actually constructed as a path within
-            <a class="link" href="#var-TMPDIR" title="TMPDIR"><code class="filename">TMPDIR</code></a>, which is on
-            the whitelist.
-        </p><p>
-            The rules for deciding which hashes of dependent tasks to include through
-            dependency chains are more complex and are generally accomplished with a
-            python function.
-            The code in <code class="filename">meta/lib/oe/sstatesig.py</code> shows two examples
-            of this and also illustrates how you can insert your own policy into the system
-            if so desired.
-            This file defines the two basic signature generators <code class="filename">OE-Core</code>
-            uses:  "OEBasic" and "OEBasicHash".
-            By default, there is a dummy "noop" signature handler enabled in BitBake.
-            This means that behavior is unchanged from previous versions.
-            <code class="filename">OE-Core</code> uses the "OEBasic" signature handler by default
-            through this setting in the <code class="filename">bitbake.conf</code> file:
-            </p><pre class="literallayout">
-  BB_SIGNATURE_HANDLER ?= "OEBasic"
-            </pre><p>
-            The "OEBasicHash" <code class="filename">BB_SIGNATURE_HANDLER</code> is the same as the
-            "OEBasic" version but adds the task hash to the stamp files.
-            This results in any metadata change that changes the task hash, automatically
-            causing the task to be run again.
-            This removes the need to bump <a class="link" href="#var-PR" title="PR"><code class="filename">PR</code></a>
-            values and changes to metadata automatically ripple across the build.
-            Currently, this behavior is not the default behavior for <code class="filename">OE-Core</code>
-            but is the default in <code class="filename">poky</code>.
-        </p><p>
-            It is also worth noting that the end result of these signature generators is to
-            make some dependency and hash information available to the build.
-            This information includes:
-            </p><pre class="literallayout">
-  BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
-  BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
-  BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
-  BB_TASKHASH - the hash of the currently running task
-            </pre><p>
-        </p></div><div class="section" title="3.2.3. Shared State"><div class="titlepage"><div><div><h3 class="title"><a id="shared-state"></a>3.2.3. Shared State</h3></div></div></div><p>
-            Checksums and dependencies, as discussed in the previous section, solve half the
-            problem.
-            The other part of the problem is being able to use checksum information during the build
-            and being able to reuse or rebuild specific components.
-        </p><p>
-            The shared state class (<code class="filename">sstate.bbclass</code>)
-            is a relatively generic implementation of how to "capture" a snapshot of a given task.
-            The idea is that the build process does not care about the source of a task's output.
-            Output could be freshly built or it could be downloaded and unpacked from
-            somewhere - the build process doesn't need to worry about its source.
-        </p><p>
-            There are two types of output, one is just about creating a directory
-            in <a class="link" href="#var-WORKDIR" title="WORKDIR"><code class="filename">WORKDIR</code></a>.
-            A good example is the output of either <code class="filename">do_install</code> or
-            <code class="filename">do_package</code>.
-            The other type of output occurs when a set of data is merged into a shared directory
-            tree such as the sysroot.
-        </p><p>
-            The Yocto Project team has tried to keep the details of the implementation hidden in
-            <code class="filename">sstate.bbclass</code>.
-            From a user's perspective, adding shared state wrapping to a task
-            is as simple as this <code class="filename">do_deploy</code> example taken from
-            <code class="filename">do_deploy.bbclass</code>:
-            </p><pre class="literallayout">
-     DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
-     SSTATETASKS += "do_deploy"
-     do_deploy[sstate-name] = "deploy"
-     do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
-     do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
-
-     python do_deploy_setscene () {
-         sstate_setscene(d)
-     }
-     addtask do_deploy_setscene
-            </pre><p>
-            In the example, we add some extra flags to the task, a name field ("deploy"), an
-            input directory where the task sends data, and the output
-            directory where the data from the task should eventually be copied.
-            We also add a <code class="filename">_setscene</code> variant of the task and add the task
-            name to the <code class="filename">SSTATETASKS</code> list.
-        </p><p>
-            If you have a directory whose contents you need to preserve, you can do this with
-            a line like the following:
-            </p><pre class="literallayout">
-     do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
-            </pre><p>
-            This method, as well as the following example, also works for multiple directories.
-            </p><pre class="literallayout">
-     do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
-     do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
-     do_package[sstate-lockfile] = "${PACKAGELOCK}"
-            </pre><p>
-            These methods also include the ability to take a lockfile when manipulating
-            shared state directory structures since some cases are sensitive to file
-            additions or removals.
-        </p><p>
-            Behind the scenes, the shared state code works by looking in
-            <a class="link" href="#var-SSTATE_DIR" title="SSTATE_DIR"><code class="filename">SSTATE_DIR</code></a> and
-            <a class="link" href="#var-SSTATE_MIRRORS" title="SSTATE_MIRRORS"><code class="filename">SSTATE_MIRRORS</code></a>
-            for shared state files.
-            Here is an example:
-            </p><pre class="literallayout">
-     SSTATE_MIRRORS ?= "\
-     file://.* http://someserver.tld/share/sstate/PATH \n \
-     file://.* file:///some/local/dir/sstate/PATH"
-            </pre><p>
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                The shared state directory (<code class="filename">SSTATE_DIR</code>) is
-                organized into two-character subdirectories, where the subdirectory
-                names are based on the first two characters of the hash.
-                If the shared state directory structure for a mirror has the
-                same structure as <code class="filename">SSTATE_DIR</code>, you must
-                specify "PATH" as part of the URI to enable the build system
-                to map to the appropriate subdirectory.
-            </div><p>
-        </p><p>
-            The shared state package validity can be detected just by looking at the
-            filename since the filename contains the task checksum (or signature) as
-            described earlier in this section.
-            If a valid shared state package is found, the build process downloads it
-            and uses it to accelerate the task.
-        </p><p>
-            The build processes uses the <code class="filename">*_setscene</code> tasks
-            for the task acceleration phase.
-            BitBake goes through this phase before the main execution code and tries
-            to accelerate any tasks for which it can find shared state packages.
-            If a shared state package for a task is available, the shared state
-            package is used.
-            This means the task and any tasks on which it is dependent are not
-            executed.
-        </p><p>
-            As a real world example, the aim is when building an IPK-based image,
-            only the <code class="filename">do_package_write_ipk</code> tasks would have their
-            shared state packages fetched and extracted.
-            Since the sysroot is not used, it would never get extracted.
-            This is another reason why a task-based approach is preferred over a
-            recipe-based approach, which would have to install the output from every task.
-        </p></div><div class="section" title="3.2.4. Tips and Tricks"><div class="titlepage"><div><div><h3 class="title"><a id="tips-and-tricks"></a>3.2.4. Tips and Tricks</h3></div></div></div><p>
-            The code in the build system that supports incremental builds is not
-            simple code.
-            This section presents some tips and tricks that help you work around
-            issues related to shared state code.
-        </p><div class="section" title="3.2.4.1. Debugging"><div class="titlepage"><div><div><h4 class="title"><a id="debugging"></a>3.2.4.1. Debugging</h4></div></div></div><p>
-                When things go wrong, debugging needs to be straightforward.
-                Because of this, the Yocto Project team included strong debugging
-                tools:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Whenever a shared state package is written out, so is a
-                        corresponding <code class="filename">.siginfo</code> 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.</p></li><li class="listitem"><p>If BitBake is run with the <code class="filename">--dump-signatures</code>
-                        (or <code class="filename">-S</code>) option, BitBake dumps out
-                        <code class="filename">.siginfo</code> files in
-                        the stamp directory for every task it would have executed instead of
-                        building the specified target package.</p></li><li class="listitem"><p>There is a <code class="filename">bitbake-diffsigs</code> command that
-                        can process these <code class="filename">.siginfo</code> files.
-                        If one file is specified, it will dump out the dependency
-                        information in the file.
-                        If two files are specified, it will compare the two files and dump out
-                        the differences between the two.
-                        This allows the question of "What changed between X and Y?" to be
-                        answered easily.</p></li></ul></div><p>
-            </p></div><div class="section" title="3.2.4.2. Invalidating Shared State"><div class="titlepage"><div><div><h4 class="title"><a id="invalidating-shared-state"></a>3.2.4.2. Invalidating Shared State</h4></div></div></div><p>
-                The shared state code uses checksums and shared state
-                cache to avoid unnecessarily rebuilding tasks.
-                As with all schemes, this one has some drawbacks.
-                It is possible that you could make implicit changes that are not factored
-                into the checksum calculation, but do affect a task's output.
-                A good example is perhaps when a tool changes its output.
-                Let's say that the output of <code class="filename">rpmdeps</code> needed to change.
-                The result of the change should be that all the "package", "package_write_rpm",
-                and "package_deploy-rpm" shared state cache items would become invalid.
-                But, because this is a change that is external to the code and therefore implicit,
-                the associated shared state cache items do not become invalidated.
-                In this case, the build process would use the cached items rather than running the
-                task again.
-                Obviously, these types of implicit changes can cause problems.
-            </p><p>
-                To avoid these problems during the build, you need to understand the effects of any
-                change you make.
-                Note that any changes you make directly to a function automatically are factored into
-                the checksum calculation and thus, will invalidate the associated area of sstate cache.
-                You need to be aware of any implicit changes that are not obvious changes to the
-                code and could affect the output of a given task.
-                Once you are aware of such a change, you can take steps to invalidate the cache
-                and force the task to run.
-                The step to take is as simple as changing a function's comments in the source code.
-                For example, to invalidate package shared state files, change the comment statements
-                of <code class="filename">do_package</code> or the comments of one of the functions it calls.
-                The change is purely cosmetic, but it causes the checksum to be recalculated and
-                forces the task to be run again.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                For an example of a commit that makes a cosmetic change to invalidate
-                a shared state, see this
-                <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54" target="_top">commit</a>.
-            </div></div></div></div><div class="section" title="3.3. x32"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="x32"></a>3.3. x32</h2></div></div></div><p>
-        x32 is a new processor-specific Application Binary Interface (psABI) for x86_64.
-        An ABI defines the calling conventions between functions in a processing environment.
-        The interface determines what registers are used and what the sizes are for various C data types.
-    </p><p>
-        Some processing environments prefer using 32-bit applications even when running
-        on Intel 64-bit platforms.
-        Consider the i386 psABI, which is a very old 32-bit ABI for Intel 64-bit platforms.
-        The i386 psABI does not provide efficient use and access of the Intel 64-bit processor resources,
-        leaving the system underutilized.
-        Now consider the x86_64 psABI.
-        This ABI is newer and uses 64-bits for data sizes and program pointers.
-        The extra bits increase the footprint size of the programs, libraries,
-        and also increases the memory and file system size requirements.
-        Executing under the x32 psABI enables user programs to utilize CPU and system resources
-        more efficiently while keeping the memory footprint of the applications low.
-        Extra bits are used for registers but not for addressing mechanisms.
-    </p><div class="section" title="3.3.1. Support"><div class="titlepage"><div><div><h3 class="title"><a id="support"></a>3.3.1. Support</h3></div></div></div><p>
-            While the x32 psABI specifications are not fully finalized, this Yocto Project
-            release supports current development specifications of x32 psABI.
-            As of this release of the Yocto Project, x32 psABI support exists as follows:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>You can create packages and images in x32 psABI format on x86_64 architecture targets.
-                    </p></li><li class="listitem"><p>You can use the x32 psABI support through the <code class="filename">meta-x32</code>
-                    layer on top of the OE-core/Yocto layer.</p></li><li class="listitem"><p>The toolchain from the <code class="filename">experimental/meta-x32</code> layer
-                    is used for building x32 psABI program binaries.</p></li><li class="listitem"><p>You can successfully build many recipes with the x32 toolchain.</p></li><li class="listitem"><p>You can create and boot <code class="filename">core-image-minimal</code> and
-                    <code class="filename">core-image-sato</code> images.</p></li></ul></div><p>
-        </p></div><div class="section" title="3.3.2. Future Development and Limitations"><div class="titlepage"><div><div><h3 class="title"><a id="future-development-and-limitations"></a>3.3.2. Future Development and Limitations</h3></div></div></div><p>
-            As of this Yocto Project release, the x32 psABI kernel and library interfaces
-            specifications are not finalized.
-        </p><p>
-            Future Plans for the x32 psABI in the Yocto Project include the following:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Enhance and fix the few remaining recipes so they
-                    work with and support x32 toolchains.</p></li><li class="listitem"><p>Enhance RPM Package Manager (RPM) support for x32 binaries.</p></li><li class="listitem"><p>Support larger images.</p></li><li class="listitem"><p>Integrate x32 recipes, toolchain, and kernel changes from
-                    <code class="filename">experimental/meta-x32</code> into OE-core.</p></li></ul></div><p>
-        </p></div><div class="section" title="3.3.3. Using x32 Right Now"><div class="titlepage"><div><div><h3 class="title"><a id="using-x32-right-now"></a>3.3.3. Using x32 Right Now</h3></div></div></div><p>
-            Despite the fact the x32 psABI support is in development state for this release of the
-            Yocto Project, you can follow these steps to use the x32 spABI:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Add the <code class="filename">experimental/meta-x32</code> layer to your local
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                    You can find the <code class="filename">experimental/meta-x32</code> source repository at
-                    <a class="ulink" href="http://git.yoctoproject.org" target="_top">http://git.yoctoproject.org</a>.</p></li><li class="listitem"><p>Edit your <code class="filename">conf/bblayers.conf</code> file so that it includes
-                    the <code class="filename">meta-x32</code>.
-                    Here is an example:
-                    </p><pre class="literallayout">
-     BBLAYERS ?= " \
-        /home/nitin/prj/poky.git/meta \
-        /home/nitin/prj/poky.git/meta-yocto \
-        /home/nitin/prj/poky.git/meta-yocto-bsp \
-        /home/nitin/prj/meta-x32.git \
-        "
-     BBLAYERS_NON_REMOVABLE ?= " \
-        /home/nitin/prj/poky.git/meta \
-        /home/nitin/prj/poky.git/meta-yocto \
-        "
-                    </pre></li><li class="listitem"><p>Enable the x32 psABI tuning file for <code class="filename">x86_64</code>
-                    machines by editing the <code class="filename">conf/local.conf</code> like this:
-                    </p><pre class="literallayout">
-      MACHINE = "qemux86-64"
-      DEFAULTTUNE = "x86-64-x32"
-      baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) \
-         or 'INVALID'), True) or 'lib'}"
-      #MACHINE = "atom-pc"
-      #DEFAULTTUNE = "core2-64-x32"
-                    </pre></li><li class="listitem"><p>As usual, use BitBake to build an image that supports the x32 psABI.
-                    Here is an example:
-                    </p><pre class="literallayout">
-     $ bitake core-image-sato
-                    </pre></li><li class="listitem"><p>As usual, run your image using QEMU:
-                    </p><pre class="literallayout">
-     $ runqemu qemux86-64 core-image-sato
-                    </pre></li></ul></div><p>
-        </p></div></div><div class="section" title="3.4. Licenses"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="licenses"></a>3.4. Licenses</h2></div></div></div><p>
-        This section describes the mechanism by which the OpenEmbedded build system
-        tracks changes to licensing text.
-        The section also describes how to enable commercially licensed recipes,
-        which by default are disabled.
-    </p><p>
-        For information that can help you maintain compliance with various open
-        source licensing during the lifecycle of the product, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle" target="_top">Maintaining Open Source License Compliance During Your Project's Lifecycle</a>" section
-        in the Yocto Project Development Manual.
-    </p><div class="section" title="3.4.1. Tracking License Changes"><div class="titlepage"><div><div><h3 class="title"><a id="usingpoky-configuring-LIC_FILES_CHKSUM"></a>3.4.1. Tracking License Changes</h3></div></div></div><p>
-            The license of an upstream project might change in the future.
-            In order to prevent these changes going unnoticed, the
-            <code class="filename"><a class="link" href="#var-LIC_FILES_CHKSUM" title="LIC_FILES_CHKSUM">LIC_FILES_CHKSUM</a></code>
-            variable tracks changes to the license text. The checksums are validated at the end of the
-            configure step, and if the checksums do not match, the build will fail.
-        </p><div class="section" title="3.4.1.1. Specifying the LIC_FILES_CHKSUM Variable"><div class="titlepage"><div><div><h4 class="title"><a id="usingpoky-specifying-LIC_FILES_CHKSUM"></a>3.4.1.1. Specifying the <code class="filename">LIC_FILES_CHKSUM</code> Variable</h4></div></div></div><p>
-                The <code class="filename">LIC_FILES_CHKSUM</code>
-                variable contains checksums of the license text in the source code for the recipe.
-                Following is an example of how to specify <code class="filename">LIC_FILES_CHKSUM</code>:
-                </p><pre class="literallayout">
-     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
-                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
-                         file://licfile2.txt;endline=50;md5=zzzz \
-                         ..."
-                </pre><p>
-            </p><p>
-                The build system uses the
-                <code class="filename"><a class="link" href="#var-S" title="S">S</a></code> variable as the
-                default directory used when searching files listed in
-                <code class="filename">LIC_FILES_CHKSUM</code>.
-                The previous example employs the default directory.
-            </p><p>
-                You can also use relative paths as shown in the following example:
-                </p><pre class="literallayout">
-     LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
-                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
-     LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
-                </pre><p>
-            </p><p>
-                In this example, the first line locates a file in
-                <code class="filename">${S}/src/ls.c</code>.
-                The second line refers to a file in
-                <code class="filename"><a class="link" href="#var-WORKDIR" title="WORKDIR">WORKDIR</a></code>, which is the parent
-                of <code class="filename"><a class="link" href="#var-S" title="S">S</a></code>.
-            </p><p>
-                Note that this variable is mandatory for all recipes, unless the
-                <code class="filename">LICENSE</code> variable is set to "CLOSED".
-            </p></div><div class="section" title="3.4.1.2. Explanation of Syntax"><div class="titlepage"><div><div><h4 class="title"><a id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax"></a>3.4.1.2. Explanation of Syntax</h4></div></div></div><p>
-                As mentioned in the previous section, the
-                <code class="filename">LIC_FILES_CHKSUM</code> variable lists all the
-                important files that contain the license text for the source code.
-                It is possible to specify a checksum for an entire file, or a specific section of a
-                file (specified by beginning and ending line numbers with the "beginline" and "endline"
-                parameters, respectively).
-                The latter is useful for source files with a license notice header,
-                README documents, and so forth.
-                If you do not use the "beginline" parameter, then it is assumed that the text begins on the
-                first line of the file.
-                Similarly, if you do not use the "endline" parameter, it is assumed that the license text
-                ends with the last line of the file.
-            </p><p>
-                The "md5" parameter stores the md5 checksum of the license text.
-                If the license text changes in any way as compared to this parameter
-                then a mismatch occurs.
-                This mismatch triggers a build failure and notifies the developer.
-                Notification allows the developer to review and address the license text changes.
-                Also note that if a mismatch occurs during the build, the correct md5
-                checksum is placed in the build log and can be easily copied to the recipe.
-            </p><p>
-                There is no limit to how many files you can specify using the
-                <code class="filename">LIC_FILES_CHKSUM</code> variable.
-                Generally, however, every project requires a few specifications for license tracking.
-                Many projects have a "COPYING" file that stores the license information for all the source
-                code files.
-                This practice allows you to just track the "COPYING" file as long as it is kept up to date.
-            </p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3>
-                If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match
-                error and displays the correct "md5" parameter value during the build.
-                The correct parameter is also captured in the build log.
-            </div><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3>
-                If the whole file contains only license text, you do not need to use the "beginline" and
-                "endline" parameters.
-            </div></div></div><div class="section" title="3.4.2. Enabling Commercially Licensed Recipes"><div class="titlepage"><div><div><h3 class="title"><a id="enabling-commercially-licensed-recipes"></a>3.4.2. Enabling Commercially Licensed Recipes</h3></div></div></div><p>
-            By default, the OpenEmbedded build system disables
-            components that have commercial or other special licensing
-            requirements.
-            Such requirements are defined on a
-            recipe-by-recipe basis through the <code class="filename">LICENSE_FLAGS</code> variable
-            definition in the affected recipe.
-            For instance, the
-            <code class="filename">$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code>
-            recipe contains the following statement:
-            </p><pre class="literallayout">
-     LICENSE_FLAGS = "commercial"
-            </pre><p>
-            Here is a slightly more complicated example that contains both an
-            explicit recipe name and version (after variable expansion):
-            </p><pre class="literallayout">
-     LICENSE_FLAGS = "license_${PN}_${PV}"
-            </pre><p>
-	        In order for a component restricted by a <code class="filename">LICENSE_FLAGS</code>
-	        definition to be enabled and included in an image, it
-	        needs to have a matching entry in the global
-	        <code class="filename">LICENSE_FLAGS_WHITELIST</code> variable, which is a variable
-	        typically defined in your <code class="filename">local.conf</code> file.
-            For example, to enable
-	        the <code class="filename">$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code>
-	        package, you could add either the string
-	        "commercial_gst-plugins-ugly" or the more general string
-	        "commercial" to <code class="filename">LICENSE_FLAGS_WHITELIST</code>.
-            See the
-            "<a class="link" href="#license-flag-matching" title="3.4.2.1. License Flag Matching">License Flag Matching</a>" section
-            for a full explanation of how <code class="filename">LICENSE_FLAGS</code> matching works.
-            Here is the example:
-            </p><pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
-            </pre><p>
-	        Likewise, to additionally enable the package built from the recipe containing
-	        <code class="filename">LICENSE_FLAGS = "license_${PN}_${PV}"</code>, and assuming
-	        that the actual recipe name was <code class="filename">emgd_1.10.bb</code>,
-	        the following string would enable that package as well as
-	        the original <code class="filename">gst-plugins-ugly</code> package:
-            </p><pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
-            </pre><p>
-	        As a convenience, you do not need to specify the complete license string
-	        in the whitelist for every package.
-            you can use an abbreviated form, which consists
-	        of just the first portion or portions of the license string before
-	        the initial underscore character or characters.
-            A partial string will match
-	        any license that contains the given string as the first
-	        portion of its license.
-            For example, the following
-	        whitelist string will also match both of the packages
-	        previously mentioned as well as any other packages that have
-	        licenses starting with "commercial" or "license".
-            </p><pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial license"
-            </pre><p>
-        </p><div class="section" title="3.4.2.1. License Flag Matching"><div class="titlepage"><div><div><h4 class="title"><a id="license-flag-matching"></a>3.4.2.1. License Flag Matching</h4></div></div></div><p>
-		        The definition of 'matching' in reference to a
-		        recipe's <code class="filename">LICENSE_FLAGS</code> setting is simple.
-                However, some things exist that you should know about in order to
-                correctly and effectively use it.
-            </p><p>
-                Before a flag
-                defined by a particular recipe is tested against the
-                contents of the <code class="filename">LICENSE_FLAGS_WHITELIST</code> variable, the
-                string <code class="filename">_${PN}</code> (with
-                <a class="link" href="#var-PN" title="PN"><code class="filename">PN</code></a> expanded of course) is
-                appended to the flag, thus automatically making each
-                <code class="filename">LICENSE_FLAGS</code> value recipe-specific.
-                That string is
-                then matched against the whitelist.
-                So if you specify <code class="filename">LICENSE_FLAGS = "commercial"</code> in recipe
-		        "foo" for example, the string <code class="filename">"commercial_foo"</code>
-                would normally be what is specified in the whitelist in order for it to
-                match.
-            </p><p>
-                You can broaden the match by
-                putting any "_"-separated beginning subset of a
-                <code class="filename">LICENSE_FLAGS</code> flag in the whitelist, which will also
-                match.
-                For example, simply specifying "commercial" in
-                the whitelist would match any expanded <code class="filename">LICENSE_FLAGS</code>
-                definition starting with "commercial" such as
-                "commercial_foo" and "commercial_bar", which are the
-                strings that would be automatically generated for
-                hypothetical "foo" and "bar" recipes assuming those
-                recipes had simply specified the following:
-                </p><pre class="literallayout">
-     LICENSE_FLAGS = "commercial"
-                </pre><p>
-            </p><p>
-                Broadening the match allows for a range of specificity for the items
-                in the whitelist, from more general to perfectly
-                specific.
-                So you have the choice of exhaustively
-                enumerating each license flag in the whitelist to
-                allow only those specific recipes into the image, or
-                of using a more general string to pick up anything
-                matching just the first component or components of the specified
-                string.
-            </p><p>
-                This scheme works even if the flag already
-                has <code class="filename">_${PN}</code> appended - the extra <code class="filename">_${PN}</code> is
-                redundant, but does not affect the outcome.
-                For example, a license flag of "commercial_1.2_foo" would
-                turn into "commercial_1.2_foo_foo" and would match
-                both the general "commercial" and the specific
-                "commercial_1.2_foo", as expected.
-                The flag would also match
-                "commercial_1.2_foo_foo" and "commercial_1.2", which
-                does not make much sense regarding use in the whitelist.
-            </p><p>
-                For a versioned string, you could instead specify
-                "commercial_foo_1.2", which would turn into
-                "commercial_foo_1.2_foo".
-                And, as expected, this flag allows
-                you to pick up this package along with
-                anything else "commercial" when you specify "commercial"
-                in the whitelist.
-                Or, the flag allows you to pick up this package along with anything "commercial_foo"
-                regardless of version when you use "commercial_foo" in the whitelist.
-                Finally, you can be completely specific about the package and version and specify
-                "commercial_foo_1.2" package and version.
-            </p></div><div class="section" title="3.4.2.2. Other Variables Related to Commercial Licenses"><div class="titlepage"><div><div><h4 class="title"><a id="other-variables-related-to-commercial-licenses"></a>3.4.2.2. Other Variables Related to Commercial Licenses</h4></div></div></div><p>
-                Other helpful variables related to commercial
-                license handling exist and are defined in the
-                <code class="filename">$HOME/poky/meta/conf/distro/include/default-distrovars.inc</code> file:
-                </p><pre class="literallayout">
-     COMMERCIAL_AUDIO_PLUGINS ?= ""
-     COMMERCIAL_VIDEO_PLUGINS ?= ""
-     COMMERCIAL_QT = ""
-                </pre><p>
-                If you want to enable these components, you can do so by making sure you have
-                the following statements in your <code class="filename">local.conf</code> configuration file:
-                </p><pre class="literallayout">
-     COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
-        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"
-                </pre><p>
-                Of course, you could also create a matching whitelist
-                for those components using the more general "commercial"
-                in the whitelist, but that would also enable all the
-                other packages with <code class="filename">LICENSE_FLAGS</code> containing
-                "commercial", which you may or may not want:
-                </p><pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial"
-                </pre><p>
-            </p><p>
-                Specifying audio and video plug-ins as part of the
-                <code class="filename">COMMERCIAL_AUDIO_PLUGINS</code> and
-                <code class="filename">COMMERCIAL_VIDEO_PLUGINS</code> statements
-                or commercial qt components as part of
-                the <code class="filename">COMMERCIAL_QT</code> statement (along
-                with the enabling <code class="filename">LICENSE_FLAGS_WHITELIST</code>) includes the
-                plug-ins or components into built images, thus adding
-                support for media formats or components.
-            </p></div></div></div></div>
-
-    <div class="chapter" title="Chapter 4. Migrating to a Newer Yocto Project Release"><div class="titlepage"><div><div><h2 class="title"><a id="migration"></a>Chapter 4. Migrating to a Newer Yocto Project Release</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#moving-to-the-yocto-project-1.3-release">4.1. Moving to the Yocto Project 1.3 Release</a></span></dt><dd><dl><dt><span class="section"><a href="#1.3-local-configuration">4.1.1. Local Configuration</a></span></dt><dt><span class="section"><a href="#1.3-recipes">4.1.2. Recipes</a></span></dt></dl></dd></dl></div><p>
-        This chapter provides information you can use to migrate work to a
-        newer Yocto Project release.  You can find the same information in the
-        release notes for a given release.
-    </p><div class="section" title="4.1. Moving to the Yocto Project 1.3 Release"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="moving-to-the-yocto-project-1.3-release"></a>4.1. Moving to the Yocto Project 1.3 Release</h2></div></div></div><p>
-        This section provides migration information for moving to the
-        Yocto Project 1.3 Release.
-    </p><div class="section" title="4.1.1. Local Configuration"><div class="titlepage"><div><div><h3 class="title"><a id="1.3-local-configuration"></a>4.1.1. Local Configuration</h3></div></div></div><p>
-            Differences include changes for
-            <a class="link" href="#var-SSTATE_MIRRORS" title="SSTATE_MIRRORS"><code class="filename">SSTATE_MIRRORS</code></a>
-            and <code class="filename">bblayers.conf</code>.
-        </p><div class="section" title="4.1.1.1. SSTATE_MIRRORS"><div class="titlepage"><div><div><h4 class="title"><a id="migration-1.3-sstate-mirrors"></a>4.1.1.1. SSTATE_MIRRORS</h4></div></div></div><p>
-                The shared state cache (sstate-cache) as pointed to by
-                <a class="link" href="#var-SSTATE_DIR" title="SSTATE_DIR"><code class="filename">SSTATE_DIR</code></a> by default
-                now has two-character subdirectories to prevent there being an issue with too
-                many files in the same directory.
-                Also, native sstate-cache packages 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
-                <a class="link" href="#var-SSTATE_MIRRORS" title="SSTATE_MIRRORS"><code class="filename">SSTATE_MIRRORS</code></a>,
-                you need to append "PATH" to the end of the mirror URL so that
-                the path used by BitBake before the mirror substitution is
-                appended to the path used to access the mirror.
-                Here is an example:
-                </p><pre class="literallayout">
-     SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"
-                </pre><p>
-            </p></div><div class="section" title="4.1.1.2. bblayers.conf"><div class="titlepage"><div><div><h4 class="title"><a id="migration-1.3-bblayers-conf"></a>4.1.1.2. bblayers.conf</h4></div></div></div><p>
-                The <code class="filename">meta-yocto</code> layer has been split into
-                two parts: <code class="filename">meta-yocto</code> and
-                <code class="filename">meta-yocto-bsp</code>, corresponding to the
-                Poky reference distro configuration and the reference
-                hardware Board Support Packages (BSPs), respectively.
-                When running BitBake or Hob for the first time after upgrading,
-                your <code class="filename">conf/bblayers.conf</code> file will be
-                updated to handle this change and you will be asked to
-                re-run/restart for the changes to take effect.
-            </p></div></div><div class="section" title="4.1.2. Recipes"><div class="titlepage"><div><div><h3 class="title"><a id="1.3-recipes"></a>4.1.2. Recipes</h3></div></div></div><p>
-            Differences include changes for the following:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Python function whitespace</p></li><li class="listitem"><p><code class="filename">proto=</code> in <code class="filename">SRC_URI</code></p></li><li class="listitem"><p><code class="filename">nativesdk</code></p></li><li class="listitem"><p>Task recipes</p></li><li class="listitem"><p><code class="filename">IMAGE_FEATURES</code></p></li><li class="listitem"><p>Removed recipes</p></li></ul></div><p>
-        </p><div class="section" title="4.1.2.1. Python Function Whitespace"><div class="titlepage"><div><div><h4 class="title"><a id="migration-1.3-python-function-whitespace"></a>4.1.2.1. Python Function Whitespace</h4></div></div></div><p>
-                All Python functions must now use four spaces for indentation.
-                Previously, an inconsistent mix of spaces and tabs existed,
-                which made extending these functions using
-                <code class="filename">_append</code> or <code class="filename">_prepend</code>
-                complicated given that Python treats whitespace as
-                syntactically significant.
-                If you are defining or extending any Python functions (e.g.
-                <code class="filename">populate_packages</code>, <code class="filename">do_unpack</code>,
-                <code class="filename">do_patch</code> and so forth) in custom recipes
-                or classes, you need to ensure you are using consistent
-                four-space indentation.
-            </p></div><div class="section" title="4.1.2.2. proto= in SRC_URI"><div class="titlepage"><div><div><h4 class="title"><a id="migration-1.3-proto=-in-src-uri"></a>4.1.2.2. proto= in SRC_URI</h4></div></div></div><p>
-                Any use of <code class="filename">proto=</code> in
-                <a class="link" href="#var-SRC_URI" title="SRC_URI"><code class="filename">SRC_URI</code></a>
-                needs to be changed to <code class="filename">protocol=</code>.
-                In particular, this applies to the following URIs:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename">svn://</code></p></li><li class="listitem"><p><code class="filename">bzr://</code></p></li><li class="listitem"><p><code class="filename">hg://</code></p></li><li class="listitem"><p><code class="filename">osc://</code></p></li></ul></div><p>
-                Other URIs were already using <code class="filename">protocol=</code>.
-                This change improves consistency.
-            </p></div><div class="section" title="4.1.2.3. nativesdk"><div class="titlepage"><div><div><h4 class="title"><a id="migration-1.3-nativesdk"></a>4.1.2.3. nativesdk</h4></div></div></div><p>
-                The suffix <code class="filename">nativesdk</code> is now implemented
-                as a prefix, which simplifies a lot of the packaging code for
-                <code class="filename">nativesdk</code> recipes.
-                All custom <code class="filename">nativesdk</code> recipes and any
-                references need to be updated to use
-                <code class="filename">nativesdk-*</code> instead of
-                <code class="filename">*-nativesdk</code>.
-            </p></div><div class="section" title="4.1.2.4. Task Recipes"><div class="titlepage"><div><div><h4 class="title"><a id="migration-1.3-task-recipes"></a>4.1.2.4. Task Recipes</h4></div></div></div><p>
-                "Task" recipes are now known as "Package groups" and have
-                been renamed from <code class="filename">task-*.bb</code> to
-                <code class="filename">packagegroup-*.bb</code>.
-                Existing references to the previous <code class="filename">task-*</code>
-                names should work in most cases as there is an automatic
-                upgrade path for most packages.
-                However, you should update references in your own recipes and
-                configurations as they could be removed in future releases.
-                You should also rename any custom <code class="filename">task-*</code>
-                recipes to <code class="filename">packagegroup-*</code>, and change
-                them to inherit <code class="filename">packagegroup</code> instead of
-                <code class="filename">task</code>, as well as taking the opportunity
-                to remove anything now handled by
-                <code class="filename">packagegroup.bbclass</code>, such as providing
-                <code class="filename">-dev</code> and <code class="filename">-dbg</code>
-                packages, setting
-                <a class="link" href="#var-LIC_FILES_CHKSUM" title="LIC_FILES_CHKSUM"><code class="filename">LIC_FILES_CHKSUM</code></a>,
-                and so forth.
-                See the
-                "<a class="link" href="#ref-classes-packagegroup" title="7.12. Package Groups - packagegroup.bbclass">Package Groups - packagegroup.bbclass</a>"
-                section for further details.
-            </p></div><div class="section" title="4.1.2.5. IMAGE_FEATURES"><div class="titlepage"><div><div><h4 class="title"><a id="migration-1.3-image-features"></a>4.1.2.5. IMAGE_FEATURES</h4></div></div></div><p>
-                Image recipes that previously included "apps-console-core"
-                in <a class="link" href="#var-IMAGE_FEATURES" title="IMAGE_FEATURES"><code class="filename">IMAGE_FEATURES</code></a>
-                should now include "splash" instead to enable the boot-up
-                splash screen.
-                Retaining "apps-console-core" will still include the splash
-                screen generates a warning.
-                The "apps-x11-core" and "apps-x11-games"
-                <code class="filename">IMAGE_FEATURES</code> features have been removed.
-            </p></div><div class="section" title="4.1.2.6. Removed Recipes"><div class="titlepage"><div><div><h4 class="title"><a id="migration-1.3-removed-recipes"></a>4.1.2.6. Removed Recipes</h4></div></div></div><p>
-                The following recipes have been removed.
-                For most of them, it is unlikely that you would have any
-                references to them in your own metadata.
-                However, you should check your metadata against this list to be sure:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><code class="filename">libx11-trim</code></em></span>:
-                        Replaced by <code class="filename">libx11</code>, which has a negligible
-                        size difference with modern Xorg.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">xserver-xorg-lite</code></em></span>:
-                        Use <code class="filename">xserver-xorg</code>, which has a negligible
-                        size difference when DRI and GLX modules are not installed.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">xserver-kdrive</code></em></span>:
-                        Effectively unmaintained for many years.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">mesa-xlib</code></em></span>:
-                        No longer serves any purpose.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">galago</code></em></span>:
-                        Replaced by telepathy.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">gail</code></em></span>:
-                        Functionality was integrated into GTK+ 2.13.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">eggdbus</code></em></span>:
-                        No longer needed.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">gcc-*-intermediate</code></em></span>:
-                        The build has been restructured to avoid the need for
-                        this step.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">libgsmd</code></em></span>:
-                        Unmaintained for many years.
-                        Functionality now provided by
-                        <code class="filename">ofono</code> instead.</p></li><li class="listitem"><p><span class="emphasis"><em>contacts, dates, tasks, eds-tools</em></span>:
-                        Largely unmaintained PIM application suite.
-                        It has been moved to <code class="filename">meta-gnome</code>
-                        in <code class="filename">meta-openembedded</code>.</p></li></ul></div><p>
-                In addition to the previously listed changes, the
-                <code class="filename">meta-demoapps</code> directory has also been removed
-                because the recipes in it were not being maintained and many
-                had become obsolete or broken.
-                Additionally, these recipes were not parsed in the default configuration.
-                Many of these recipes are already provided in an updated and
-                maintained form within OpenEmbedded community layers such as
-                <code class="filename">meta-oe</code> and <code class="filename">meta-gnome</code>.
-                For the remainder, you can now find them in the
-                <code class="filename">meta-extras</code> repository, which is in the
-                Yocto Project source repositories.
-            </p></div></div></div></div>
-
-    <div class="chapter" title="Chapter 5. Source Directory Structure"><div class="titlepage"><div><div><h2 class="title"><a id="ref-structure"></a>Chapter 5. Source Directory Structure</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#structure-core">5.1. Top level core components</a></span></dt><dd><dl><dt><span class="section"><a href="#structure-core-bitbake">5.1.1. <code class="filename">bitbake/</code></a></span></dt><dt><span class="section"><a href="#structure-core-build">5.1.2. <code class="filename">build/</code></a></span></dt><dt><span class="section"><a href="#handbook">5.1.3. <code class="filename">documentation</code></a></span></dt><dt><span class="section"><a href="#structure-core-meta">5.1.4. <code class="filename">meta/</code></a></span></dt><dt><span class="section"><a href="#structure-core-meta-yocto">5.1.5. <code class="filename">meta-yocto/</code></a></span></dt><dt><span class="section"><a href="#structure-core-meta-yocto-bsp">5.1.6. <code class="filename">meta-yocto-bsp/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-hob">5.1.7. <code class="filename">meta-hob/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-skeleton">5.1.8. <code class="filename">meta-skeleton/</code></a></span></dt><dt><span class="section"><a href="#structure-core-scripts">5.1.9. <code class="filename">scripts/</code></a></span></dt><dt><span class="section"><a href="#structure-core-script">5.1.10. <code class="filename">oe-init-build-env</code></a></span></dt><dt><span class="section"><a href="#structure-basic-top-level">5.1.11. <code class="filename">LICENSE, README, and README.hardware</code></a></span></dt></dl></dd><dt><span class="section"><a href="#structure-build">5.2. The Build Directory - <code class="filename">build/</code></a></span></dt><dd><dl><dt><span class="section"><a href="#structure-build-pseudodone">5.2.1. <code class="filename">build/pseudodone</code></a></span></dt><dt><span class="section"><a href="#structure-build-conf-local.conf">5.2.2. <code class="filename">build/conf/local.conf</code></a></span></dt><dt><span class="section"><a href="#structure-build-conf-bblayers.conf">5.2.3. <code class="filename">build/conf/bblayers.conf</code></a></span></dt><dt><span class="section"><a href="#structure-build-conf-sanity_info">5.2.4. <code class="filename">build/conf/sanity_info</code></a></span></dt><dt><span class="section"><a href="#structure-build-downloads">5.2.5. <code class="filename">build/downloads/</code></a></span></dt><dt><span class="section"><a href="#structure-build-sstate-cache">5.2.6. <code class="filename">build/sstate-cache/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp">5.2.7. <code class="filename">build/tmp/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-buildstats">5.2.8. <code class="filename">build/tmp/buildstats/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-cache">5.2.9. <code class="filename">build/tmp/cache/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy">5.2.10. <code class="filename">build/tmp/deploy/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-deb">5.2.11. <code class="filename">build/tmp/deploy/deb/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-rpm">5.2.12. <code class="filename">build/tmp/deploy/rpm/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-licenses">5.2.13. <code class="filename">build/tmp/deploy/licenses/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-images">5.2.14. <code class="filename">build/tmp/deploy/images/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-deploy-ipk">5.2.15. <code class="filename">build/tmp/deploy/ipk/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-sysroots">5.2.16. <code class="filename">build/tmp/sysroots/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-stamps">5.2.17. <code class="filename">build/tmp/stamps/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-log">5.2.18. <code class="filename">build/tmp/log/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-pkgdata">5.2.19. <code class="filename">build/tmp/pkgdata/</code></a></span></dt><dt><span class="section"><a href="#structure-build-tmp-work">5.2.20. <code class="filename">build/tmp/work/</code></a></span></dt></dl></dd><dt><span class="section"><a href="#structure-meta">5.3. The Metadata - <code class="filename">meta/</code></a></span></dt><dd><dl><dt><span class="section"><a href="#structure-meta-classes">5.3.1. <code class="filename">meta/classes/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-conf">5.3.2. <code class="filename">meta/conf/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-conf-machine">5.3.3. <code class="filename">meta/conf/machine/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-conf-distro">5.3.4. <code class="filename">meta/conf/distro/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-bsp">5.3.5. <code class="filename">meta/recipes-bsp/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-connectivity">5.3.6. <code class="filename">meta/recipes-connectivity/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-core">5.3.7. <code class="filename">meta/recipes-core/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-devtools">5.3.8. <code class="filename">meta/recipes-devtools/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-extended">5.3.9. <code class="filename">meta/recipes-extended/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-gnome">5.3.10. <code class="filename">meta/recipes-gnome/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-graphics">5.3.11. <code class="filename">meta/recipes-graphics/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-kernel">5.3.12. <code class="filename">meta/recipes-kernel/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-multimedia">5.3.13. <code class="filename">meta/recipes-multimedia/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-qt">5.3.14. <code class="filename">meta/recipes-qt/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-rt">5.3.15. <code class="filename">meta/recipes-rt/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-sato">5.3.16. <code class="filename">meta/recipes-sato/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-support">5.3.17. <code class="filename">meta/recipes-support/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-site">5.3.18. <code class="filename">meta/site/</code></a></span></dt><dt><span class="section"><a href="#structure-meta-recipes-txt">5.3.19. <code class="filename">meta/recipes.txt</code></a></span></dt></dl></dd></dl></div><p>
-    The <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a> consists of several components.
-    Understanding them and knowing where they are located is key to using the Yocto Project well.
-    This chapter describes the Source Directory and gives information about the various
-    files and directories.
-</p><p>
-    For information on how to establish a local Source Directory on your development system, see the
-    "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#getting-setup" target="_top">Getting Set Up</a>"
-    section in the Yocto Project Development Manual.
-</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-    The OpenEmbedded build system does not support file or directory names that
-    contain spaces.
-    Be sure that the Source Directory you use does not contain these types
-    of names.
-</div><div class="section" title="5.1. Top level core components"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="structure-core"></a>5.1. Top level core components</h2></div></div></div><div class="section" title="5.1.1. bitbake/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-core-bitbake"></a>5.1.1. <code class="filename">bitbake/</code></h3></div></div></div><p>
-            The <a class="ulink" href="source-directory" target="_top">Source Directory</a>
-            includes a copy of BitBake for ease of use.
-            The copy usually matches the current stable BitBake release from the BitBake project.
-            BitBake, a metadata interpreter, reads the Yocto Project metadata and runs the tasks
-            defined by that data.
-            Failures are usually from the metadata and not from BitBake itself.
-            Consequently, most users do not need to worry about BitBake.
-        </p><p>
-            When you run the <code class="filename">bitbake</code> command, the wrapper script in
-            <code class="filename">scripts/</code> is executed to run the main BitBake executable,
-            which resides in the <code class="filename">bitbake/bin/</code> directory.
-            Sourcing the <a class="link" href="#structure-core-script" title="5.1.10. oe-init-build-env">oe-init-build-env</a>
-            script places the <code class="filename">scripts</code> and <code class="filename">bitbake/bin</code>
-            directories (in that order) into the shell's <code class="filename">PATH</code> environment
-            variable.
-        </p><p>
-            For more information on BitBake, see the BitBake documentation
-            inculded in the <code class="filename">bitbake/doc/manual</code> directory of the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-        </p></div><div class="section" title="5.1.2. build/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-core-build"></a>5.1.2. <code class="filename">build/</code></h3></div></div></div><p>
-            This directory contains user configuration files and the output
-            generated by the OpenEmbedded build system in its standard configuration where
-            the source tree is combined with the output.
-            The <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>
-            is created initially when you <code class="filename">source</code>
-            the OpenEmbedded build environment setup script <code class="filename">oe-init-build-env</code>.
-        </p><p>
-            It is also possible to place output and configuration
-            files in a directory separate from the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>
-            by providing a directory name when you <code class="filename">source</code>
-            the setup script.
-            For information on separating output from your local Source Directory files, see <a class="link" href="#structure-core-script" title="5.1.10. oe-init-build-env">oe-init-build-env</a>.
-        </p></div><div class="section" title="5.1.3. documentation"><div class="titlepage"><div><div><h3 class="title"><a id="handbook"></a>5.1.3. <code class="filename">documentation</code></h3></div></div></div><p>
-            This directory holds the source for the Yocto Project documentation
-            as well as templates and tools that allow you to generate PDF and HTML
-            versions of the manuals.
-            Each manual is contained in a sub-folder.
-            For example, the files for this manual reside in
-            <code class="filename">ref-manual</code>.
-        </p></div><div class="section" title="5.1.4. meta/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-core-meta"></a>5.1.4. <code class="filename">meta/</code></h3></div></div></div><p>
-            This directory contains the OpenEmbedded Core metadata.
-            The directory holds recipes, common classes, and machine
-            configuration for emulated targets (qemux86, qemuarm,
-            and so on.)
-        </p></div><div class="section" title="5.1.5. meta-yocto/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-core-meta-yocto"></a>5.1.5. <code class="filename">meta-yocto/</code></h3></div></div></div><p>
-            This directory contains the configuration for the Poky
-            reference distribution.
-        </p></div><div class="section" title="5.1.6. meta-yocto-bsp/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-core-meta-yocto-bsp"></a>5.1.6. <code class="filename">meta-yocto-bsp/</code></h3></div></div></div><p>
-            This directory contains the Yocto Project reference
-            hardware BSPs.
-        </p></div><div class="section" title="5.1.7. meta-hob/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-hob"></a>5.1.7. <code class="filename">meta-hob/</code></h3></div></div></div><p>
-            This directory contains template recipes used by the
-            <a class="ulink" href="http://www.yoctoproject.org/projects/hob" target="_top">Hob</a>
-            build UI.
-        </p></div><div class="section" title="5.1.8. meta-skeleton/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-skeleton"></a>5.1.8. <code class="filename">meta-skeleton/</code></h3></div></div></div><p>
-            This directory contains template recipes for BSP and kernel development.
-        </p></div><div class="section" title="5.1.9. scripts/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-core-scripts"></a>5.1.9. <code class="filename">scripts/</code></h3></div></div></div><p>
-            This directory contains various integration scripts that implement
-            extra functionality in the Yocto Project environment (e.g. QEMU scripts).
-            The <a class="link" href="#structure-core-script" title="5.1.10. oe-init-build-env">oe-init-build-env</a> script appends this
-            directory to the shell's <code class="filename">PATH</code> environment variable.
-        </p><p>
-            The <code class="filename">scripts</code> directory has useful scripts that assist contributing
-            back to the Yocto Project, such as <code class="filename">create_pull_request</code> and
-            <code class="filename">send_pull_request</code>.
-        </p></div><div class="section" title="5.1.10. oe-init-build-env"><div class="titlepage"><div><div><h3 class="title"><a id="structure-core-script"></a>5.1.10. <code class="filename">oe-init-build-env</code></h3></div></div></div><p>
-            This script sets up the OpenEmbedded build environment.
-            Running this script with the <code class="filename">source</code> command in
-            a shell makes changes to <code class="filename">PATH</code> and sets other core BitBake variables based on the
-            current working directory.
-            You need to run this script before running BitBake commands.
-            The script uses other scripts within the <code class="filename">scripts</code> directory to do
-            the bulk of the work.
-        </p><p>
-            By default, running this script without a Build Directory argument creates the
-            <code class="filename">build</code> directory.
-            If you provide a Build Directory argument when you <code class="filename">source</code>
-            the script, you direct OpenEmbedded build system to create a
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a> of your choice.
-            For example, the following command creates a Build Directory named
-            <code class="filename">mybuilds</code> that is outside of the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>:
-            </p><pre class="literallayout">
-     $ source oe-init-build-env ~/mybuilds
-            </pre><p>
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                The OpenEmbedded build system does not support file or directory names that
-                contain spaces.
-                If you attempt to run the <code class="filename">oe-init-build-env</code> script
-                from a Source Directory that contains spaces in either the filenames
-                or directory names, the script returns an error indicating no such
-                file or directory.
-                Be sure to use a Source Directory free of names containing spaces.
-            </div><p>
-        </p></div><div class="section" title="5.1.11. LICENSE, README, and README.hardware"><div class="titlepage"><div><div><h3 class="title"><a id="structure-basic-top-level"></a>5.1.11. <code class="filename">LICENSE, README, and README.hardware</code></h3></div></div></div><p>
-            These files are standard top-level files.
-        </p></div></div><div class="section" title="5.2. The Build Directory - build/"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="structure-build"></a>5.2. The Build Directory - <code class="filename">build/</code></h2></div></div></div><div class="section" title="5.2.1. build/pseudodone"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-pseudodone"></a>5.2.1. <code class="filename">build/pseudodone</code></h3></div></div></div><p>
-            This tag file indicates that the initial pseudo binary was created.
-            The file is built the first time BitBake is invoked.
-        </p></div><div class="section" title="5.2.2. build/conf/local.conf"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-conf-local.conf"></a>5.2.2. <code class="filename">build/conf/local.conf</code></h3></div></div></div><p>
-            This file contains all the local user configuration for your build environment.
-            If there is no <code class="filename">local.conf</code> present, it is created from
-            <code class="filename">local.conf.sample</code>.
-            The <code class="filename">local.conf</code> file contains documentation on the various configuration options.
-            Any variable set here overrides any variable set elsewhere within the environment unless
-            that variable is hard-coded within a file (e.g. by using '=' instead of '?=').
-            Some variables are hard-coded for various reasons but these variables are
-            relatively rare.
-        </p><p>
-            Edit this file to set the <code class="filename"><a class="link" href="#var-MACHINE" title="MACHINE">MACHINE</a></code>
-            for which you want to build, which package types you wish to use
-            (<a class="link" href="#var-PACKAGE_CLASSES" title="PACKAGE_CLASSES"><code class="filename">PACKAGE_CLASSES</code></a>),
-            where you want to downloaded files
-            (<code class="filename"><a class="link" href="#var-DL_DIR" title="DL_DIR">DL_DIR</a></code>),
-            and how you want your host machine to use resources
-            (<a class="link" href="#var-BB_NUMBER_THREADS" title="BB_NUMBER_THREADS"><code class="filename">BB_NUMBER_THREADS</code></a> and
-            <a class="link" href="#var-PARALLEL_MAKE" title="PARALLEL_MAKE"><code class="filename">PARALLEL_MAKE</code></a>).
-        </p></div><div class="section" title="5.2.3. build/conf/bblayers.conf"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-conf-bblayers.conf"></a>5.2.3. <code class="filename">build/conf/bblayers.conf</code></h3></div></div></div><p>
-            This file defines layers, which are directory trees, traversed (or walked) by BitBake.
-            If <code class="filename">bblayers.conf</code>
-            is not present, it is created from <code class="filename">bblayers.conf.sample</code> when
-            you <code class="filename">source</code> the environment setup script.
-        </p><p>
-            The <code class="filename">bblayers.conf</code> file uses the
-            <a class="link" href="#var-BBLAYERS" title="BBLAYERS"><code class="filename">BBLAYERS</code></a> variable to
-            list the layers BitBake tries to find.
-            The file uses the
-            <a class="link" href="#var-BBLAYERS_NON_REMOVABLE" title="BBLAYERS_NON_REMOVABLE"><code class="filename">BBLAYERS_NON_REMOVABLE</code></a>
-            variable to list layers that must not be removed.
-        </p></div><div class="section" title="5.2.4. build/conf/sanity_info"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-conf-sanity_info"></a>5.2.4. <code class="filename">build/conf/sanity_info</code></h3></div></div></div><p>
-            This file is created during the build to indicate the state of the sanity checks.
-        </p></div><div class="section" title="5.2.5. build/downloads/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-downloads"></a>5.2.5. <code class="filename">build/downloads/</code></h3></div></div></div><p>
-            This directory is used for the upstream source tarballs.
-            The directory can be reused by multiple builds or moved to another location.
-            You can control the location of this directory through the
-            <code class="filename"><a class="link" href="#var-DL_DIR" title="DL_DIR">DL_DIR</a></code> variable.
-        </p></div><div class="section" title="5.2.6. build/sstate-cache/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-sstate-cache"></a>5.2.6. <code class="filename">build/sstate-cache/</code></h3></div></div></div><p>
-            This directory is used for the shared state cache.
-            The directory can be reused by multiple builds or moved to another location.
-            You can control the location of this directory through the
-            <code class="filename"><a class="link" href="#var-SSTATE_DIR" title="SSTATE_DIR">SSTATE_DIR</a></code> variable.
-        </p></div><div class="section" title="5.2.7. build/tmp/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp"></a>5.2.7. <code class="filename">build/tmp/</code></h3></div></div></div><p>
-            This directory receives all the OpenEmbedded build system's output.
-            BitBake creates this directory if it does not exist.
-            As a last resort, to clean up a build and start it from scratch (other than the downloads),
-            you can remove everything in the <code class="filename">tmp</code> directory or get rid of the
-            directory completely.
-            If you do, you should also completely remove the <code class="filename">build/sstate-cache</code>
-            directory as well.
-        </p></div><div class="section" title="5.2.8. build/tmp/buildstats/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-buildstats"></a>5.2.8. <code class="filename">build/tmp/buildstats/</code></h3></div></div></div><p>
-            This directory stores the build statistics.
-        </p></div><div class="section" title="5.2.9. build/tmp/cache/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-cache"></a>5.2.9. <code class="filename">build/tmp/cache/</code></h3></div></div></div><p>
-            When BitBake parses the metadata, it creates a cache file of the result that can
-            be used when subsequently running commands.
-            These results are stored here on a per-machine basis.
-        </p></div><div class="section" title="5.2.10. build/tmp/deploy/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-deploy"></a>5.2.10. <code class="filename">build/tmp/deploy/</code></h3></div></div></div><p>
-            This directory contains any 'end result' output from the OpenEmbedded build process.
-        </p></div><div class="section" title="5.2.11. build/tmp/deploy/deb/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-deploy-deb"></a>5.2.11. <code class="filename">build/tmp/deploy/deb/</code></h3></div></div></div><p>
-            This directory receives any <code class="filename">.deb</code> packages produced by
-            the build process.
-            The packages are sorted into feeds for different architecture types.
-        </p></div><div class="section" title="5.2.12. build/tmp/deploy/rpm/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-deploy-rpm"></a>5.2.12. <code class="filename">build/tmp/deploy/rpm/</code></h3></div></div></div><p>
-            This directory receives any <code class="filename">.rpm</code> packages produced by
-            the build process.
-            The packages are sorted into feeds for different architecture types.
-        </p></div><div class="section" title="5.2.13. build/tmp/deploy/licenses/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-deploy-licenses"></a>5.2.13. <code class="filename">build/tmp/deploy/licenses/</code></h3></div></div></div><p>
-            This directory receives package licensing information.
-            For example, the directory contains sub-directories for <code class="filename">bash</code>,
-            <code class="filename">busybox</code>, and <code class="filename">eglibc</code> (among others) that in turn
-            contain appropriate <code class="filename">COPYING</code> license files with other licensing information.
-        </p></div><div class="section" title="5.2.14. build/tmp/deploy/images/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-deploy-images"></a>5.2.14. <code class="filename">build/tmp/deploy/images/</code></h3></div></div></div><p>
-            This directory receives complete filesystem images.
-            If you want to flash the resulting image from a build onto a device, look here for the image.
-        </p><p>
-            Be careful when deleting files in this directory.
-            You can safely delete old images from this directory (e.g.
-            <code class="filename">core-image-*</code>, <code class="filename">hob-image-*</code>,
-            etc.).
-            However, the kernel (<code class="filename">*zImage*</code>, <code class="filename">*uImage*</code>, etc.),
-            bootloader and other supplementary files might be deployed here prior to building an
-            image.
-            Because these files, however, are not directly produced from the image, if you
-            delete them they will not be automatically re-created when you build the image again.
-        </p><p>
-            If you do accidentally delete files here, you will need to force them to be
-            re-created.
-            In order to do that, you will need to know the target that produced them.
-            For example, these commands rebuild and re-create the kernel files:
-            </p><pre class="literallayout">
-     $ bitbake -c clean virtual/kernel
-     $ bitbake virtual/kernel
-            </pre><p>
-        </p></div><div class="section" title="5.2.15. build/tmp/deploy/ipk/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-deploy-ipk"></a>5.2.15. <code class="filename">build/tmp/deploy/ipk/</code></h3></div></div></div><p>
-            This directory receives <code class="filename">.ipk</code> packages produced by
-            the build process.</p></div><div class="section" title="5.2.16. build/tmp/sysroots/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-sysroots"></a>5.2.16. <code class="filename">build/tmp/sysroots/</code></h3></div></div></div><p>
-            This directory contains shared header files and libraries as well as other shared
-            data.
-            Packages that need to share output with other packages do so within this directory.
-            The directory is subdivided by architecture so multiple builds can run within
-            the one Build Directory.
-        </p></div><div class="section" title="5.2.17. build/tmp/stamps/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-stamps"></a>5.2.17. <code class="filename">build/tmp/stamps/</code></h3></div></div></div><p>
-            This directory holds information that BitBake uses for accounting purposes
-            to track what tasks have run and when they have run.
-            The directory is sub-divided by architecture, package name, and
-            version.
-            Following is an example:
-            </p><pre class="literallayout">
-     stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do
-            </pre><p>
-            Although the files in the directory are empty of data,
-            BitBake uses the filenames and timestamps for tracking purposes.
-        </p></div><div class="section" title="5.2.18. build/tmp/log/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-log"></a>5.2.18. <code class="filename">build/tmp/log/</code></h3></div></div></div><p>
-            This directory contains general logs that are not otherwise placed using the
-            package's <code class="filename"><a class="link" href="#var-WORKDIR" title="WORKDIR">WORKDIR</a></code>.
-            Examples of logs are the output from the <code class="filename">check_pkg</code> or
-            <code class="filename">distro_check</code> tasks.
-            Running a build does not necessarily mean this directory is created.
-        </p></div><div class="section" title="5.2.19. build/tmp/pkgdata/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-pkgdata"></a>5.2.19. <code class="filename">build/tmp/pkgdata/</code></h3></div></div></div><p>
-            This directory contains intermediate packaging data that is used later in the packaging process.
-            For more information, see the "<a class="link" href="#ref-classes-package" title="7.13. Packaging - package*.bbclass">Packaging - package*.bbclass</a>" section.
-        </p></div><div class="section" title="5.2.20. build/tmp/work/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-build-tmp-work"></a>5.2.20. <code class="filename">build/tmp/work/</code></h3></div></div></div><p>
-            This directory contains architecture-specific work sub-directories
-            for packages built by BitBake.
-            All tasks execute from the appropriate work directory.
-            For example, the source for a particular package is unpacked,
-            patched, configured and compiled all within its own work directory.
-            Within the work directory, organization is based on the package group
-            and version for which the source is being compiled
-            as defined by the
-            <a class="link" href="#var-WORKDIR" title="WORKDIR"><code class="filename">WORKDIR</code></a>.
-        </p><p>
-            It is worth considering the structure of a typical work directory.
-            As an example, consider the <code class="filename">linux-yocto-kernel-3.0</code>
-            on the machine <code class="filename">qemux86</code>
-            built within the Yocto Project.
-            For this package, a work directory of
-            <code class="filename">tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+&lt;.....&gt;</code>,
-            referred to as the
-            <code class="filename"><a class="link" href="#var-WORKDIR" title="WORKDIR">WORKDIR</a></code>, is created.
-            Within this directory, the source is unpacked to
-            <code class="filename">linux-qemux86-standard-build</code> and then patched by Quilt
-            (see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#using-a-quilt-workflow" target="_top">Modifying Package
-            Source Code with Quilt</a>" section in the Yocto Project Development Manual.
-            Within the <code class="filename">linux-qemux86-standard-build</code> directory,
-            standard Quilt directories <code class="filename">linux-3.0/patches</code>
-            and <code class="filename">linux-3.0/.pc</code> are created,
-            and standard Quilt commands can be used.
-        </p><p>
-            There are other directories generated within <code class="filename">WORKDIR</code>.
-            The most important directory is <code class="filename">WORKDIR/temp/</code>,
-            which has log files for each task (<code class="filename">log.do_*.pid</code>)
-            and contains the scripts BitBake runs for each task
-            (<code class="filename">run.do_*.pid</code>).
-            The <code class="filename">WORKDIR/image/</code> directory is where "make
-            install" places its output that is then split into sub-packages
-            within <code class="filename">WORKDIR/packages-split/</code>.
-        </p></div></div><div class="section" title="5.3. The Metadata - meta/"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="structure-meta"></a>5.3. The Metadata - <code class="filename">meta/</code></h2></div></div></div><p>
-        As mentioned previously, metadata is the core of the Yocto Project.
-        Metadata has several important subdivisions:
-    </p><div class="section" title="5.3.1. meta/classes/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-classes"></a>5.3.1. <code class="filename">meta/classes/</code></h3></div></div></div><p>
-            This directory contains the <code class="filename">*.bbclass</code> files.
-            Class files are used to abstract common code so it can be reused by multiple
-            packages.
-            Every package inherits the <code class="filename">base.bbclass</code> file.
-            Examples of other important classes are <code class="filename">autotools.bbclass</code>, which
-            in theory allows any Autotool-enabled package to work with the Yocto Project with minimal effort.
-            Another example is <code class="filename">kernel.bbclass</code> that contains common code and functions
-            for working with the Linux kernel.
-            Functions like image generation or packaging also have their specific class files
-            such as <code class="filename">image.bbclass</code>, <code class="filename">rootfs_*.bbclass</code> and
-            <code class="filename">package*.bbclass</code>.
-        </p></div><div class="section" title="5.3.2. meta/conf/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-conf"></a>5.3.2. <code class="filename">meta/conf/</code></h3></div></div></div><p>
-            This directory contains the core set of configuration files that start from
-            <code class="filename">bitbake.conf</code> and from which all other configuration
-            files are included.
-            See the include statements at the end of the file and you will note that even
-            <code class="filename">local.conf</code> is loaded from there.
-            While <code class="filename">bitbake.conf</code> sets up the defaults, you can often override
-            these by using the (<code class="filename">local.conf</code>) file, machine file or
-            the distribution configuration file.
-        </p></div><div class="section" title="5.3.3. meta/conf/machine/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-conf-machine"></a>5.3.3. <code class="filename">meta/conf/machine/</code></h3></div></div></div><p>
-            This directory contains all the machine configuration files.
-            If you set <code class="filename">MACHINE="qemux86"</code>,
-            the OpenEmbedded build system looks for a <code class="filename">qemux86.conf</code> file in this
-            directory.
-            The <code class="filename">include</code> directory contains various data common to multiple machines.
-            If you want to add support for a new machine to the Yocto Project, look in this directory.
-        </p></div><div class="section" title="5.3.4. meta/conf/distro/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-conf-distro"></a>5.3.4. <code class="filename">meta/conf/distro/</code></h3></div></div></div><p>
-            Any distribution-specific configuration is controlled from this directory.
-            For the Yocto Project, the <code class="filename">defaultsetup.conf</code> is the main file here.
-            This directory includes the versions and the
-            <code class="filename">SRCDATE</code> definitions for applications that are configured here.
-            An example of an alternative configuration might be <code class="filename">poky-bleeding.conf</code>.
-            Although this file mainly inherits its configuration from Poky.
-        </p></div><div class="section" title="5.3.5. meta/recipes-bsp/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-bsp"></a>5.3.5. <code class="filename">meta/recipes-bsp/</code></h3></div></div></div><p>
-            This directory contains anything linking to specific hardware or hardware
-            configuration information such as "u-boot" and "grub".
-        </p></div><div class="section" title="5.3.6. meta/recipes-connectivity/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-connectivity"></a>5.3.6. <code class="filename">meta/recipes-connectivity/</code></h3></div></div></div><p>
-            This directory contains libraries and applications related to communication with other devices.
-        </p></div><div class="section" title="5.3.7. meta/recipes-core/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-core"></a>5.3.7. <code class="filename">meta/recipes-core/</code></h3></div></div></div><p>
-            This directory contains what is needed to build a basic working Linux image
-            including commonly used dependencies.
-        </p></div><div class="section" title="5.3.8. meta/recipes-devtools/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-devtools"></a>5.3.8. <code class="filename">meta/recipes-devtools/</code></h3></div></div></div><p>
-            This directory contains tools that are primarily used by the build system.
-            The tools, however, can also be used on targets.
-        </p></div><div class="section" title="5.3.9. meta/recipes-extended/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-extended"></a>5.3.9. <code class="filename">meta/recipes-extended/</code></h3></div></div></div><p>
-            This directory contains non-essential applications that add features compared to the
-            alternatives in core.
-            You might need this directory for full tool functionality or for Linux Standard Base (LSB)
-            compliance.
-        </p></div><div class="section" title="5.3.10. meta/recipes-gnome/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-gnome"></a>5.3.10. <code class="filename">meta/recipes-gnome/</code></h3></div></div></div><p>
-            This directory contains all things related to the GTK+ application framework.
-        </p></div><div class="section" title="5.3.11. meta/recipes-graphics/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-graphics"></a>5.3.11. <code class="filename">meta/recipes-graphics/</code></h3></div></div></div><p>
-            This directory contains X and other graphically related system libraries
-        </p></div><div class="section" title="5.3.12. meta/recipes-kernel/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-kernel"></a>5.3.12. <code class="filename">meta/recipes-kernel/</code></h3></div></div></div><p>
-            This directory contains the kernel and generic applications and libraries that
-            have strong kernel dependencies.
-        </p></div><div class="section" title="5.3.13. meta/recipes-multimedia/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-multimedia"></a>5.3.13. <code class="filename">meta/recipes-multimedia/</code></h3></div></div></div><p>
-            This directory contains codecs and support utilities for audio, images and video.
-        </p></div><div class="section" title="5.3.14. meta/recipes-qt/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-qt"></a>5.3.14. <code class="filename">meta/recipes-qt/</code></h3></div></div></div><p>
-            This directory contains all things related to the Qt application framework.
-        </p></div><div class="section" title="5.3.15. meta/recipes-rt/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-rt"></a>5.3.15. <code class="filename">meta/recipes-rt/</code></h3></div></div></div><p>
-            This directory contains package and image recipes for using and testing
-            the <code class="filename">PREEMPT_RT</code> kernel.
-        </p></div><div class="section" title="5.3.16. meta/recipes-sato/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-sato"></a>5.3.16. <code class="filename">meta/recipes-sato/</code></h3></div></div></div><p>
-            This directory contains the Sato demo/reference UI/UX and its associated applications
-            and configuration data.
-        </p></div><div class="section" title="5.3.17. meta/recipes-support/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-support"></a>5.3.17. <code class="filename">meta/recipes-support/</code></h3></div></div></div><p>
-            This directory contains recipes that used by other recipes, but that are not directly
-            included in images (i.e. dependencies of other recipes).
-        </p></div><div class="section" title="5.3.18. meta/site/"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-site"></a>5.3.18. <code class="filename">meta/site/</code></h3></div></div></div><p>
-            This directory contains a list of cached results for various architectures.
-            Because certain "autoconf" test results cannot be determined when cross-compiling due to
-            the tests not able to run on a live system, the information in this directory is
-            passed to "autoconf" for the various architectures.
-        </p></div><div class="section" title="5.3.19. meta/recipes.txt"><div class="titlepage"><div><div><h3 class="title"><a id="structure-meta-recipes-txt"></a>5.3.19. <code class="filename">meta/recipes.txt</code></h3></div></div></div><p>
-            This file is a description of the contents of <code class="filename">recipes-*</code>.
-        </p></div></div></div>
-
-    <div class="chapter" title="Chapter 6. BitBake"><div class="titlepage"><div><div><h2 class="title"><a id="ref-bitbake"></a>Chapter 6. BitBake</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#ref-bitbake-parsing">6.1. Parsing</a></span></dt><dt><span class="section"><a href="#ref-bitbake-providers">6.2. Preferences and Providers</a></span></dt><dt><span class="section"><a href="#ref-bitbake-dependencies">6.3. Dependencies</a></span></dt><dt><span class="section"><a href="#ref-bitbake-tasklist">6.4. The Task List</a></span></dt><dt><span class="section"><a href="#ref-bitbake-runtask">6.5. Running a Task</a></span></dt><dt><span class="section"><a href="#ref-bitbake-commandline">6.6. BitBake Command Line</a></span></dt><dt><span class="section"><a href="#ref-bitbake-fetchers">6.7. Fetchers</a></span></dt></dl></div><p>
-        BitBake is a program written in Python that interprets the metadata used by the OpenEmbedded
-        build system.
-        At some point, developers wonder what actually happens when you enter:
-        </p><pre class="literallayout">
-     $ bitbake core-image-sato
-        </pre><p>
-    </p><p>
-        This chapter provides an overview of what happens behind the scenes from BitBake's perspective.
-    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-        BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships.
-        As such, it has no real knowledge of what the tasks being executed actually do.
-        BitBake just considers a list of tasks with dependencies and handles metadata
-        that consists of variables in a certain format that get passed to the tasks.
-    </div><div class="section" title="6.1. Parsing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-bitbake-parsing"></a>6.1. Parsing</h2></div></div></div><p>
-            BitBake parses configuration files, classes, and <code class="filename">.bb</code> files.
-        </p><p>
-            The first thing BitBake does is look for the <code class="filename">bitbake.conf</code> file.
-            This file resides in the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>
-            within the <code class="filename">meta/conf/</code> directory.
-            BitBake finds it by examining its
-            <a class="link" href="#var-BBPATH" title="BBPATH"><code class="filename">BBPATH</code></a> environment
-            variable and looking for the <code class="filename">meta/conf/</code>
-            directory.
-        </p><p>
-            The <code class="filename">bitbake.conf</code> file lists other configuration
-            files to include from a <code class="filename">conf/</code>
-            directory below the directories listed in <code class="filename">BBPATH</code>.
-            In general, the most important configuration file from a user's perspective
-            is <code class="filename">local.conf</code>, which contains a user's customized
-            settings for the OpenEmbedded build environment.
-            Other notable configuration files are the distribution
-            configuration file (set by the
-            <code class="filename"><a class="link" href="#var-DISTRO" title="DISTRO">DISTRO</a></code> variable)
-            and the machine configuration file
-            (set by the
-            <code class="filename"><a class="link" href="#var-MACHINE" title="MACHINE">MACHINE</a></code> variable).
-            The <code class="filename">DISTRO</code> and <code class="filename">MACHINE</code> BitBake environment
-            variables are both usually set in
-            the <code class="filename">local.conf</code> file.
-            Valid distribution
-            configuration files are available in the <code class="filename">meta/conf/distro/</code> directory
-            and valid machine configuration
-            files in the <code class="filename">meta/conf/machine/</code> directory.
-            Within the <code class="filename">meta/conf/machine/include/</code>
-            directory are various <code class="filename">tune-*.inc</code> configuration files that provide common
-            "tuning" settings specific to and shared between particular architectures and machines.
-        </p><p>
-            After the parsing of the configuration files, some standard classes are included.
-            The <code class="filename">base.bbclass</code> file is always included.
-            Other classes that are specified in the configuration using the
-            <code class="filename"><a class="link" href="#var-INHERIT" title="INHERIT">INHERIT</a></code>
-            variable are also included.
-            Class files are searched for in a <code class="filename">classes</code> subdirectory
-            under the paths in <code class="filename">BBPATH</code> in the same way as
-            configuration files.
-        </p><p>
-            After classes are included, the variable
-            <code class="filename"><a class="link" href="#var-BBFILES" title="BBFILES">BBFILES</a></code>
-            is set, usually in
-            <code class="filename">local.conf</code>, and defines the list of places to search for
-            <code class="filename">.bb</code> files.
-            By default, the <code class="filename">BBFILES</code> variable specifies the
-            <code class="filename">meta/recipes-*/</code> directory within Poky.
-            Adding extra content to <code class="filename">BBFILES</code> is best achieved through the use of
-            BitBake layers as described in the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#understanding-and-creating-layers" target="_top">Understanding and
-            Creating Layers</a>" section of the Yocto Project Development Manual.
-        </p><p>
-            BitBake parses each <code class="filename">.bb</code> file in <code class="filename">BBFILES</code> and
-            stores the values of various variables.
-            In summary, for each <code class="filename">.bb</code>
-            file the configuration plus the base class of variables are set, followed
-            by the data in the <code class="filename">.bb</code> file
-            itself, followed by any inherit commands that
-            <code class="filename">.bb</code> file might contain.
-        </p><p>
-            Because parsing <code class="filename">.bb</code> files is a time
-            consuming process, a cache is kept to speed up subsequent parsing.
-            This cache is invalid if the timestamp of the <code class="filename">.bb</code>
-            file itself changes, or if the timestamps of any of the include,
-            configuration or class files the <code class="filename">.bb</code>
-            file depends on changes.
-        </p></div><div class="section" title="6.2. Preferences and Providers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-bitbake-providers"></a>6.2. Preferences and Providers</h2></div></div></div><p>
-            Once all the <code class="filename">.bb</code> files have been
-            parsed, BitBake starts to build the target (<code class="filename">core-image-sato</code>
-            in the previous section's example) and looks for providers of that target.
-            Once a provider is selected, BitBake resolves all the dependencies for
-            the target.
-            In the case of <code class="filename">core-image-sato</code>, it would lead to
-            <code class="filename">packagegroup-core-x11-sato</code>,
-            which in turn leads to recipes like <code class="filename">matchbox-terminal</code>,
-            <code class="filename">pcmanfm</code> and <code class="filename">gthumb</code>.
-            These recipes in turn depend on <code class="filename">eglibc</code> and the toolchain.
-        </p><p>
-            Sometimes a target might have multiple providers.
-            A common example is "virtual/kernel", which is provided by each kernel package.
-            Each machine often selects the best kernel provider by using a line similar to the
-            following in the machine configuration file:
-        </p><pre class="literallayout">
-     PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
-        </pre><p>
-            The default <code class="filename"><a class="link" href="#var-PREFERRED_PROVIDER" title="PREFERRED_PROVIDER">PREFERRED_PROVIDER</a></code>
-            is the provider with the same name as the target.
-        </p><p>
-            Understanding how providers are chosen is made complicated by the fact
-            that multiple versions might exist.
-            BitBake defaults to the highest version of a provider.
-            Version comparisons are made using the same method as Debian.
-            You can use the
-            <code class="filename"><a class="link" href="#var-PREFERRED_VERSION" title="PREFERRED_VERSION">PREFERRED_VERSION</a></code>
-            variable to specify a particular version (usually in the distro configuration).
-            You can influence the order by using the
-            <code class="filename"><a class="link" href="#var-DEFAULT_PREFERENCE" title="DEFAULT_PREFERENCE">DEFAULT_PREFERENCE</a></code>
-            variable.
-            By default, files have a preference of "0".
-            Setting the <code class="filename">DEFAULT_PREFERENCE</code> to "-1" makes the
-            package unlikely to be used unless it is explicitly referenced.
-            Setting the <code class="filename">DEFAULT_PREFERENCE</code> to "1" makes it likely the package is used.
-            <code class="filename">PREFERRED_VERSION</code> overrides any <code class="filename">DEFAULT_PREFERENCE</code> setting.
-            <code class="filename">DEFAULT_PREFERENCE</code> is often used to mark newer and more experimental package
-            versions until they have undergone sufficient testing to be considered stable.
-        </p><p>
-            In summary, BitBake has created a list of providers, which is prioritized, for each target.
-        </p></div><div class="section" title="6.3. Dependencies"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-bitbake-dependencies"></a>6.3. Dependencies</h2></div></div></div><p>
-            Each target BitBake builds consists of multiple tasks such as
-            <code class="filename">fetch</code>, <code class="filename">unpack</code>,
-            <code class="filename">patch</code>, <code class="filename">configure</code>,
-            and <code class="filename">compile</code>.
-            For best performance on multi-core systems, BitBake considers each task as an independent
-            entity with its own set of dependencies.
-        </p><p>
-            Dependencies are defined through several variables.
-            You can find information about variables BitBake uses in the BitBake documentation,
-            which is found in the <code class="filename">bitbake/doc/manual</code> directory within the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-            At a basic level, it is sufficient to know that BitBake uses the
-            <code class="filename"><a class="link" href="#var-DEPENDS" title="DEPENDS">DEPENDS</a></code> and
-            <code class="filename"><a class="link" href="#var-RDEPENDS" title="RDEPENDS">RDEPENDS</a></code> variables when
-            calculating dependencies.
-        </p></div><div class="section" title="6.4. The Task List"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-bitbake-tasklist"></a>6.4. The Task List</h2></div></div></div><p>
-            Based on the generated list of providers and the dependency information,
-            BitBake can now calculate exactly what tasks it needs to run and in what
-            order it needs to run them.
-            The build now starts with BitBake forking off threads up to the limit set in the
-            <code class="filename"><a class="link" href="#var-BB_NUMBER_THREADS" title="BB_NUMBER_THREADS">BB_NUMBER_THREADS</a></code> variable.
-            BitBake continues to fork threads as long as there are tasks ready to run,
-            those tasks have all their dependencies met, and the thread threshold has not been
-            exceeded.
-        </p><p>
-            It is worth noting that you can greatly speed up the build time by properly setting
-            the <code class="filename">BB_NUMBER_THREADS</code> variable.
-            See the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/yocto-project-qs/yocto-project-qs.html#building-image" target="_top">Building an Image</a>"
-            section in the Yocto Project Quick Start for more information.
-        </p><p>
-            As each task completes, a timestamp is written to the directory specified by the
-            <code class="filename"><a class="link" href="#var-STAMP" title="STAMP">STAMP</a></code> variable.
-            On subsequent runs, BitBake looks within the <code class="filename">/build/tmp/stamps</code>
-            directory and does not rerun
-            tasks that are already completed unless a timestamp is found to be invalid.
-            Currently, invalid timestamps are only considered on a per
-            <code class="filename">.bb</code> file basis.
-            So, for example, if the configure stamp has a timestamp greater than the
-            compile timestamp for a given target, then the compile task would rerun.
-            Running the compile task again, however, has no effect on other providers
-            that depend on that target.
-            This behavior could change or become configurable in future versions of BitBake.
-        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-            Some tasks are marked as "nostamp" tasks.
-            No timestamp file is created when these tasks are run.
-            Consequently, "nostamp" tasks are always rerun.
-        </div></div><div class="section" title="6.5. Running a Task"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-bitbake-runtask"></a>6.5. Running a Task</h2></div></div></div><p>
-            Tasks can either be a shell task or a Python task.
-            For shell tasks, BitBake writes a shell script to
-            <code class="filename">${WORKDIR}/temp/run.do_taskname.pid</code> and then executes the script.
-            The generated shell script contains all the exported variables, and the shell functions
-            with all variables expanded.
-            Output from the shell script goes to the file <code class="filename">${WORKDIR}/temp/log.do_taskname.pid</code>.
-            Looking at the expanded shell functions in the run file and the output in the log files
-            is a useful debugging technique.
-        </p><p>
-            For Python tasks, BitBake executes the task internally and logs information to the
-            controlling terminal.
-            Future versions of BitBake will write the functions to files similar to the way
-            shell tasks are handled.
-            Logging will be handled in way similar to shell tasks as well.
-        </p><p>
-            Once all the tasks have been completed BitBake exits.
-        </p><p>
-            When running a task, BitBake tightly controls the execution environment
-            of the build tasks to make sure unwanted contamination from the build machine
-            cannot influence the build.
-            Consequently, if you do want something to get passed into the build
-            task's environment, you must take a few steps:
-            </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Tell BitBake to load what you want from the environment
-                    into the data store.
-                    You can do so through the <code class="filename">BB_ENV_EXTRAWHITE</code>
-                    variable.
-                    For example, assume you want to prevent the build system from
-                    accessing your <code class="filename">$HOME/.ccache</code> directory.
-                    The following command tells BitBake to load
-                    <code class="filename">CCACHE_DIR</code> from the environment into the data
-                    store:
-                    </p><pre class="literallayout">
-     export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"
-                    </pre></li><li class="listitem"><p>Tell BitBake to export what you have loaded into the
-                    environment store to the task environment of every running task.
-                    Loading something from the environment into the data store
-                    (previous step) only makes it available in the datastore.
-                    To export it to the task environment of every running task,
-                    use a command similar to the following in your
-                    <code class="filename">local.conf</code> or distro configuration file:
-                    </p><pre class="literallayout">
-     export CCACHE_DIR
-                    </pre></li></ol></div><p>
-        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-            A side effect of the previous steps is that BitBake records the variable
-            as a dependency of the build process in things like the shared state
-            checksums.
-            If doing so results in unnecessary rebuilds of tasks, you can whitelist the
-            variable so that the shared state code ignores the dependency when it creates
-            checksums.
-            For information on this process, see the <code class="filename">BB_HASHBASE_WHITELIST</code>
-            example in the "<a class="link" href="#checksums" title="3.2.2. Checksums (Signatures)">Checksums (Signatures)</a>" section.
-        </div></div><div class="section" title="6.6. BitBake Command Line"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-bitbake-commandline"></a>6.6. BitBake Command Line</h2></div></div></div><p>
-            Following is the BitBake help output:
-        </p><pre class="screen">
-$ bitbake --help
-Usage: bitbake [options] [package ...]
-
-Executes the specified task (default is 'build') for a given set of BitBake files.
-It expects that BBFILES is defined, which is a space separated list of files to
-be executed.  BBFILES does support wildcards.
-Default BBFILES are the .bb files in the current directory.
-
-Options:
-  --version             show program's version number and exit
-  -h, --help            show this help message and exit
-  -b BUILDFILE, --buildfile=BUILDFILE
-                        execute the task against this .bb file, rather than a
-                        package from BBFILES. Does not handle any
-                        dependencies.
-  -k, --continue        continue as much as possible after an error. While the
-                        target that failed, and those that depend on it,
-                        cannot be remade, the other dependencies of these
-                        targets can be processed all the same.
-  -a, --tryaltconfigs   continue with builds by trying to use alternative
-                        providers where possible.
-  -f, --force           force run of specified cmd, regardless of stamp status
-  -c CMD, --cmd=CMD     Specify task to execute. Note that this only executes
-                        the specified task for the providee and the packages
-                        it depends on, i.e. 'compile' does not implicitly call
-                        stage for the dependencies (IOW: use only if you know
-                        what you are doing). Depending on the base.bbclass a
-                        listtasks tasks is defined and will show available
-                        tasks
-  -r PREFILE, --read=PREFILE
-                        read the specified file before bitbake.conf
-  -R POSTFILE, --postread=POSTFILE
-                        read the specified file after bitbake.conf
-  -v, --verbose         output more chit-chat to the terminal
-  -D, --debug           Increase the debug level. You can specify this more
-                        than once.
-  -n, --dry-run         don't execute, just go through the motions
-  -S, --dump-signatures
-                        don't execute, just dump out the signature
-                        construction information
-  -p, --parse-only      quit after parsing the BB files (developers only)
-  -s, --show-versions   show current and preferred versions of all packages
-  -e, --environment     show the global or per-package environment (this is
-                        what used to be bbread)
-  -g, --graphviz        emit the dependency trees of the specified packages in
-                        the dot syntax
-  -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
-                        Assume these dependencies don't exist and are already
-                        provided (equivalent to ASSUME_PROVIDED). Useful to
-                        make dependency graphs more appealing
-  -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
-                        Show debug logging for the specified logging domains
-  -P, --profile         profile the command and print a report
-  -u UI, --ui=UI        userinterface to use
-  -t SERVERTYPE, --servertype=SERVERTYPE
-                        Choose which server to use, none, process or xmlrpc
-  --revisions-changed   Set the exit code depending on whether upstream
-                        floating revisions have changed or not
-        </pre></div><div class="section" title="6.7. Fetchers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-bitbake-fetchers"></a>6.7. Fetchers</h2></div></div></div><p>
-            BitBake also contains a set of "fetcher" modules that allow
-            retrieval of source code from various types of sources.
-            For example, BitBake can get source code from a disk with the metadata, from websites,
-            from remote shell accounts or from Source Code Management (SCM) systems
-            like <code class="filename">cvs/subversion/git</code>.
-        </p><p>
-            Fetchers are usually triggered by entries in
-            <code class="filename"><a class="link" href="#var-SRC_URI" title="SRC_URI">SRC_URI</a></code>.
-            You can find information about the options and formats of entries for specific
-            fetchers in the BitBake manual located in the
-            <code class="filename">bitbake/doc/manual</code> directory of the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-        </p><p>
-            One useful feature for certain Source Code Manager (SCM) fetchers is the ability to
-            "auto-update" when the upstream SCM changes version.
-            Since this ability requires certain functionality from the SCM, not all
-            systems support it.
-            Currently Subversion, Bazaar and to a limited extent, Git support the ability to "auto-update".
-            This feature works using the <code class="filename"><a class="link" href="#var-SRCREV" title="SRCREV">SRCREV</a></code>
-            variable.
-            See the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#platdev-appdev-srcrev" target="_top">Using an External SCM</a>" section
-            in the Yocto Project Development Manual for more information.
-        </p></div></div>
-
-    <div class="chapter" title="Chapter 7. Classes"><div class="titlepage"><div><div><h2 class="title"><a id="ref-classes"></a>Chapter 7. Classes</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#ref-classes-base">7.1. The base class - <code class="filename">base.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-autotools">7.2. Autotooled Packages - <code class="filename">autotools.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-update-alternatives">7.3. Alternatives - <code class="filename">update-alternatives.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-update-rc.d">7.4. Initscripts - <code class="filename">update-rc.d.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-binconfig">7.5. Binary config scripts - <code class="filename">binconfig.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-debian">7.6. Debian renaming - <code class="filename">debian.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-pkgconfig">7.7. Pkg-config - <code class="filename">pkgconfig.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-src-distribute">7.8. Distribution of sources - <code class="filename">src_distribute_local.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-perl">7.9. Perl modules - <code class="filename">cpan.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-distutils">7.10. Python extensions - <code class="filename">distutils.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-devshell">7.11. Developer Shell - <code class="filename">devshell.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-packagegroup">7.12. Package Groups - <code class="filename">packagegroup.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-package">7.13. Packaging - <code class="filename">package*.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-kernel">7.14. Building kernels - <code class="filename">kernel.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-image">7.15. Creating images - <code class="filename">image.bbclass</code> and <code class="filename">rootfs*.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-sanity">7.16. Host System sanity checks - <code class="filename">sanity.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-insane">7.17. Generated output quality assurance checks - <code class="filename">insane.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-siteinfo">7.18. Autotools configuration data cache - <code class="filename">siteinfo.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-useradd">7.19. Adding Users - <code class="filename">useradd.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-externalsrc">7.20. Using External Source - <code class="filename">externalsrc.bbclass</code></a></span></dt><dt><span class="section"><a href="#ref-classes-others">7.21. Other Classes</a></span></dt></dl></div><p>
-    Class files are used to abstract common functionality and share it amongst multiple
-    <code class="filename">.bb</code> files.
-    Any metadata usually found in a <code class="filename">.bb</code> file can also be placed in a class
-    file.
-    Class files are identified by the extension <code class="filename">.bbclass</code> and are usually placed
-    in a <code class="filename">classes/</code> directory beneath the
-    <code class="filename">meta*/</code> directory found in the
-    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-    Class files can also be pointed to by BUILDDIR (e.g. <code class="filename">build/</code>)in the same way as
-    <code class="filename">.conf</code> files in the <code class="filename">conf</code> directory.
-    Class files are searched for in <a class="link" href="#var-BBPATH" title="BBPATH"><code class="filename">BBPATH</code></a>
-    using the same method by which <code class="filename">.conf</code> files are searched.
-</p><p>
-    In most cases inheriting the class is enough to enable its features, although
-    for some classes you might need to set variables or override some of the
-    default behaviour.
-</p><div class="section" title="7.1. The base class - base.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-base"></a>7.1. The base class - <code class="filename">base.bbclass</code></h2></div></div></div><p>
-        The base class is special in that every <code class="filename">.bb</code>
-        file inherits it automatically.
-        This class contains definitions for standard basic
-        tasks such as fetching, unpacking, configuring (empty by default), compiling
-        (runs any <code class="filename">Makefile</code> present), installing (empty by default) and packaging
-        (empty by default).
-        These classes are often overridden or extended by other classes
-        such as <code class="filename">autotools.bbclass</code> or <code class="filename">package.bbclass</code>.
-        The class also contains some commonly used functions such as <code class="filename">oe_runmake</code>.
-    </p></div><div class="section" title="7.2. Autotooled Packages - autotools.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-autotools"></a>7.2. Autotooled Packages - <code class="filename">autotools.bbclass</code></h2></div></div></div><p>
-        Autotools (<code class="filename">autoconf</code>, <code class="filename">automake</code>,
-        and <code class="filename">libtool</code>) bring standardization.
-        This class defines a set of tasks (configure, compile etc.) that
-        work for all Autotooled packages.
-        It should usually be enough to define a few standard variables
-        and then simply <code class="filename">inherit autotools</code>.
-        This class can also work with software that emulates Autotools.
-        For more information, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#usingpoky-extend-addpkg-autotools" target="_top">Autotooled Package</a>"
-        section in the Yocto Project Development Manual.
-    </p><p>
-        It's useful to have some idea of how the tasks defined by this class work
-        and what they do behind the scenes.
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename">do_configure</code> ‐ regenerates the
-                configure script (using <code class="filename">autoreconf</code>) and then launches it
-                with a standard set of arguments used during cross-compilation.
-                You can pass additional parameters to <code class="filename">configure</code> through the
-                <code class="filename"><a class="link" href="#var-EXTRA_OECONF" title="EXTRA_OECONF">EXTRA_OECONF</a></code> variable.
-                </p></li><li class="listitem"><p><code class="filename">do_compile</code> ‐ runs <code class="filename">make</code> with
-                arguments that specify the compiler and linker.
-                You can pass additional arguments through
-                the <code class="filename"><a class="link" href="#var-EXTRA_OEMAKE" title="EXTRA_OEMAKE">EXTRA_OEMAKE</a></code> variable.
-                </p></li><li class="listitem"><p><code class="filename">do_install</code> ‐ runs <code class="filename">make install</code>
-                and passes a DESTDIR option, which takes its value from the standard
-                <code class="filename"><a class="link" href="#var-DESTDIR" title="DESTDIR">DESTDIR</a></code> variable.
-                </p></li></ul></div><p>
-    </p></div><div class="section" title="7.3. Alternatives - update-alternatives.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-update-alternatives"></a>7.3. Alternatives - <code class="filename">update-alternatives.bbclass</code></h2></div></div></div><p>
-        Several programs can fulfill the same or similar function and be installed with the same name.
-        For example, the <code class="filename">ar</code> command is available from the
-        <code class="filename">busybox</code>, <code class="filename">binutils</code> and
-        <code class="filename">elfutils</code> packages.
-        The <code class="filename">update-alternatives.bbclass</code> class handles renaming the
-        binaries so that multiple packages can be installed without conflicts.
-        The <code class="filename">ar</code> command still works regardless of which packages are installed
-        or subsequently removed.
-        The class renames the conflicting binary in each package and symlinks the highest
-        priority binary during installation or removal of packages.
-    </p><p>
-        Four variables control this class:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename">ALTERNATIVE_NAME</code> ‐ The name of the
-                binary that is replaced (<code class="filename">ar</code> in this example).</p></li><li class="listitem"><p><code class="filename">ALTERNATIVE_LINK</code> ‐ The path to
-                the resulting binary (<code class="filename">/bin/ar</code> in this example).</p></li><li class="listitem"><p><code class="filename">ALTERNATIVE_PATH</code> ‐ The path to the
-                real binary (<code class="filename">/usr/bin/ar.binutils</code> in this example).</p></li><li class="listitem"><p><code class="filename">ALTERNATIVE_PRIORITY</code> ‐ The priority of
-                the binary.
-                The version with the most features should have the highest priority.</p></li></ul></div><p>
-    </p><p>
-	Currently, the OpenEmbedded build system supports only one binary per package.
-    </p></div><div class="section" title="7.4. Initscripts - update-rc.d.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-update-rc.d"></a>7.4. Initscripts - <code class="filename">update-rc.d.bbclass</code></h2></div></div></div><p>
-        This class uses <code class="filename">update-rc.d</code> to safely install an
-        initialization script on behalf of the package.
-        The OpenEmbedded build system takes care of details such as making sure the script is stopped before
-        a package is removed and started when the package is installed.
-        Three variables control this class:
-        <code class="filename"><a class="link" href="#var-INITSCRIPT_PACKAGES" title="INITSCRIPT_PACKAGES">INITSCRIPT_PACKAGES</a></code>,
-        <code class="filename"><a class="link" href="#var-INITSCRIPT_NAME" title="INITSCRIPT_NAME">INITSCRIPT_NAME</a></code> and
-        <code class="filename"><a class="link" href="#var-INITSCRIPT_PARAMS" title="INITSCRIPT_PARAMS">INITSCRIPT_PARAMS</a></code>.
-        See the variable links for details.
-    </p></div><div class="section" title="7.5. Binary config scripts - binconfig.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-binconfig"></a>7.5. Binary config scripts - <code class="filename">binconfig.bbclass</code></h2></div></div></div><p>
-        Before <code class="filename">pkg-config</code> had become widespread, libraries shipped shell
-        scripts to give information about the libraries and include paths needed
-        to build software (usually named <code class="filename">LIBNAME-config</code>).
-        This class assists any recipe using such scripts.
-    </p><p>
-        During staging, BitBake installs such scripts into the
-        <code class="filename">sysroots/</code> directory.
-        BitBake also changes all paths to point into the <code class="filename">sysroots/</code>
-        directory so all builds that use the script will use the correct
-        directories for the cross compiling layout.
-    </p></div><div class="section" title="7.6. Debian renaming - debian.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-debian"></a>7.6. Debian renaming - <code class="filename">debian.bbclass</code></h2></div></div></div><p>
-        This class renames packages so that they follow the Debian naming
-        policy (i.e. <code class="filename">eglibc</code> becomes <code class="filename">libc6</code>
-        and <code class="filename">eglibc-devel</code> becomes <code class="filename">libc6-dev</code>.
-    </p></div><div class="section" title="7.7. Pkg-config - pkgconfig.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-pkgconfig"></a>7.7. Pkg-config - <code class="filename">pkgconfig.bbclass</code></h2></div></div></div><p>
-        <code class="filename">pkg-config</code> brought standardization and this class aims to make its
-        integration smooth for all libraries that make use of it.
-    </p><p>
-        During staging, BitBake installs <code class="filename">pkg-config</code> data into the
-        <code class="filename">sysroots/</code> directory.
-        By making use of sysroot functionality within <code class="filename">pkg-config</code>,
-        this class no longer has to manipulate the files.
-    </p></div><div class="section" title="7.8. Distribution of sources - src_distribute_local.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-src-distribute"></a>7.8. Distribution of sources - <code class="filename">src_distribute_local.bbclass</code></h2></div></div></div><p>
-        Many software licenses require that source files be provided along with the binaries.
-        To simplify this process, two classes were created:
-        <code class="filename">src_distribute.bbclass</code> and
-        <code class="filename">src_distribute_local.bbclass</code>.
-    </p><p>
-        The results of these classes are <code class="filename">tmp/deploy/source/</code>
-        subdirs with sources sorted by
-        <code class="filename"><a class="link" href="#var-LICENSE" title="LICENSE">LICENSE</a></code> field.
-        If recipes list few licenses (or have entries like "Bitstream Vera"),
-        the source archive is placed in each license directory.
-    </p><p>
-        This class operates using three modes:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>copy:</em></span> Copies the files to the
-                distribute directory.</p></li><li class="listitem"><p><span class="emphasis"><em>symlink:</em></span> Symlinks the files to the
-                distribute directory.</p></li><li class="listitem"><p><span class="emphasis"><em>move+symlink:</em></span> Moves the files into
-                the distribute directory and then symlinks them back.</p></li></ul></div><p>
-    </p></div><div class="section" title="7.9. Perl modules - cpan.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-perl"></a>7.9. Perl modules - <code class="filename">cpan.bbclass</code></h2></div></div></div><p>
-        Recipes for Perl modules are simple.
-        These recipes usually only need to point to the source's archive and then inherit the
-        proper <code class="filename">.bbclass</code> file.
-        Building is split into two methods depending on which method the module authors used.
-    </p><p>
-        Modules that use old <code class="filename">Makefile.PL</code>-based build system require
-        <code class="filename">cpan.bbclass</code> in their recipes.
-    </p><p>
-        Modules that use <code class="filename">Build.PL</code>-based build system require
-        using <code class="filename">cpan_build.bbclass</code> in their recipes.
-    </p></div><div class="section" title="7.10. Python extensions - distutils.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-distutils"></a>7.10. Python extensions - <code class="filename">distutils.bbclass</code></h2></div></div></div><p>
-        Recipes for Python extensions are simple.
-        These recipes usually only need to point to the source's archive and then inherit
-        the proper <code class="filename">.bbclass</code> file.
-        Building is split into two methods dependling on which method the module authors used.
-    </p><p>
-        Extensions that use an Autotools-based build system require Autotools and
-        <code class="filename">distutils</code>-based <code class="filename">.bbclasse</code> files in their recipes.
-    </p><p>
-        Extensions that use <code class="filename">distutils</code>-based build systems require
-        <code class="filename">distutils.bbclass</code> in their recipes.
-    </p></div><div class="section" title="7.11. Developer Shell - devshell.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-devshell"></a>7.11. Developer Shell - <code class="filename">devshell.bbclass</code></h2></div></div></div><p>
-        This class adds the <code class="filename">devshell</code> task.
-        Distribution policy dictates whether to include this class.
-        See the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#platdev-appdev-devshell" target="_top">Using a Development Shell</a>" section
-        in the Yocto Project Development Manual for more information about using <code class="filename">devshell</code>.
-    </p></div><div class="section" title="7.12. Package Groups - packagegroup.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-packagegroup"></a>7.12. Package Groups - <code class="filename">packagegroup.bbclass</code></h2></div></div></div><p>
-        This class sets default values appropriate for package group recipes (such as
-        <code class="filename"><a class="link" href="#var-PACKAGES" title="PACKAGES">PACKAGES</a></code>,
-        <code class="filename"><a class="link" href="#var-PACKAGE_ARCH" title="PACKAGE_ARCH">PACKAGE_ARCH</a></code>,
-        <code class="filename"><a class="link" href="#var-ALLOW_EMPTY" title="ALLOW_EMPTY">ALLOW_EMPTY</a></code>,
-        and so forth.
-        It is highly recommended that all package group recipes inherit this class.
-    </p><p>
-        For information on how to use this class, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks" target="_top">Customizing Images Using Custom Package Tasks</a>"
-        section in the Yocto Project Development Manual.
-    </p><p>
-        Previously, this class was named <code class="filename">task.bbclass</code>.
-    </p></div><div class="section" title="7.13. Packaging - package*.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-package"></a>7.13. Packaging - <code class="filename">package*.bbclass</code></h2></div></div></div><p>
-        The packaging classes add support for generating packages from a build's
-        output.
-        The core generic functionality is in <code class="filename">package.bbclass</code>.
-        The code specific to particular package types is contained in various sub-classes such as
-        <code class="filename">package_deb.bbclass</code>, <code class="filename">package_ipk.bbclass</code>,
-        and <code class="filename">package_rpm.bbclass</code>.
-        Most users will want one or more of these classes.
-    </p><p>
-        You can control the list of resulting package formats by using the
-        <code class="filename"><a class="link" href="#var-PACKAGE_CLASSES" title="PACKAGE_CLASSES">PACKAGE_CLASSES</a></code>
-        variable defined in the <code class="filename">local.conf</code> configuration file,
-        which is located in the <code class="filename">conf</code> folder of the
-        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-        When defining the variable, you can specify one or more package types.
-        Since images are generated from packages, a packaging class is
-        needed to enable image generation.
-        The first class listed in this variable is used for image generation.
-    </p><p>
-        The package class you choose can affect build-time performance and has space
-        ramifications.
-        In general, building a package with RPM takes about thirty percent more time as
-        compared to using IPK to build the same or similar package.
-        This comparison takes into account a complete build of the package with all
-        dependencies previously built.
-        The reason for this discrepancy is because the RPM package manager creates and
-        processes more metadata than the IPK package manager.
-        Consequently, you might consider setting <code class="filename">PACKAGE_CLASSES</code>
-        to "package_ipk" if you are building smaller systems.
-    </p><p>
-        Keep in mind, however, that RPM starts to provide more abilities than IPK due to
-        the fact that it processes more metadata.
-        For example, this information includes individual file types, file checksum generation
-        and evaluation on install, sparse file support, conflict detection and resolution
-        for multilib systems, ACID style upgrade, and repackaging abilities for rollbacks.
-    </p><p>
-        Another consideration for packages built using the RPM package manager is space.
-        For smaller systems, the extra space used for the Berkley Database and the amount
-        of metadata can affect your ability to do on-device upgrades.
-    </p><p>
-        You can find additional information on the effects of the package class at these
-        two Yocto Project mailing list links:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html" target="_top">
-                https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html</a></p></li><li class="listitem"><p><a class="ulink" href="http://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html" target="_top">
-                https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html</a></p></li></ul></div><p>
-    </p></div><div class="section" title="7.14. Building kernels - kernel.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-kernel"></a>7.14. Building kernels - <code class="filename">kernel.bbclass</code></h2></div></div></div><p>
-        This class handles building Linux kernels.
-        The class contains code to build all kernel trees.
-        All needed headers are staged into the
-        <code class="filename"><a class="link" href="#var-STAGING_KERNEL_DIR" title="STAGING_KERNEL_DIR">STAGING_KERNEL_DIR</a></code>
-        directory to allow out-of-tree module builds using <code class="filename">module.bbclass</code>.
-    </p><p>
-        This means that each built kernel module is packaged separately and inter-module
-        dependencies are created by parsing the <code class="filename">modinfo</code> output.
-        If all modules are required, then installing the <code class="filename">kernel-modules</code>
-        package installs all packages with modules and various other kernel packages
-        such as <code class="filename">kernel-vmlinux</code>.
-    </p><p>
-        Various other classes are used by the kernel and module classes internally including
-        <code class="filename">kernel-arch.bbclass</code>, <code class="filename">module_strip.bbclass</code>,
-        <code class="filename">module-base.bbclass</code>, and <code class="filename">linux-kernel-base.bbclass</code>.
-    </p></div><div class="section" title="7.15. Creating images - image.bbclass and rootfs*.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-image"></a>7.15. Creating images - <code class="filename">image.bbclass</code> and <code class="filename">rootfs*.bbclass</code></h2></div></div></div><p>
-        These classes add support for creating images in several formats.
-        First, the root filesystem is created from packages using
-        one of the <code class="filename">rootfs_*.bbclass</code>
-        files (depending on the package format used) and then the image is created.
-    </p><p>
-        The <code class="filename"><a class="link" href="#var-IMAGE_FSTYPES" title="IMAGE_FSTYPES">IMAGE_FSTYPES</a></code>
-        variable controls the types of images to generate.
-    </p><p>
-        The <code class="filename"><a class="link" href="#var-IMAGE_INSTALL" title="IMAGE_INSTALL">IMAGE_INSTALL</a></code>
-        variable controls the list of packages to install into the image.
-    </p></div><div class="section" title="7.16. Host System sanity checks - sanity.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-sanity"></a>7.16. Host System sanity checks - <code class="filename">sanity.bbclass</code></h2></div></div></div><p>
-        This class checks to see if prerequisite software is present so that
-        users can be notified of potential problems that might affect their build.
-        The class also performs basic user configuration checks from
-        the <code class="filename">local.conf</code> configuration file to
-        prevent common mistakes that cause build failures.
-        Distribution policy usually determines whether to include this class.
-    </p></div><div class="section" title="7.17. Generated output quality assurance checks - insane.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-insane"></a>7.17. Generated output quality assurance checks - <code class="filename">insane.bbclass</code></h2></div></div></div><p>
-        This class adds a step to the package generation process that sanity checks the
-        packages generated by the OpenEmbedded build system.
-        A range of checks are performed that check the build's output
-        for common problems that show up during runtime.
-        Distribution policy usually dictates whether to include this class.
-    </p><p>
-        You can configure the sanity checks so that specific test failures either raise a warning or
-        an error message.
-        Typically, failures for new tests generate a warning.
-        Subsequent failures for the same test would then generate an error message
-        once the metadata is in a known and good condition.
-        You use the <code class="filename">WARN_QA</code> variable to specify tests for which you
-        want to generate a warning message on failure.
-        You use the <code class="filename">ERROR_QA</code> variable to specify tests for which you
-        want to generate an error message on failure.
-    </p><p>
-        The following list shows the tests you can list with the <code class="filename">WARN_QA</code>
-        and <code class="filename">ERROR_QA</code> variables:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><code class="filename">ldflags:</code></em></span>
-                Ensures that the binaries were linked with the
-                <code class="filename">LDFLAGS</code> options provided by the build system.
-                If this test fails, check that the <code class="filename">LDFLAGS</code> variable
-                is being passed to the linker command.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">useless-rpaths:</code></em></span>
-                Checks for dynamic library load paths (rpaths) in the binaries that
-                by default on a standard system are searched by the linker (e.g.
-                <code class="filename">/lib</code> and <code class="filename">/usr/lib</code>).
-                While these paths will not cause any breakage, they do waste space and
-                are unnecessary.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">rpaths:</code></em></span>
-                Checks for rpaths in the binaries that contain build system paths such
-                as <code class="filename">TMPDIR</code>.
-                If this test fails, bad <code class="filename">-rpath</code> options are being
-                passed to the linker commands and your binaries have potential security
-                issues.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">dev-so:</code></em></span>
-                Checks that the <code class="filename">.so</code> symbolic links are in the
-                <code class="filename">-dev</code> package and not in any of the other packages.
-                In general, these symlinks are only useful for development purposes.
-                Thus, the <code class="filename">-dev</code> package is the correct location for
-                them.
-                Some very rare cases do exist for dynamically loaded modules where
-                these symlinks are needed instead in the main package.
-                </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">debug-files:</code></em></span>
-                Checks for <code class="filename">.debug</code> directories in anything but the
-                <code class="filename">-dbg</code> package.
-                The debug files should all be in the <code class="filename">-dbg</code> package.
-                Thus, anything packaged elsewhere is incorrect packaging.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">arch:</code></em></span>
-                Checks the Executable and Linkable Format (ELF) type, bit size and endianness
-                of any binaries to ensure it matches the target architecture.
-                This test fails if any binaries don't match the type since there would be an
-                incompatibility.
-                Sometimes software, like bootloaders, might need to bypass this check.
-                </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">debug-deps:</code></em></span>
-                Checks that <code class="filename">-dbg</code> packages only depend on other
-                <code class="filename">-dbg</code> packages and not on any other types of packages,
-                which would cause a packaging bug.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">dev-deps:</code></em></span>
-                Checks that <code class="filename">-dev</code> packages only depend on other
-                <code class="filename">-dev</code> packages and not on any other types of packages,
-                which would be a packaging bug.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">pkgconfig:</code></em></span>
-                Checks <code class="filename">.pc</code> files for any
-                <code class="filename">TMPDIR/WORKDIR</code> paths.
-                Any <code class="filename">.pc</code> file containing these paths is incorrect
-                since <code class="filename">pkg-config</code> itself adds the correct sysroot prefix
-                when the files are accessed.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">la:</code></em></span>
-                Checks <code class="filename">.la</code> files for any <code class="filename">TMPDIR</code>
-                paths.
-                Any <code class="filename">.la</code> file continaing these paths is incorrect since
-                <code class="filename">libtool</code> adds the correct sysroot prefix when using the
-                files automatically itself.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">desktop:</code></em></span>
-                Runs the <code class="filename">desktop-file-validate</code> program against any
-                <code class="filename">.desktop</code> files to validate their contents against
-                the specification for <code class="filename">.desktop</code> files.</p></li></ul></div><p>
-    </p></div><div class="section" title="7.18. Autotools configuration data cache - siteinfo.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-siteinfo"></a>7.18. Autotools configuration data cache - <code class="filename">siteinfo.bbclass</code></h2></div></div></div><p>
-        Autotools can require tests that must execute on the target hardware.
-        Since this is not possible in general when cross compiling, site information is
-        used to provide cached test results so these tests can be skipped over but
-        still make the correct values available.
-        The <code class="filename"><a class="link" href="#structure-meta-site" title="5.3.18. meta/site/">meta/site directory</a></code>
-        contains test results sorted into different categories such as architecture, endianness, and
-        the <code class="filename">libc</code> used.
-        Site information provides a list of files containing data relevant to
-        the current build in the
-        <code class="filename"><a class="link" href="#var-CONFIG_SITE" title="CONFIG_SITE">CONFIG_SITE</a></code> variable
-        that Autotools automatically picks up.
-    </p><p>
-        The class also provides variables like
-        <code class="filename"><a class="link" href="#var-SITEINFO_ENDIANNESS" title="SITEINFO_ENDIANNESS">SITEINFO_ENDIANNESS</a></code>
-        and <code class="filename"><a class="link" href="#var-SITEINFO_BITS" title="SITEINFO_BITS">SITEINFO_BITS</a></code>
-        that can be used elsewhere in the metadata.
-    </p><p>
-        Because this class is included from <code class="filename">base.bbclass</code>, it is always active.
-    </p></div><div class="section" title="7.19. Adding Users - useradd.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-useradd"></a>7.19. Adding Users - <code class="filename">useradd.bbclass</code></h2></div></div></div><p>
-        If you have packages that install files that are owned by custom users or groups,
-        you can use this class to specify those packages and associate the users and groups
-        with those packages.
-        The <code class="filename">meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</code>
-        recipe in the <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>
-        provides a simple exmample that shows how to add three
-        users and groups to two packages.
-        See the <code class="filename">useradd-example.bb</code> for more information on how to
-        use this class.
-    </p></div><div class="section" title="7.20. Using External Source - externalsrc.bbclass"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-externalsrc"></a>7.20. Using External Source - <code class="filename">externalsrc.bbclass</code></h2></div></div></div><p>
-        You can use this class to build software from source code that is external to the
-        OpenEmbedded build system.
-        In other words, your source code resides in an external tree outside of the Yocto Project.
-        Building software from an external source tree means that the normal fetch, unpack, and
-        patch process is not used.
-    </p><p>
-        To use the class, you need to define the
-        <a class="link" href="#var-S" title="S"><code class="filename">S</code></a> variable to point to the directory that contains the source files.
-        You also need to have your recipe inherit the <code class="filename">externalsrc.bbclass</code> class.
-    </p><p>
-        This class expects the source code to support recipe builds that use the
-        <a class="link" href="#var-B" title="B"><code class="filename">B</code></a> variable to point to the directory in
-        which the OpenEmbedded build system places the generated objects built from the recipes.
-        By default, the <code class="filename">B</code> directory is set to the following, which is separate from the
-        Source Directory (<code class="filename">S</code>):
-        </p><pre class="literallayout">
-     ${WORKDIR}/${BPN}/{PV}/
-        </pre><p>
-        See the glossary entries for the
-        <a class="link" href="#var-WORKDIR" title="WORKDIR"><code class="filename">WORKDIR</code></a>,
-        <a class="link" href="#var-BPN" title="BPN"><code class="filename">BPN</code></a>,
-        <a class="link" href="#var-PV" title="PV"><code class="filename">PV</code></a>,
-        <a class="link" href="#var-S" title="S"><code class="filename">S</code></a>, and
-        <a class="link" href="#var-B" title="B"><code class="filename">B</code></a> for more information.
-    </p><p>
-        You can build object files in the external tree by setting the
-        <code class="filename">B</code> variable equal to <code class="filename">"${S}"</code>.
-        However, this practice does not work well if you use the source for more than one variant
-        (i.e., "natives" such as <code class="filename">quilt-native</code>,
-        or "crosses" such as <code class="filename">gcc-cross</code>).
-        So, be sure there are no "native", "cross", or "multilib" variants of the recipe.
-    </p><p>
-        If you do want to build different variants of a recipe, you can use the
-        <a class="link" href="#var-BBCLASSEXTEND" title="BBCLASSEXTEND"><code class="filename">BBCLASSEXTEND</code></a> variable.
-        When you do, the <a class="link" href="#var-B" title="B"><code class="filename">B</code></a> variable must support the
-        recipe's ability to build variants in different working directories.
-        Most autotools-based recipes support separating these directories.
-        The OpenEmbedded build system defaults to using separate directories for <code class="filename">gcc</code>
-        and some kernel recipes.
-        Alternatively, you can make sure that separate recipes exist that each
-        use the <code class="filename">BBCLASSEXTEND</code> variable to build each variant.
-        The separate recipes can inherit a single target recipe.
-    </p><p>
-        For information on how to use this class, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#building-software-from-an-external-source" target="_top">Building
-        Software from an External Source</a>" section in the Yocto Project Development Manual.
-    </p></div><div class="section" title="7.21. Other Classes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-classes-others"></a>7.21. Other Classes</h2></div></div></div><p>
-        Thus far, this chapter has discussed only the most useful and important
-        classes.
-        However, other classes exist within the <code class="filename">meta/classes</code> directory
-        in the <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-        You can examine the <code class="filename">.bbclass</code> files directly for more
-        information.
-    </p></div></div>
-
-    <div class="chapter" title="Chapter 8. Images"><div class="titlepage"><div><div><h2 class="title"><a id="ref-images"></a>Chapter 8. Images</h2></div></div></div><p>
-        The OpenEmbedded build process supports several types of images to satisfy different needs.
-        When you issue the <code class="filename">bitbake</code> command you provide a “top-level” recipe
-        that essentially begins the build for the type of image you want.
-    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-        Building an image without GNU General Public License Version 3 (GPLv3) components
-        is only supported for minimal and base images.
-        Furthermore, if you are going to build an image using non-GPLv3 components,
-        you must make the following changes in the <code class="filename">local.conf</code> file
-        before using the BitBake command to build the minimal or base image:
-        <pre class="literallayout">
-     1. Comment out the EXTRA_IMAGE_FEATURES line
-     2. Set INCOMPATIBLE_LICENSE = "GPLv3"
-        </pre></div><p>
-        From within the <code class="filename">poky</code> Git repository, use the following command to list
-        the supported images:
-        </p><pre class="literallayout">
-     $ ls meta*/recipes*/images/*.bb
-        </pre><p>
-        These recipes reside in the <code class="filename">meta/recipes-core/images</code>,
-        <code class="filename">meta/recipes-extended/images</code>,
-        <code class="filename">meta/recipes-graphics/images</code>, and
-        <code class="filename">meta/recipes-sato/images</code> directories
-        within the <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">source directory</a>.
-        Although the recipe names are somewhat explanatory, here is a list that describes them:
-    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-base</code>:</em></span>
-            A console-only image that fully supports the target device hardware.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-minimal</code>:</em></span>
-            A small image just capable of allowing a device to boot.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-minimal-dev</code>:</em></span>
-            A <code class="filename">core-image-minimal</code> image suitable for development work
-            using the host.
-            The image includes headers and libraries you can use in a host development
-            environment.
-            </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-minimal-initramfs</code>:</em></span>
-            A <code class="filename">core-image-minimal</code> image that has the Minimal RAM-based
-            Initial Root Filesystem (<code class="filename">initramfs</code>) as part of the kernel,
-            which allows the system to find the first “init” program more efficiently.
-            </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-minimal-mtdutils</code>:</em></span>
-            A <code class="filename">core-image-minimal</code> image that has support
-            for the Minimal MTD Utilities, which let the user interact with the
-            MTD subsystem in the kernel to perform operations on flash devices.
-            </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-x11</code>:</em></span>
-            A very basic X11 image with a terminal.
-            </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-basic</code>:</em></span>
-            A console-only image with more full-featured Linux system
-            functionality installed.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-lsb</code>:</em></span>
-            An image that conforms to the Linux Standard Base (LSB) specification.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-lsb-dev</code>:</em></span>
-            A <code class="filename">core-image-lsb</code> image that is suitable for development work
-            using the host.
-            The image includes headers and libraries you can use in a host development
-            environment.
-            </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-lsb-sdk</code>:</em></span>
-            A <code class="filename">core-image-lsb</code> that includes everything in meta-toolchain
-            but also includes development headers and libraries to form a complete standalone SDK.
-            This image is suitable for development using the target.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-clutter</code>:</em></span>
-            An image with support for the Open GL-based toolkit Clutter, which enables development of
-            rich and animated graphical user interfaces.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-sato</code>:</em></span>
-            An image with Sato support, a mobile environment and visual style that works well
-            with mobile devices.
-            The image supports X11 with a Sato theme and applications such as
-            a terminal, editor, file manager, media player, and so forth.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-sato-dev</code>:</em></span>
-            A <code class="filename">core-image-sato</code> image suitable for development
-            using the host.
-            The image includes libraries needed to build applications on the device itself,
-            testing and profiling tools, and debug symbols.
-            This image was formerly <code class="filename">core-image-sdk</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-sato-sdk</code>:</em></span>
-            A <code class="filename">core-image-sato</code> image that includes everything in meta-toolchain.
-            The image also includes development headers and libraries to form a complete standalone SDK
-            and is suitable for development using the target.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-rt</code>:</em></span>
-            A <code class="filename">core-image-minimal</code> image plus a real-time test suite and
-            tools appropriate for real-time use.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-rt-sdk</code>:</em></span>
-            A <code class="filename">core-image-rt</code> image that includes everything in
-            <code class="filename">meta-toolchain</code>.
-            The image also includes development headers and libraries to form a complete
-            stand-alone SDK and is suitable for development using the target.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-gtk-directfb</code>:</em></span>
-            An image that uses <code class="filename">gtk+</code> over <code class="filename">directfb</code>
-            instead of X11.
-            In order to build, this image requires specific distro configuration that enables
-            <code class="filename">gtk</code> over <code class="filename">directfb</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">build-appliance-image</code>:</em></span>
-            An image you can boot and run using either the
-            <a class="ulink" href="http://www.vmware.com/products/player/overview.html" target="_top">VMware Player</a>
-            or <a class="ulink" href="http://www.vmware.com/products/workstation/overview.html" target="_top">VMware Workstation</a>.
-            For more information on this image, see the
-            <a class="ulink" href="http://www.yoctoproject.org/documentation/build-appliance" target="_top">Build Appliance</a> page on
-            the Yocto Project website.</p></li></ul></div><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3>
-        From the Yocto Project release 1.1 onwards, <code class="filename">-live</code> and
-        <code class="filename">-directdisk</code> images have been replaced by a "live"
-        option in <code class="filename">IMAGE_FSTYPES</code> that will work with any image to produce an
-        image file that can be
-        copied directly to a CD or USB device and run as is.
-        To build a live image, simply add
-        "live" to <code class="filename">IMAGE_FSTYPES</code> within the <code class="filename">local.conf</code>
-        file or wherever appropriate and then build the desired image as normal.
-    </div></div>
-
-    <div class="chapter" title="Chapter 9. Reference: Features"><div class="titlepage"><div><div><h2 class="title"><a id="ref-features"></a>Chapter 9. Reference: Features</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#ref-features-distro">9.1. Distro</a></span></dt><dt><span class="section"><a href="#ref-features-machine">9.2. Machine</a></span></dt><dt><span class="section"><a href="#ref-features-image">9.3. Images</a></span></dt><dt><span class="section"><a href="#ref-features-backfill">9.4. Feature Backfilling</a></span></dt></dl></div><p>
-        Features provide a mechanism for working out which packages
-        should be included in the generated images.
-        Distributions can select which features they want to support through the
-        <code class="filename"><a class="link" href="#var-DISTRO_FEATURES" title="DISTRO_FEATURES">DISTRO_FEATURES</a></code>
-        variable, which is set in the <code class="filename">poky.conf</code> distribution configuration file.
-        Machine features are set in the
-        <code class="filename"><a class="link" href="#var-MACHINE_FEATURES" title="MACHINE_FEATURES">MACHINE_FEATURES</a></code>
-        variable, which is set in the machine configuration file and
-        specifies the hardware features for a given machine.
-    </p><p>
-        These two variables combine to work out which kernel modules,
-        utilities, and other packages to include.
-        A given distribution can support a selected subset of features so some machine features might not
-        be included if the distribution itself does not support them.
-    </p><p>
-        One method you can use to determine which recipes are checking to see if a
-        particular feature is contained or not is to <code class="filename">grep</code> through
-        the metadata for the feature.
-        Here is an example that discovers the recipes whose build is potentially
-        changed based on a given feature:
-        </p><pre class="literallayout">
-     $ cd $HOME/poky
-     $ git grep 'contains.*MACHINE_FEATURES.*&lt;feature&gt;'
-        </pre><p>
-    </p><p>
-        This chapter provides a reference of shipped machine and distro features
-        you can include as part of the image, a reference on image types you can
-        build, and a reference on feature backfilling.
-    </p><div class="section" title="9.1. Distro"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-features-distro"></a>9.1. Distro</h2></div></div></div><p>
-            The items below are features you can use with
-            <a class="link" href="#var-DISTRO_FEATURES" title="DISTRO_FEATURES"><code class="filename">DISTRO_FEATURES</code></a>.
-            Features do not have a one-to-one correspondence to packages, and they can
-            go beyond simply controlling the installation of a package or packages.
-            Sometimes a feature can influence how certain recipes are built.
-            For example, a feature might determine whether a particular configure option
-            is specified within <code class="filename">do_configure</code> for a particular
-            recipe.
-        </p><p>
-            This list only represents features as shipped with the Yocto Project metadata:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>alsa:</em></span> ALSA support will be included (OSS compatibility
-                    kernel modules will be installed if available).</p></li><li class="listitem"><p><span class="emphasis"><em>bluetooth:</em></span> Include bluetooth support (integrated BT only)
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>ext2:</em></span> Include tools for supporting for devices with internal
-                    HDD/Microdrive for storing files (instead of Flash only devices)
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>irda:</em></span> Include Irda support
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>keyboard:</em></span> Include keyboard support (e.g. keymaps will be
-                    loaded during boot).
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>pci:</em></span> Include PCI bus support
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>pcmcia:</em></span> Include PCMCIA/CompactFlash support
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>usbgadget:</em></span> USB Gadget Device support (for USB
-                    networking/serial/storage)
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>usbhost:</em></span> USB Host support (allows to connect external
-                    keyboard, mouse, storage, network etc)
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>wifi:</em></span> WiFi support (integrated only)
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>cramfs:</em></span> CramFS support
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>ipsec:</em></span> IPSec support
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>ipv6:</em></span> IPv6 support
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>nfs:</em></span> NFS client support (for mounting NFS exports on
-                    device)</p></li><li class="listitem"><p><span class="emphasis"><em>ppp:</em></span> PPP dialup support</p></li><li class="listitem"><p><span class="emphasis"><em>smbfs:</em></span> SMB networks client support (for mounting
-                    Samba/Microsoft Windows shares on device)</p></li></ul></div><p>
-        </p></div><div class="section" title="9.2. Machine"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-features-machine"></a>9.2. Machine</h2></div></div></div><p>
-            The items below are features you can use with
-            <a class="link" href="#var-MACHINE_FEATURES" title="MACHINE_FEATURES"><code class="filename">MACHINE_FEATURES</code></a>.
-            Features do not have a one-to-one correspondence to packages, and they can
-            go beyond simply controlling the installation of a package or packages.
-            Sometimes a feature can influence how certain recipes are built.
-            For example, a feature might determine whether a particular configure option
-            is specified within <code class="filename">do_configure</code> for a particular
-            recipe.
-        </p><p>
-            This feature list only represents features as shipped with the Yocto Project metadata:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>acpi:</em></span> Hardware has ACPI (x86/x86_64 only)
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>alsa:</em></span> Hardware has ALSA audio drivers
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>apm:</em></span> Hardware uses APM (or APM emulation)
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>bluetooth:</em></span> Hardware has integrated BT
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>ext2:</em></span> Hardware HDD or Microdrive
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>irda:</em></span> Hardware has Irda support
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>keyboard:</em></span> Hardware has a keyboard
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>pci:</em></span> Hardware has a PCI bus
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>pcmcia:</em></span> Hardware has PCMCIA or CompactFlash sockets
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>screen:</em></span> Hardware has a screen
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>serial:</em></span> Hardware has serial support (usually RS232)
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>touchscreen:</em></span> Hardware has a touchscreen
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>usbgadget:</em></span> Hardware is USB gadget device capable
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>usbhost:</em></span> Hardware is USB Host capable
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>wifi:</em></span> Hardware has integrated WiFi
-                    </p></li></ul></div><p>
-        </p></div><div class="section" title="9.3. Images"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-features-image"></a>9.3. Images</h2></div></div></div><p>
-            The contents of images generated by the OpenEmbedded build system can be controlled by the
-            <code class="filename"><a class="link" href="#var-IMAGE_FEATURES" title="IMAGE_FEATURES">IMAGE_FEATURES</a></code>
-            and <code class="filename"><a class="link" href="#var-EXTRA_IMAGE_FEATURES" title="EXTRA_IMAGE_FEATURES">EXTRA_IMAGE_FEATURES</a></code>
-            variables that you typically configure in your image recipes.
-            Through these variables you can add several different
-            predefined packages such as development utilities or packages with debug
-            information needed to investigate application problems or profile applications.
-        </p><p>
-            Current list of
-            <code class="filename">IMAGE_FEATURES</code> contains the following:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>splash:</em></span> Enables showing a splash screen during boot.
-                    By default, this screen is provided by <code class="filename">psplash</code>, which does
-                    allow customization.
-                    If you prefer to use an alternative splash screen package, you can do so by
-                    setting the <code class="filename">SPLASH</code> variable
-                    to a different package name (or names) within the image recipe or at the distro
-                    configuration level.</p></li><li class="listitem"><p><span class="emphasis"><em>ssh-server-dropbear:</em></span> Installs the Dropbear minimal
-                    SSH server.
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>ssh-server-openssh:</em></span> Installs the OpenSSH SSH server,
-                    which is more full-featured than Dropbear.
-                    Note that if both the OpenSSH SSH server and the Dropbear minimal SSH server
-                    are present in <code class="filename">IMAGE_FEATURES</code>, then OpenSSH will take
-                    precedence and Dropbear will not be installed.</p></li><li class="listitem"><p><span class="emphasis"><em>x11:</em></span> Installs the X server</p></li><li class="listitem"><p><span class="emphasis"><em>x11-base:</em></span> Installs the X server with a
-                    minimal environment.</p></li><li class="listitem"><p><span class="emphasis"><em>x11-sato:</em></span> Installs the OpenedHand Sato environment.
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>tools-sdk:</em></span> Installs a full SDK that runs on the device.
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>tools-debug:</em></span> Installs debugging tools such as
-                    <code class="filename">strace</code> and <code class="filename">gdb</code>.
-                    </p></li><li class="listitem"><p><span class="emphasis"><em>tools-profile:</em></span> Installs profiling tools such as
-                    <code class="filename">oprofile</code>, <code class="filename">exmap</code>, and
-                    <code class="filename">LTTng</code>.</p></li><li class="listitem"><p><span class="emphasis"><em>tools-testapps:</em></span> Installs device testing tools (e.g.
-                    touchscreen debugging).</p></li><li class="listitem"><p><span class="emphasis"><em>nfs-server:</em></span> Installs an NFS server.</p></li><li class="listitem"><p><span class="emphasis"><em>dev-pkgs:</em></span> Installs development packages (headers and
-                    extra library links) for all packages installed in a given image.</p></li><li class="listitem"><p><span class="emphasis"><em>staticdev-pkgs:</em></span> Installs static development
-                    packages (i.e. static libraries containing <code class="filename">*.a</code> files) for all
-                    packages installed in a given image.</p></li><li class="listitem"><p><span class="emphasis"><em>dbg-pkgs:</em></span> Installs debug symbol packages for all packages
-                    installed in a given image.</p></li><li class="listitem"><p><span class="emphasis"><em>doc-pkgs:</em></span> Installs documentation packages for all packages
-                    installed in a given image.</p></li></ul></div><p>
-        </p></div><div class="section" title="9.4. Feature Backfilling"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-features-backfill"></a>9.4. Feature Backfilling</h2></div></div></div><p>
-            Sometimes it is necessary in the OpenEmbedded build system to extend
-            <a class="link" href="#var-MACHINE_FEATURES" title="MACHINE_FEATURES"><code class="filename">MACHINE_FEATURES</code></a>
-            or <a class="link" href="#var-DISTRO_FEATURES" title="DISTRO_FEATURES"><code class="filename">DISTRO_FEATURES</code></a>
-            to control functionality that was previously enabled and not able
-            to be disabled.
-            For these cases, we need to add an
-            additional feature item to appear in one of these variables,
-            but we do not want to force developers who have existing values
-            of the variables in their configuration to add the new feature
-            in order to retain the same overall level of functionality.
-            Thus, the OpenEmbedded build system has a mechanism to
-            automatically "backfill" these added features into existing
-            distro or machine configurations.
-            You can see the list of features for which this is done by
-            finding the
-            <a class="link" href="#var-DISTRO_FEATURES_BACKFILL" title="DISTRO_FEATURES_BACKFILL"><code class="filename">DISTRO_FEATURES_BACKFILL</code></a>
-            and <a class="link" href="#var-MACHINE_FEATURES_BACKFILL" title="MACHINE_FEATURES_BACKFILL"><code class="filename">MACHINE_FEATURES_BACKFILL</code></a>
-            variables in the <code class="filename">meta/conf/bitbake.conf</code> file.
-        </p><p>
-            Because such features are backfilled by default into all
-            configurations as described in the previous paragraph, developers
-            who wish to disable the new features need to be able to selectively
-            prevent the backfilling from occurring.
-            They can do this by adding the undesired feature or features to the
-            <a class="link" href="#var-DISTRO_FEATURES_BACKFILL_CONSIDERED" title="DISTRO_FEATURES_BACKFILL_CONSIDERED"><code class="filename">DISTRO_FEATURES_BACKFILL_CONSIDERED</code></a>
-            or <a class="link" href="#var-MACHINE_FEATURES_BACKFILL_CONSIDERED" title="MACHINE_FEATURES_BACKFILL_CONSIDERED"><code class="filename">MACHINE_FEATURES_BACKFILL_CONSIDERED</code></a>
-            variables for distro features and machine features respectively.
-        </p><p>
-            Here are two examples to help illustrate feature backfilling:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>The "pulseaudio" distro feature option</em></span>:
-                    Previously, PulseAudio support was enabled within the Qt and
-                    GStreamer frameworks.
-                    Because of this, the feature is backfilled and thus
-                    enabled for all distros through the
-                    <code class="filename">DISTRO_FEATURES_BACKFILL</code>
-                    variable in the <code class="filename">meta/conf/bitbake.conf</code> file.
-                    However, your distro needs to disable the feature.
-                    You can disable the feature without affecting
-                    other existing distro configurations that need PulseAudio support
-                    by adding "pulseaudio" to
-                    <code class="filename">DISTRO_FEATURES_BACKFILL_CONSIDERED</code>
-                    in your distro's <code class="filename">.conf</code> file.
-                    Adding the feature to this variable when it also
-                    exists in the <code class="filename">DISTRO_FEATURES_BACKFILL</code>
-                    variable prevents the build system from adding the feature to
-                    your configuration's <code class="filename">DISTRO_FEATURES</code>, effectively disabling
-                    the feature for that particular distro.</p></li><li class="listitem"><p><span class="emphasis"><em>The "rtc" machine feature option</em></span>:
-                    Previously, real time clock (RTC) support was enabled for all
-                    target devices.
-                    Because of this, the feature is backfilled and thus enabled
-                    for all machines through the <code class="filename">MACHINE_FEATURES_BACKFILL</code>
-                    variable in the <code class="filename">meta/conf/bitbake.conf</code> file.
-                    However, your target device does not have this capability.
-                    You can disable RTC support for your device without
-                    affecting other machines that need RTC support
-                    by adding the feature to your machine's
-                    <code class="filename">MACHINE_FEATURES_BACKFILL_CONSIDERED</code>
-                    list in the machine's <code class="filename">.conf</code> file.
-                    Adding the feature to this variable when it also
-                    exists in the <code class="filename">MACHINE_FEATURES_BACKFILL</code>
-                    variable prevents the build system from adding the feature to
-                    your configuration's <code class="filename">MACHINE_FEATURES</code>, effectively
-                    disabling RTC support for that particular machine.</p></li></ul></div><p>
-        </p></div></div>
-
-    <div class="chapter" title="Chapter 10. Variables Glossary"><div class="titlepage"><div><div><h2 class="title"><a id="ref-variables-glos"></a>Chapter 10. Variables Glossary</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="glossary"><a href="#ref-variables-glossary">Glossary</a></span></dt></dl></div><p>
-    This chapter lists common variables used in the OpenEmbedded build system and gives an overview
-    of their function and contents.
-</p><div class="glossary" title="Glossary"><div class="titlepage"><div><div><h2 class="title"><a id="ref-variables-glossary"></a>Glossary</h2></div></div></div><p>
-       <a class="link" href="#var-ALLOW_EMPTY" title="ALLOW_EMPTY">A</a>
-       <a class="link" href="#var-B" title="B">B</a>
-       <a class="link" href="#var-CFLAGS" title="CFLAGS">C</a>
-       <a class="link" href="#var-D" title="D">D</a>
-       <a class="link" href="#var-ENABLE_BINARY_LOCALE_GENERATION" title="ENABLE_BINARY_LOCALE_GENERATION">E</a>
-       <a class="link" href="#var-FILES" title="FILES">F</a>
-
-       <a class="link" href="#var-HOMEPAGE" title="HOMEPAGE">H</a>
-       <a class="link" href="#var-IMAGE_FEATURES" title="IMAGE_FEATURES">I</a>
-
-       <a class="link" href="#var-KBRANCH" title="KBRANCH">K</a>
-       <a class="link" href="#var-LAYERDIR" title="LAYERDIR">L</a>
-       <a class="link" href="#var-MACHINE" title="MACHINE">M</a>
-
-       <a class="link" href="#var-OE_TERMINAL" title="OE_TERMINAL">O</a>
-       <a class="link" href="#var-P" title="P">P</a>
-
-       <a class="link" href="#var-RCONFLICTS" title="RCONFLICTS">R</a>
-       <a class="link" href="#var-S" title="S">S</a>
-       <a class="link" href="#var-T" title="T">T</a>
-
-
-       <a class="link" href="#var-WORKDIR" title="WORKDIR">W</a>
-
-
-
-    </p><div class="glossdiv" title="A"><h3 class="title">A</h3><dl><dt><a id="var-ALLOW_EMPTY"></a>ALLOW_EMPTY</dt><dd><p>
-                   Specifies if an output package should still be produced if it is empty.
-                   By default, BitBake does not produce empty packages.
-                   This default behavior can cause issues when there is an
-                   <a class="link" href="#var-RDEPENDS" title="RDEPENDS"><code class="filename">RDEPENDS</code></a> or
-                   some other runtime hard-requirement on the existence of the package.
-                </p><p>
-                   Like all package-controlling variables, you must always use them in
-                   conjunction with a package name override.
-                   Here is an example:
-                   </p><pre class="literallayout">
-     ALLOW_EMPTY_${PN} = "1"
-                   </pre><p>
-                </p></dd><dt><a id="var-AUTHOR"></a>AUTHOR</dt><dd><p>The email address used to contact the original author or authors in
-                    order to send patches, forward bugs, etc.</p></dd><dt><a id="var-AUTOREV"></a>AUTOREV</dt><dd><p>When <code class="filename"><a class="link" href="#var-SRCREV" title="SRCREV">SRCREV</a></code>
-                    is set to the value of this variable, it specifies that the latest
-                    source revision in the repository should be used. Here is an example:
-                    </p><pre class="literallayout">
-     SRCREV = "${AUTOREV}"
-                    </pre><p>
-                </p></dd></dl></div><div class="glossdiv" title="B"><h3 class="title">B</h3><dl><dt><a id="var-B"></a>B</dt><dd><p>
-                    The <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                    The OpenEmbedded build system places generated objects into the Build Directory
-                    during a recipe's build process.
-                    By default, this directory is the same as the <a class="link" href="#var-S" title="S"><code class="filename">S</code></a>
-                    directory:
-                    </p><pre class="literallayout">
-     B = ${WORKDIR}/${BPN}/{PV}/
-                    </pre><p>
-                    You can separate the (<code class="filename">S</code>) directory and the directory pointed to
-                    by the <code class="filename">B</code> variable.
-                    Most autotools-based recipes support separating these directories.
-                    The build system defaults to using separate directories for <code class="filename">gcc</code>
-                    and some kernel recipes.
-                </p></dd><dt><a id="var-BAD_RECOMMENDATIONS"></a>BAD_RECOMMENDATIONS</dt><dd><p>
-                    A list of packages not to install despite being recommended by a recipe.
-                    Support for this variable exists only when using the
-                    <code class="filename">ipk</code> packaging backend.
-                </p></dd><dt><a id="var-BB_DISKMON_DIRS"></a>BB_DISKMON_DIRS</dt><dd><p>
-                    Monitors disk space and available inodes during the build
-                    and allows you to control the build based on these
-                    parameters.
-                </p><p>
-                    Disk space monitoring is disabled by default.
-                    To enable monitoring, add the <code class="filename">BB_DISKMON_DIRS</code>
-                    variable to your <code class="filename">conf/local.conf</code> file found in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                    Use the following form:
-                    </p><pre class="literallayout">
-     BB_DISKMON_DIRS = "&lt;action&gt;,&lt;dir&gt;,&lt;threshold&gt; [...]"
-
-     where:
-
-        &lt;action&gt; is:
-           ABORT:     Immediately abort the build when
-                      a threshold is broken.
-           STOPTASKS: Stop the build after the currently
-                      executing tasks have finished when
-                      a threshold is broken.
-           WARN:      Issue a warning but continue the
-                      build when a threshold is broken.
-                      Subsequent warnings are issued as
-                      defined by the
-                      <a class="link" href="#var-BB_DISKMON_WARNINTERVAL" title="BB_DISKMON_WARNINTERVAL">BB_DISKMON_WARNINTERVAL</a> variable,
-                      which must be defined in the
-                      conf/local.conf file.
-
-        &lt;dir&gt; is:
-           Any directory you choose. You can specify one or
-           more directories to monitor by separating the
-           groupings with a space.  If two directories are
-           on the same device, only the first directory
-           is monitored.
-
-        &lt;threshold&gt; is:
-           Either the minimum available disk space,
-           the minimum number of free inodes, or
-           both.  You must specify at least one.  To
-           omit one or the other, simply omit the value.
-           Specify the threshold using G, M, K for Gbytes,
-           Mbytes, and Kbytes, respectively. If you do
-           not specify G, M, or K, Kbytes is assumed by
-           default.  Do not use GB, MB, or KB.
-                    </pre><p>
-                </p><p>
-                    Here are some examples:
-                    </p><pre class="literallayout">
-     BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
-     BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
-     BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
-                    </pre><p>
-                    The first example works only if you also provide
-                    the <a class="link" href="#var-BB_DISKMON_WARNINTERVAL" title="BB_DISKMON_WARNINTERVAL"><code class="filename">BB_DISKMON_WARNINTERVAL</code></a> variable
-                    in the <code class="filename">conf/local.conf</code>.
-                    This example causes the build system to immediately
-                    abort when either the disk space in <code class="filename">${TMPDIR}</code> drops
-                    below 1 Gbyte or the available free inodes drops below
-                    100 Kbytes.
-                    Because two directories are provided with the variable, the
-                    build system also issue a
-                    warning when the disk space in the
-                    <code class="filename">${SSTATE_DIR}</code> directory drops
-                    below 1 Gbyte or the number of free inodes drops
-                    below 100 Kbytes.
-                    Subsequent warnings are issued during intervals as
-                    defined by the <code class="filename">BB_DISKMON_WARNINTERVAL</code>
-                    variable.
-                </p><p>
-                    The second example stops the build after all currently
-                    executing tasks complete when the minimum disk space
-                    in the <code class="filename">${TMPDIR}</code> directory drops
-                    below 1 Gbyte.
-                    No disk monitoring occurs for the free inodes in this case.
-                </p><p>
-                    The final example immediately aborts the build when the
-                    number of free inodes in the <code class="filename">${TMPDIR}</code> directory
-                    drops below 100 Kbytes.
-                    No disk space monitoring for the directory itself occurs
-                    in this case.
-                </p></dd><dt><a id="var-BB_DISKMON_WARNINTERVAL"></a>BB_DISKMON_WARNINTERVAL</dt><dd><p>
-                    Defines the disk space and free inode warning intervals.
-                    To set these intervals, define the variable in your
-                    <code class="filename">conf/local.conf</code> file in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                </p><p>
-                    If you are going to use the
-                    <code class="filename">BB_DISKMON_WARNINTERVAL</code> variable, you must
-                    also use the
-                    <a class="link" href="#var-BB_DISKMON_DIRS" title="BB_DISKMON_DIRS"><code class="filename">BB_DISKMON_DIRS</code></a> variable
-                    and define its action as "WARN".
-                    During the build, subsequent warnings are issued each time
-                    disk space or number of free inodes further reduces by
-                    the respective interval.
-                </p><p>
-                    If you do not provide a <code class="filename">BB_DISKMON_WARNINTERVAL</code>
-                    variable and you do use <code class="filename">BB_DISKMON_DIRS</code> with
-                    the "WARN" action, the disk monitoring interval defaults to
-                    the following:
-                    </p><pre class="literallayout">
-     BB_DISKMON_WARNINTERVAL = "50M,5K"
-                    </pre><p>
-                </p><p>
-                    When specifying the variable in your configuration file,
-                    use the following form:
-                    </p><pre class="literallayout">
-     BB_DISKMON_WARNINTERVAL = "&lt;disk_space_interval&gt;,&lt;disk_inode_interval&gt;"
-
-     where:
-
-        &lt;disk_space_interval&gt; is:
-           An interval of memory expressed in either
-           G, M, or K for Gbytes, Mbytes, or Kbytes,
-           respectively. You cannot use GB, MB, or KB.
-
-        &lt;disk_inode_interval&gt; is:
-           An interval of free inodes expressed in either
-           G, M, or K for Gbytes, Mbytes, or Kbytes,
-           respectively. You cannot use GB, MB, or KB.
-                    </pre><p>
-                </p><p>
-                    Here is an example:
-                    </p><pre class="literallayout">
-     BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
-     BB_DISKMON_WARNINTERVAL = "50M,5K"
-                    </pre><p>
-                    These variables cause the OpenEmbedded build system to
-                    issue subsequent warnings each time the available
-                    disk space further reduces by 50 Mbytes or the number
-                    of free inodes further reduces by 5 Kbytes in the
-                    <code class="filename">${SSTATE_DIR}</code> directory.
-                    Subsequent warnings based on the interval occur each time
-                    a respective interval is reached beyond the intial warning
-                    (i.e. 1 Gbytes and 100 Kbytes).
-                </p></dd><dt><a id="var-BBCLASSEXTEND"></a>BBCLASSEXTEND</dt><dd><p>
-                    Allows you to extend a recipe so that it builds variants of the software.
-                    Common variants for recipes exist such as "natives" like <code class="filename">quilt-native</code>,
-                    which is a copy of quilt built to run on the build system;
-                    "crosses" such as <code class="filename">gcc-cross</code>,
-                    which is a compiler built to run on the build machine but produces binaries
-                    that run on the target <a class="link" href="#var-MACHINE" title="MACHINE"><code class="filename">MACHINE</code></a>;
-                    "nativesdk", which targets the SDK machine instead of <code class="filename">MACHINE</code>;
-                    and "mulitlibs" in the form "<code class="filename">multilib:&lt;multilib_name&gt;</code>".
-                </p><p>
-                    To build a different variant of the recipe with a minimal amount of code, it usually
-                    is as simple as adding the following to your recipe:
-                    </p><pre class="literallayout">
-     BBCLASSEXTEND =+ "native nativesdk"
-     BBCLASSEXTEND =+ "multilib:&lt;multilib_name&gt;"
-                    </pre><p>
-                </p></dd><dt><a id="var-BBMASK"></a>BBMASK</dt><dd><p>Prevents BitBake from processing recipes and recipe append files.
-                    You can use the <code class="filename">BBMASK</code> variable to "hide"
-                    these <code class="filename">.bb</code> and <code class="filename">.bbappend</code> files.
-                    BitBake ignores any recipe or recipe append files that match the expression.
-                    It is as if BitBake does not see them at all.
-                    Consequently, matching files are not parsed or otherwise used by
-                    BitBake.</p><p>The value you provide is passed to python's regular expression compiler.
-                    For complete syntax information, see python's documentation at
-                    <a class="ulink" href="http://docs.python.org/release/2.3/lib/re-syntax.html" target="_top">http://docs.python.org/release/2.3/lib/re-syntax.html</a>.
-                    The expression is compared against the full paths to the files.
-                    For example, the following uses a complete regular expression to tell
-                    BitBake to ignore all recipe and recipe append files in the
-                    <code class="filename">.*/meta-ti/recipes-misc/</code> directory:
-                    </p><pre class="literallayout">
-     BBMASK = ".*/meta-ti/recipes-misc/"
-                    </pre><p>Use the <code class="filename">BBMASK</code> variable from within the
-                    <code class="filename">conf/local.conf</code> file found
-                    in the <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.</p></dd><dt><a id="var-BB_NUMBER_THREADS"></a>BB_NUMBER_THREADS</dt><dd><p>The maximum number of tasks BitBake should run in parallel at any one time.
-                    If your host development system supports multiple cores a good rule of thumb
-                    is to set this variable to twice the number of cores.</p></dd><dt><a id="var-BBFILE_COLLECTIONS"></a>BBFILE_COLLECTIONS</dt><dd><p>Lists the names of configured layers.
-                    These names are used to find the other <code class="filename">BBFILE_*</code>
-                    variables.
-                    Typically, each layer will append its name to this variable in its
-                    <code class="filename">conf/layer.conf</code> file.
-                </p></dd><dt><a id="var-BBFILE_PATTERN"></a>BBFILE_PATTERN</dt><dd><p>Variable that expands to match files from <code class="filename">BBFILES</code> in a particular layer.
-                    This variable is used in the <code class="filename">conf/layer.conf</code> file and must
-                    be suffixed with the name of the specific layer (e.g.
-                    <code class="filename">BBFILE_PATTERN_emenlow</code>).</p></dd><dt><a id="var-BBFILE_PRIORITY"></a>BBFILE_PRIORITY</dt><dd><p>Assigns the priority for recipe files in each layer.</p><p>This variable is useful in situations where the same recipe appears in
-                    more than one layer.
-                    Setting this variable allows you to prioritize a
-                    layer against other layers that contain the same recipe - effectively
-                    letting you control the precedence for the multiple layers.
-                    The precedence established through this variable stands regardless of a
-                    recipe's version (<code class="filename">PV</code> variable).
-                    For example, a layer that has a recipe with a higher <code class="filename">PV</code> value but for
-                    which the <code class="filename">BBFILE_PRIORITY</code> is set to have a lower precedence still has a
-                    lower precedence.</p><p>A larger value for the <code class="filename">BBFILE_PRIORITY</code> variable results in a higher
-                    precedence.
-                    For example, the value 6 has a higher precedence than the value 5.
-                    If not specified, the <code class="filename">BBFILE_PRIORITY</code> variable is set based on layer
-                    dependencies (see the
-                    <code class="filename"><a class="link" href="#var-LAYERDEPENDS" title="LAYERDEPENDS">LAYERDEPENDS</a></code> variable for
-                    more information.
-                    The default priority, if unspecified
-                    for a layer with no dependencies, is the lowest defined priority + 1
-                    (or 1 if no priorities are defined).</p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3>
-                    You can use the command <code class="filename">bitbake-layers show_layers</code> to list
-                    all configured layers along with their priorities.
-                </div></dd><dt><a id="var-BBFILES"></a>BBFILES</dt><dd><p>List of recipe files used by BitBake to build software</p></dd><dt><a id="var-BBPATH"></a>BBPATH</dt><dd><p>Used by BitBake to locate <code class="filename">.bbclass</code> and configuration files.
-                    This variable is analogous to the <code class="filename">PATH</code> variable.</p></dd><dt><a id="var-BBINCLUDELOGS"></a>BBINCLUDELOGS</dt><dd><p>Variable that controls how BitBake displays logs on build failure.</p></dd><dt><a id="var-BBLAYERS"></a>BBLAYERS</dt><dd><p>Lists the layers to enable during the build.
-                    This variable is defined in the <code class="filename">bblayers.conf</code> configuration
-                    file in the <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                    Here is an example:
-                    </p><pre class="literallayout">
-     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 \
-       "
-                    </pre><p>
-                    This example enables four layers, one of which is a custom, user-defined layer
-                    named <code class="filename">meta-mykernel</code>.
-                </p></dd><dt><a id="var-BBLAYERS_NON_REMOVABLE"></a>BBLAYERS_NON_REMOVABLE</dt><dd><p>Lists core layers that cannot be removed from the
-                    <code class="filename">bblayers.conf</code> file.
-                    In order for BitBake to build your image, your
-                    <code class="filename">bblayers.conf</code> file must include the
-                    <code class="filename">meta</code> and <code class="filename">meta-yocto</code>
-                    core layers.
-                    Here is an example that shows these two layers listed in
-                    the <code class="filename">BBLAYERS_NON_REMOVABLE</code> statement:
-                    </p><pre class="literallayout">
-     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 \
-       "
-                    </pre><p>
-                </p></dd><dt><a id="var-BP"></a>BP</dt><dd><p>The base recipe name and version but without any special
-                    recipe name suffix (i.e. <code class="filename">-native</code>, <code class="filename">lib64-</code>,
-                    and so forth).
-                    <code class="filename">BP</code> is comprised of the following:
-                    </p><pre class="literallayout">
-     ${BPN}-${PV}
-                    </pre></dd><dt><a id="var-BPN"></a>BPN</dt><dd><p>The bare name of the recipe.
-                    This variable is a version of the <a class="link" href="#var-PN" title="PN"><code class="filename">PN</code></a> variable
-                    but removes common suffixes such as "-native" and "-cross" as well
-                    as removes common prefixes such as multilib's "lib64-" and "lib32-".
-                    The exact list of suffixes removed is specified by the
-                    <a class="link" href="#var-SPECIAL_PKGSUFFIX" title="SPECIAL_PKGSUFFIX"><code class="filename">SPECIAL_PKGSUFFIX</code></a> variable.
-                    The exact list of prefixes removed is specified by the
-                    <a class="link" href="#var-MLPREFIX" title="MLPREFIX"><code class="filename">MLPREFIX</code></a> variable.
-                    Prefixes are removed for multilib and nativesdk cases.</p></dd></dl></div><div class="glossdiv" title="C"><h3 class="title">C</h3><dl><dt><a id="var-CFLAGS"></a>CFLAGS</dt><dd><p>
-                    Flags passed to C compiler for the target system.
-                    This variable evaluates to the same as
-                    <code class="filename"><a class="link" href="#var-TARGET_CFLAGS" title="TARGET_CFLAGS">TARGET_CFLAGS</a></code>.
-                </p></dd><dt><a id="var-COMBINED_FEATURES"></a>COMBINED_FEATURES</dt><dd><p>A set of features common between
-                    <a class="link" href="#var-MACHINE_FEATURES" title="MACHINE_FEATURES"><code class="filename">MACHINE_FEATURES</code></a>
-                    and <a class="link" href="#var-DISTRO_FEATURES" title="DISTRO_FEATURES"><code class="filename">DISTRO_FEATURES</code></a>.
-                    See the glossary descriptions for these variables for more information.</p></dd><dt><a id="var-COMPATIBLE_MACHINE"></a>COMPATIBLE_MACHINE</dt><dd><p>A regular expression which evaluates to match the machines the recipe
-                    works with.
-                    It stops recipes being run on machines for which they are not compatible.
-                    This is particularly useful with kernels.
-                    It also helps to increase parsing speed as further parsing of the recipe is skipped
-                    if it is found the current machine is not compatible.</p></dd><dt><a id="var-CONFFILES"></a>CONFFILES</dt><dd><p>
-                    Identifies editable or configurable files that are part of a package.
-                    If the Package Management System (PMS) is being used to update
-                    packages on the target system, it is possible that
-                    configuration files you have changed after the original installation
-                    and that you now want to remain unchanged are overwritten.
-                    In other words, editable files might exist in the package that you do not
-                    want reset as part of the package update process.
-                    You can use the <code class="filename">CONFFILES</code> variable to list the files in the
-                    package that you wish to prevent the PMS from overwriting during this update process.
-                </p><p>
-                    To use the <code class="filename">CONFFILES</code> variable, provide a package name
-                    override that identifies the resulting package.
-                    Then, provide a space-separated list of files.
-                    Here is an example:
-                    </p><pre class="literallayout">
-  CONFFILES_${PN} += "${sysconfdir}/file1 \
-     ${sysconfdir}/file2 ${sysconfdir}/file3"
-                    </pre><p>
-                </p><p>
-                    A relationship exists between the <code class="filename">CONFFILES</code> and
-                    <code class="filename"><a class="link" href="#var-FILES" title="FILES">FILES</a></code> variables.
-                    The files listed within <code class="filename">CONFFILES</code> must be a subset of
-                    the files listed within <code class="filename">FILES</code>.
-                    Because the configuration files you provide with <code class="filename">CONFFILES</code>
-                    are simply being identified so that the PMS will not overwrite them,
-                    it makes sense that
-                    the files must already be included as part of the package through the
-                    <code class="filename">FILES</code> variable.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    When specifying paths as part of the <code class="filename">CONFFILES</code> variable,
-                    it is good practice to use appropriate path variables.
-                    For example, <code class="filename">${sysconfdir}</code> rather than
-                    <code class="filename">/etc</code> or <code class="filename">${bindir}</code> rather
-                    than <code class="filename">/usr/bin</code>.
-                    You can find a list of these variables at the top of the
-                    <code class="filename">/meta/conf/bitbake.conf</code> file in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-                </div></dd><dt><a id="var-CONFIG_SITE"></a>CONFIG_SITE</dt><dd><p>
-                    A list of files that contains <code class="filename">autoconf</code> test results relevant
-                    to the current build.
-                    This variable is used by the Autotools utilities when running
-                    <code class="filename">configure</code>.
-                </p></dd><dt><a id="var-CORE_IMAGE_EXTRA_INSTALL"></a>CORE_IMAGE_EXTRA_INSTALL</dt><dd><p>
-                    Specifies the list of packages to be added to the image.
-                    This variable should only be set in the <code class="filename">local.conf</code>
-                    configuration file found in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                </p><p>
-                    This variable replaces <code class="filename">POKY_EXTRA_INSTALL</code>, which is no longer supported.
-                </p></dd></dl></div><div class="glossdiv" title="D"><h3 class="title">D</h3><dl><dt><a id="var-D"></a>D</dt><dd><p>The destination directory.</p></dd><dt><a id="var-DEBUG_BUILD"></a>DEBUG_BUILD</dt><dd><p>
-                    Specifies to build packages with debugging information.
-                    This influences the value of the
-                    <code class="filename"><a class="link" href="#var-SELECTED_OPTIMIZATION" title="SELECTED_OPTIMIZATION">SELECTED_OPTIMIZATION</a></code>
-                    variable.
-                </p></dd><dt><a id="var-DEBUG_OPTIMIZATION"></a>DEBUG_OPTIMIZATION</dt><dd><p>
-                    The options to pass in
-                    <code class="filename"><a class="link" href="#var-TARGET_CFLAGS" title="TARGET_CFLAGS">TARGET_CFLAGS</a></code>
-                    and <code class="filename"><a class="link" href="#var-CFLAGS" title="CFLAGS">CFLAGS</a></code> when compiling
-                    a system for debugging.
-                    This variable defaults to "-O -fno-omit-frame-pointer -g".
-                </p></dd><dt><a id="var-DEFAULT_PREFERENCE"></a>DEFAULT_PREFERENCE</dt><dd><p>Specifies the priority of recipes.</p></dd><dt><a id="var-DEPENDS"></a>DEPENDS</dt><dd><p>
-                    Lists a recipe's build-time dependencies
-                    (i.e. other recipe files).
-                    The system ensures that all the dependencies listed
-                    have been built and have their contents in the appropriate
-                    sysroots before the recipe's configure task is executed.
-                </p></dd><dt><a id="var-DESCRIPTION"></a>DESCRIPTION</dt><dd><p>The package description used by package managers.
-                      If not set, <code class="filename">DESCRIPTION</code> takes
-                      the value of the
-                      <a class="link" href="#var-SUMMARY" title="SUMMARY"><code class="filename">SUMMARY</code></a>
-                      variable.
-                </p></dd><dt><a id="var-DESTDIR"></a>DESTDIR</dt><dd><p>the destination directory.</p></dd><dt><a id="var-DISTRO"></a>DISTRO</dt><dd><p>
-                    The short name of the distribution.
-                    This variable corresponds to a file with the
-                    extension <code class="filename">.conf</code>
-                    located in a <code class="filename">conf/distro</code> directory
-                    within the metadata that contains the distribution configuration.
-                    The
-                    value must not contain spaces, and is typically all lower-case.
-                </p><p>
-                    If the variable is blank, a set of default configuration
-                    will be used, which is specified
-                    within <code class="filename">meta/conf/distro/defaultsetup.conf</code>.
-                </p></dd><dt><a id="var-DISTRO_EXTRA_RDEPENDS"></a>DISTRO_EXTRA_RDEPENDS</dt><dd><p>
-                    Specifies a list of distro-specific packages to add to all images.
-                    This variable takes affect through
-                    <code class="filename">packagegroup-base</code> so the
-                    variable only really applies to the more full-featured
-                    images that include <code class="filename">packagegroup-base</code>.
-                    You can use this variable to keep distro policy out of
-                    generic images.
-                    As with all other distro variables, you set this variable
-                    in the distro <code class="filename">.conf</code> file.
-                </p></dd><dt><a id="var-DISTRO_EXTRA_RRECOMMENDS"></a>DISTRO_EXTRA_RRECOMMENDS</dt><dd><p>
-                    Specifies a list of distro-specific packages to add to all images
-                    if the packages exist.
-                    The packages might not exist or be empty (e.g. kernel modules).
-                    The list of packages are automatically installed but can be
-                    removed by the user.
-                </p></dd><dt><a id="var-DISTRO_FEATURES"></a>DISTRO_FEATURES</dt><dd><p>The features enabled for the distribution.
-                    For a list of features supported by the Yocto Project as shipped,
-                    see the "<a class="link" href="#ref-features-distro" title="9.1. Distro">Distro</a>"
-                    section.
-                </p></dd><dt><a id="var-DISTRO_FEATURES_BACKFILL"></a>DISTRO_FEATURES_BACKFILL</dt><dd><p>Features to be added to
-                    <code class="filename"><a class="link" href="#var-DISTRO_FEATURES" title="DISTRO_FEATURES">DISTRO_FEATURES</a></code>
-                    if not also present in
-                    <code class="filename"><a class="link" href="#var-DISTRO_FEATURES_BACKFILL_CONSIDERED" title="DISTRO_FEATURES_BACKFILL_CONSIDERED">DISTRO_FEATURES_BACKFILL_CONSIDERED</a></code>.
-                </p><p>
-                    This variable is set in the <code class="filename">meta/conf/bitbake.conf</code> file.
-                    It is not intended to be user-configurable.
-                    It is best to just reference the variable to see which distro features are
-                    being backfilled for all distro configurations.
-                    See the <a class="link" href="#ref-features-backfill" title="9.4. Feature Backfilling">Feature backfilling</a> section for
-                    more information.
-                </p></dd><dt><a id="var-DISTRO_FEATURES_BACKFILL_CONSIDERED"></a>DISTRO_FEATURES_BACKFILL_CONSIDERED</dt><dd><p>Features from
-                    <code class="filename"><a class="link" href="#var-DISTRO_FEATURES_BACKFILL" title="DISTRO_FEATURES_BACKFILL">DISTRO_FEATURES_BACKFILL</a></code>
-                    that should not backfilled (i.e. added to
-                    <code class="filename"><a class="link" href="#var-DISTRO_FEATURES" title="DISTRO_FEATURES">DISTRO_FEATURES</a></code>)
-                    during the build.
-                    See the "<a class="link" href="#ref-features-backfill" title="9.4. Feature Backfilling">Feature Backfilling</a>" section for
-                    more information.
-                    </p></dd><dt><a id="var-DISTRO_NAME"></a>DISTRO_NAME</dt><dd><p>The long name of the distribution.</p></dd><dt><a id="var-DISTRO_PN_ALIAS"></a>DISTRO_PN_ALIAS</dt><dd><p>Alias names used for the recipe in various Linux distributions.</p><p>See the
-                    "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#usingpoky-configuring-DISTRO_PN_ALIAS" target="_top">Handling
-                    a Package Name Alias</a>" section in the Yocto Project Development
-                    Manual for more information.</p></dd><dt><a id="var-DISTRO_VERSION"></a>DISTRO_VERSION</dt><dd><p>the version of the distribution.</p></dd><dt><a id="var-DL_DIR"></a>DL_DIR</dt><dd><p>
-                    The central download directory used by the build process to store downloads.
-                    You can set this directory by defining the <code class="filename">DL_DIR</code>
-                    variable in the <code class="filename">/conf/local.conf</code> file.
-                    This directory is self-maintaining and you should not have
-                    to touch it.
-                    By default, the directory is <code class="filename">downloads</code> in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                    </p><pre class="literallayout">
-     #DL_DIR ?= "${TOPDIR}/downloads"
-                    </pre><p>
-                    To specify a different download directory, simply uncomment the line
-                    and provide your directory.
-                </p><p>
-                    During a first build, the system downloads many different source code
-                    tarballs from various upstream projects.
-                    Downloading can take a while, particularly if your network
-                    connection is slow.
-                    Tarballs are all stored in the directory defined by
-                    <code class="filename">DL_DIR</code> and the build system looks there first
-                    to find source tarballs.
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                        When wiping and rebuilding, you can preserve this directory to speed
-                        up this part of subsequent builds.
-                    </div><p>
-                </p><p>
-                    You can safely share this directory between multiple builds on the
-                    same development machine.
-                    For additional information on how the build process gets source files
-                    when working behind a firewall or proxy server, see the
-                    "<a class="link" href="#how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server">FAQ</a>"
-                    chapter.
-                </p></dd></dl></div><div class="glossdiv" title="E"><h3 class="title">E</h3><dl><dt><a id="var-ENABLE_BINARY_LOCALE_GENERATION"></a>ENABLE_BINARY_LOCALE_GENERATION</dt><dd><p></p><p>Variable that controls which locales for <code class="filename">eglibc</code> are
-                    to be generated during the build (useful if the target device has 64Mbytes
-                    of RAM or less).</p></dd><dt><a id="var-EXTENDPE"></a>EXTENDPE</dt><dd><p>
-                    Used with file and pathnames to create a prefix for a recipe's
-                    version based on the recipe's
-                    <a class="link" href="#var-PE" title="PE"><code class="filename">PE</code></a> value.
-                    If <code class="filename">PE</code> is set and greater than zero for a recipe,
-                    <code class="filename">EXTENDPE</code> becomes that value (e.g if
-                    <code class="filename">PE</code> is equal to "1" then <code class="filename">EXTENDPE</code>
-                    becomes "1_").
-                    If a recipe's <code class="filename">PE</code> is not set (the default) or is equal to
-                    zero, <code class="filename">EXTENDPE</code> becomes "".</p><p>See the <a class="link" href="#var-STAMP" title="STAMP"><code class="filename">STAMP</code></a>
-                    variable for an example.
-                </p></dd><dt><a id="var-EXTRA_IMAGE_FEATURES"></a>EXTRA_IMAGE_FEATURES</dt><dd><p>Allows extra packages to be added to the generated images.
-                    You set this variable in the <code class="filename">local.conf</code>
-                    configuration file.
-                    Note that some image features are also added using the
-                    <code class="filename"><a class="link" href="#var-IMAGE_FEATURES" title="IMAGE_FEATURES">IMAGE_FEATURES</a></code>
-                    variable generally configured in image recipes.
-                    You can use this variable to add more features in addition to those.
-                    Here are some examples of features you can add:</p><pre class="literallayout">
-"dbg-pkgs" - Adds -dbg packages for all installed packages
-             including symbol information for debugging and
-             profiling.
-
-"dev-pkgs" - Adds -dev packages for all installed packages.
-             This is useful if you want to develop against
-             the libraries in the image.
-
-"tools-sdk" - Adds development tools such as gcc, make,
-              pkgconfig and so forth.
-
-"tools-debug" - Adds debugging tools such as gdb and
-                strace.
-
-"tools-profile" - Adds profiling tools such as oprofile,
-                  exmap, lttng and valgrind (x86 only).
-
-"tools-testapps" - Adds useful testing tools such as
-                   ts_print, aplay, arecord and so
-                   forth.
-
-"debug-tweaks" - Makes an image suitable for development.
-                 For example, ssh root access has a blank
-                 password.  You should remove this feature
-                 before you produce a production image.
-                    </pre><p>There are other valid features too, see the
-                 <a class="link" href="#ref-features-image" title="9.3. Images">Images</a>
-                 section for more details.</p></dd><dt><a id="var-EXTRA_IMAGEDEPENDS"></a>EXTRA_IMAGEDEPENDS</dt><dd><p>A list of recipes to be built that do not provide packages to be installed in
-                    the root filesystem.
-                </p><p>Sometimes a recipe is required to build the final image but is not
-                    needed in the root filesystem.
-                    You can use the <code class="filename">EXTRA_IMAGEDEPENDS</code> variable to
-                    list these recipes and thus, specify the dependencies.
-                    A typical example is a required bootloader in a machine configuration.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    To add packages to the root filesystem, see the various
-                    <code class="filename">*DEPENDS</code> and <code class="filename">*RECOMMENDS</code>
-                    variables.
-                </div></dd><dt><a id="var-EXTRA_OECMAKE"></a>EXTRA_OECMAKE</dt><dd><p>Additional <code class="filename">cmake</code> options.</p></dd><dt><a id="var-EXTRA_OECONF"></a>EXTRA_OECONF</dt><dd><p>Additional <code class="filename">configure</code> script options.</p></dd><dt><a id="var-EXTRA_OEMAKE"></a>EXTRA_OEMAKE</dt><dd><p>Additional GNU <code class="filename">make</code> options.</p></dd></dl></div><div class="glossdiv" title="F"><h3 class="title">F</h3><dl><dt><a id="var-FILES"></a>FILES</dt><dd><p>
-                    The list of directories or files that are placed in packages.
-                </p><p>
-                    To use the <code class="filename">FILES</code> variable, provide a package name
-                    override that identifies the resulting package.
-                    Then, provide a space-separated list of files or paths that identifies the
-                    files you want included as part of the resulting package.
-                    Here is an example:
-                    </p><pre class="literallayout">
-  FILES_${PN} += "${bindir}/mydir1/ ${bindir}/mydir2/myfile"
-                    </pre><p>
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    When specifying paths as part of the <code class="filename">FILES</code> variable,
-                    it is good practice to use appropriate path variables.
-                    For example, <code class="filename">${sysconfdir}</code> rather than
-                    <code class="filename">/etc</code> or <code class="filename">${bindir}</code> rather
-                    than <code class="filename">/usr/bin</code>.
-                    You can find a list of these variables at the top of the
-                    <code class="filename">/meta/conf/bitbake.conf</code> file in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-                </div><p>
-                    If some of the files you provide with the <code class="filename">FILES</code> variable
-                    are editable and you know they should not be
-                    overwritten during the package update process by the Package Management
-                    System (PMS), you can identify these files so that the PMS will not
-                    overwrite them.
-                    See the <code class="filename"><a class="link" href="#var-CONFFILES" title="CONFFILES">CONFFILES</a></code>
-                    variable for information on how to identify these files to the PMS.
-                </p></dd><dt><a id="var-FILESEXTRAPATHS"></a>FILESEXTRAPATHS</dt><dd><p>
-                    Extends the search path the OpenEmbedded build system uses when
-                    looking for files and patches as it processes recipes.
-                    The directories BitBake uses when it processes recipes is defined by the
-                    <a class="link" href="#var-FILESPATH" title="FILESPATH"><code class="filename">FILESPATH</code></a> variable.
-                    You can add directories to the search path by defining the
-                    <code class="filename">FILESEXTRAPATHS</code> variable.
-                </p><p>
-                    To add paths to the search order, provide a list of directories and separate
-                    each path using a colon character as follows:
-                    </p><pre class="literallayout">
-     FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
-                    </pre><p>
-                    Typically, you want your directories searched first.
-                    To make sure that happens, use <code class="filename">_prepend</code> and
-                    the immediate expansion (<code class="filename">:=</code>) operator as shown in the
-                    previous example.
-                    Finally, to maintain the integrity of the <code class="filename">FILESPATH</code> variable,
-                    you must include the appropriate beginning or ending (as needed) colon character.
-                </p><p>
-                    The <code class="filename">FILESEXTRAPATHS</code> variable is intended for use in
-                    <code class="filename">.bbappend</code> files to include any additional files provided in that layer.
-                    You typically accomplish this with the following:
-                    </p><pre class="literallayout">
-     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-                    </pre><p>
-                </p></dd><dt><a id="var-FILESPATH"></a>FILESPATH</dt><dd><p>
-                    The default set of directories the OpenEmbedded build system uses
-                    when searching for patches and files.
-                    During the build process, BitBake searches each directory in
-                    <code class="filename">FILESPATH</code> in the specified order when looking for
-                    files and patches specified by each <code class="filename">file://</code> URI in a recipe.
-                </p><p>
-                    The default value for the <code class="filename">FILESPATH</code> variable is defined
-                    in the <code class="filename">base.bbclass</code> class found in
-                    <code class="filename">meta/classes</code> in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>:
-                    </p><pre class="literallayout">
-FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
-   "${FILE_DIRNAME}/${P}", "${FILE_DIRNAME}/${PN}", \
-   "${FILE_DIRNAME}/${BP}", "${FILE_DIRNAME}/${BPN}", \
-   "${FILE_DIRNAME}/files", "${FILE_DIRNAME}" ], d)}"
-                    </pre><p>
-                    Do not hand-edit the <code class="filename">FILESPATH</code> variable.
-                    If you want to extend the set of pathnames that BitBake uses when searching for
-                    files and patches, use the
-                    <a class="link" href="#var-FILESEXTRAPATHS" title="FILESEXTRAPATHS"><code class="filename">FILESEXTRAPATHS</code></a> variable.
-                </p></dd><dt><a id="var-FILESYSTEM_PERMS_TABLES"></a>FILESYSTEM_PERMS_TABLES</dt><dd><p>Allows you to define your own file permissions settings table as part of
-                    your configuration for the packaging process.
-                    For example, suppose you need a consistent set of custom permissions for
-                    a set of groups and users across an entire work project.
-                    It is best to do this in the packages themselves but this is not always
-                    possible.
-                </p><p>
-                    By default, the OpenEmbedded build system uses the <code class="filename">fs-perms.txt</code>, which
-                    is located in the <code class="filename">meta/files</code> folder in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-                    If you create your own file permissions setting table, you should place it in your
-                    layer or the distros layer.
-                </p><p>
-                    You define the <code class="filename">FILESYSTEM_PERMS_TABLES</code> variable in the
-                    <code class="filename">conf/local.conf</code> file, which is found in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>, to
-                    point to your custom <code class="filename">fs-perms.txt</code>.
-                    You can specify more than a single file permissions setting table.
-                    The paths you specify to these files must be defined within the
-                    <code class="filename">BBPATH</code> variable.
-                </p><p>
-                    For guidance on how to create your own file permissions settings table file,
-                    examine the existing <code class="filename">fs-perms.txt</code>.
-                </p></dd><dt><a id="var-FULL_OPTIMIZATION"></a>FULL_OPTIMIZATION</dt><dd><p>
-                    The options to pass in
-                    <code class="filename"><a class="link" href="#var-TARGET_CFLAGS" title="TARGET_CFLAGS">TARGET_CFLAGS</a></code>
-                    and <code class="filename"><a class="link" href="#var-CFLAGS" title="CFLAGS">CFLAGS</a></code>
-                    when compiling an optimized system.
-                    This variable defaults to
-                    "-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2".
-                </p></dd></dl></div><div class="glossdiv" title="H"><h3 class="title">H</h3><dl><dt><a id="var-HOMEPAGE"></a>HOMEPAGE</dt><dd><p>Website where more information about the software the recipe is building
-                    can be found.</p></dd></dl></div><div class="glossdiv" title="I"><h3 class="title">I</h3><dl><dt><a id="var-IMAGE_FEATURES"></a>IMAGE_FEATURES</dt><dd><p>The list of features to include in an image.
-                Typically, you configure this variable in an image recipe.
-                Note that you can also add extra features to the image by using the
-                <code class="filename"><a class="link" href="#var-EXTRA_IMAGE_FEATURES" title="EXTRA_IMAGE_FEATURES">EXTRA_IMAGE_FEATURES</a></code> variable.
-                See the "<a class="link" href="#ref-features-image" title="9.3. Images">Images</a>" section for the
-                full list of features that can be included in images built by the
-                OpenEmbedded build system.</p></dd><dt><a id="var-IMAGE_FSTYPES"></a>IMAGE_FSTYPES</dt><dd><p>Formats of root filesystem images that you want to have created.</p></dd><dt><a id="var-IMAGE_INSTALL"></a>IMAGE_INSTALL</dt><dd><p>
-                    Specifies the packages to install into an image.
-                    The <code class="filename">IMAGE_INSTALL</code> variable is a mechanism for an image
-                    recipe and you should use it with care to avoid ordering issues.
-                </p><p>
-                    Image recipes set <code class="filename">IMAGE_INSTALL</code> to specify the
-                    packages to install into an image through <code class="filename">image.bbclass</code>.
-                    Additionally, "helper" classes exist, such as <code class="filename">core-image.bbclass</code>,
-                    that can take
-                    <code class="filename"><a class="link" href="#var-IMAGE_FEATURES" title="IMAGE_FEATURES">IMAGE_FEATURES</a></code> lists
-                    and turn these into auto-generated entries in
-                    <code class="filename">IMAGE_INSTALL</code> in addition to its default contents.
-                </p><p>
-                    Using <code class="filename">IMAGE_INSTALL</code> with the <code class="filename">+=</code>
-                    operator from the <code class="filename">/conf/local.conf</code> file or from within
-                    an image recipe is not recommended as it can cause ordering issues.
-                    Since <code class="filename">core-image.bbclass</code> sets <code class="filename">IMAGE_INSTALL</code>
-                    to a default value using the <code class="filename">?=</code> operator, using a
-                    <code class="filename">+=</code> operation against <code class="filename">IMAGE_INSTALL</code>
-                    will result in unexpected behavior when used in
-                    <code class="filename">/conf/local.conf</code>.
-                    Furthermore, the same operation from with an image recipe may or may not
-                    succeed depending on the specific situation.
-                    In both these cases, the behavior is contrary to how most users expect
-                    the <code class="filename">+=</code> operator to work.
-                </p><p>
-                    When you use this variable, it is best to use it as follows:
-                    </p><pre class="literallayout">
-     IMAGE_INSTALL_append = " package-name"
-                    </pre><p>
-                    Be sure to include the space between the quotation character and the start of the
-                    package name.
-                </p></dd><dt><a id="var-IMAGE_OVERHEAD_FACTOR"></a>IMAGE_OVERHEAD_FACTOR</dt><dd><p>
-                    Defines a multiplier that the build system applies to the initial image
-                    size for cases when the multiplier times the returned disk usage value
-                    for the image is greater than the sum of
-                    <code class="filename"><a class="link" href="#var-IMAGE_ROOTFS_SIZE" title="IMAGE_ROOTFS_SIZE">IMAGE_ROOTFS_SIZE</a></code>
-                    and
-                    <code class="filename"><a class="link" href="#var-IMAGE_ROOTFS_EXTRA_SPACE" title="IMAGE_ROOTFS_EXTRA_SPACE">IMAGE_ROOTFS_EXTRA_SPACE</a></code>.
-                    The result of the multiplier applied to the initial image size creates
-                    free disk space in the image as overhead.
-                    By default, the build process uses a multiplier of 1.3 for this variable.
-                    This default value results in 30% free disk space added to the image when this
-                    method is used to determine the final generated image size.
-                    You should be aware that post install scripts and the package management
-                    system uses disk space inside this overhead area.
-                    Consequently, the multiplier does not produce an image with
-                    all the theoretical free disk space.
-                    See <code class="filename"><a class="link" href="#var-IMAGE_ROOTFS_SIZE" title="IMAGE_ROOTFS_SIZE">IMAGE_ROOTFS_SIZE</a></code>
-                    for information on how the build system determines the overall image size.
-                </p><p>
-                    The default 30% free disk space typically gives the image enough room to boot
-                    and allows for basic post installs while still leaving a small amount of
-                    free disk space.
-                    If 30% free space is inadequate, you can increase the default value.
-                    For example, the following setting gives you 50% free space added to the image:
-                    </p><pre class="literallayout">
-     IMAGE_OVERHEAD_FACTOR = "1.5"
-                    </pre><p>
-                </p><p>
-                    Alternatively, you can ensure a specific amount of free disk space is added
-                    to the image by using
-                    <code class="filename"><a class="link" href="#var-IMAGE_ROOTFS_EXTRA_SPACE" title="IMAGE_ROOTFS_EXTRA_SPACE">IMAGE_ROOTFS_EXTRA_SPACE</a></code>
-                    the variable.
-                </p></dd><dt><a id="var-IMAGE_ROOTFS_EXTRA_SPACE"></a>IMAGE_ROOTFS_EXTRA_SPACE</dt><dd><p>
-                    Defines additional free disk space created in the image in Kbytes.
-                    By default, this variable is set to "0".
-                    This free disk space is added to the image after the build system determines
-                    the image size as described in
-                    <code class="filename"><a class="link" href="#var-IMAGE_ROOTFS_SIZE" title="IMAGE_ROOTFS_SIZE">IMAGE_ROOTFS_SIZE</a></code>.
-                </p><p>
-                    This variable is particularly useful when you want to ensure that a
-                    specific amount of free disk space is available on a device after an image
-                    is installed and running.
-                    For example, to be sure 5 Gbytes of free disk space is available, set the
-                    variable as follows:
-                    </p><pre class="literallayout">
-     IMAGE_ROOTFS_EXTRA_SPACE = "5242880"
-                    </pre><p>
-                </p></dd><dt><a id="var-IMAGE_ROOTFS_SIZE"></a>IMAGE_ROOTFS_SIZE</dt><dd><p>
-                    Defines the size in Kbytes for the generated image.
-                    The OpenEmbedded build system determines the final size for the generated
-                    image using an algorithm that takes into account the initial disk space used
-                    for the generated image, a requested size for the image, and requested
-                    additional free disk space to be added to the image.
-                    Programatically, the build system determines the final size of the
-                    generated image as follows:
-                    </p><pre class="literallayout">
-    if (image-du * overhead) &lt; rootfs-size:
-	internal-rootfs-size = rootfs-size + xspace
-    else:
-	internal-rootfs-size = (image-du * overhead) + xspace
-
-    where:
-
-      image-du = Returned value of the du command on
-                 the image.
-
-      overhead = IMAGE_OVERHEAD_FACTOR
-
-      rootfs-size = IMAGE_ROOTFS_SIZE
-
-      internal-rootfs-size = Initial root filesystem
-                             size before any modifications.
-
-      xspace = IMAGE_ROOTFS_EXTRA_SPACE
-                    </pre><p>
-
-                </p></dd><dt><a id="var-INC_PR"></a>INC_PR</dt><dd><p>Helps define the recipe revision for recipes that share
-                    a common <code class="filename">include</code> file.
-                    You can think of this variable as part of the recipe revision
-                    as set from within an include file.</p><p>Suppose, for example, you have a set of recipes that
-                    are used across several projects.
-                    And, within each of those recipes the revision
-                    (its <code class="filename">PR</code> value) is set accordingly.
-                    In this case, when the revision of those recipes changes
-                    the burden is on you to find all those recipes and
-                    be sure that they get changed to reflect the updated
-                    version of the recipe.
-                    In this scenario, it can get complicated when recipes
-                    used in many places and that provide common functionality
-                    are upgraded to a new revision.</p><p>A more efficient way of dealing with this situation is
-                    to set the <code class="filename">INC_PR</code> variable inside
-                    the <code class="filename">include</code> files that the recipes
-                    share and then expand the <code class="filename">INC_PR</code>
-                    variable within the recipes to help
-                    define the recipe revision.
-                    </p><p>
-                    The following provides an example that shows how to use
-                    the <code class="filename">INC_PR</code> variable
-                    given a common <code class="filename">include</code> file that
-                    defines the variable.
-                    Once the variable is defined in the
-                    <code class="filename">include</code> file, you can use the
-                    variable to set the <code class="filename">PR</code> values in
-                    each recipe.
-                    You will notice that when you set a recipe's
-                    <code class="filename">PR</code> you can provide more granular
-                    revisioning by appending values to the
-                    <code class="filename">INC_PR</code> variable:
-                    </p><pre class="literallayout">
-recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
-recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
-recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
-recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
-                    </pre><p>
-                    The first line of the example establishes the baseline
-                    revision to be used for all recipes that use the
-                    <code class="filename">include</code> file.
-                    The remaining lines in the example are from individual
-                    recipes and show how the <code class="filename">PR</code> value
-                    is set.</p></dd><dt><a id="var-INHIBIT_PACKAGE_STRIP"></a>INHIBIT_PACKAGE_STRIP</dt><dd><p>
-                    Causes the build to not strip binaries in resulting packages.
-                </p></dd><dt><a id="var-INHERIT"></a>INHERIT</dt><dd><p>
-                    Causes the named class to be inherited at
-                    this point during parsing.
-                    The variable is only valid in configuration files.
-                </p></dd><dt><a id="var-INITSCRIPT_PACKAGES"></a>INITSCRIPT_PACKAGES</dt><dd><p>
-                    A list of the packages that contain initscripts.
-                    If multiple packages are specified, you need to append the package name
-                    to the other <code class="filename">INITSCRIPT_*</code> as an override.</p><p>
-                    This variable is used in recipes when using <code class="filename">update-rc.d.bbclass</code>.
-                    The variable is optional and defaults to the <code class="filename">PN</code> variable.
-                </p></dd><dt><a id="var-INITSCRIPT_NAME"></a>INITSCRIPT_NAME</dt><dd><p>
-                    The filename of the initscript (as installed to <code class="filename">${etcdir}/init.d)</code>.
-                </p><p>
-                    This variable is used in recipes when using <code class="filename">update-rc.d.bbclass</code>.
-                    The variable is Mandatory.
-                </p></dd><dt><a id="var-INITSCRIPT_PARAMS"></a>INITSCRIPT_PARAMS</dt><dd><p>
-                    Specifies the options to pass to <code class="filename">update-rc.d</code>.
-                    An example is <code class="filename">start 99 5 2 . stop 20 0 1 6 .</code>, which gives the script a
-                    runlevel of 99, starts the script in initlevels 2 and 5, and
-                    stops the script in levels 0, 1 and 6.
-                </p><p>
-                    The variable is mandatory and is used in recipes when using
-                    <code class="filename">update-rc.d.bbclass</code>.
-                </p></dd></dl></div><div class="glossdiv" title="K"><h3 class="title">K</h3><dl><dt><a id="var-KBRANCH"></a>KBRANCH</dt><dd><p>
-                    A regular expression used by the build process to explicitly identify the kernel
-                    branch that is validated, patched and configured during a build.
-                    The <code class="filename">KBRANCH</code> variable is optional.
-                    You can use it to trigger checks to ensure the exact kernel branch you want is
-                    being used by the build process.
-                </p><p>
-                    Values for this variable are set in the kernel's recipe file and the kernel's
-                    append file.
-                    For example, if you are using the Yocto Project kernel that is based on the
-                    Linux 3.4 kernel, the kernel recipe file is the
-                    <code class="filename">meta/recipes-kernel/linux/linux-yocto_3.4.bb</code> file.
-                    Following is the default value for <code class="filename">KBRANCH</code> and the default
-                    override for the architectures the Yocto Project supports:
-                    </p><pre class="literallayout">
-     KBRANCH_DEFAULT = "standard/base"
-     KBRANCH = "${KBRANCH_DEFAULT}"
-                    </pre><p>
-                    This branch exists in the <code class="filename">linux-yocto-3.4</code> kernel Git
-                    repository <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.4/refs/heads" target="_top">http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.4/refs/heads</a>.
-                </p><p>
-                    This variable is also used from the kernel's append file to identify the kernel
-                    branch specific to a particular machine or target hardware.
-                    The kernel's append file is located in the BSP layer for a given machine.
-                    For example, the kernel append file for the Crown Bay BSP is in the
-                    <code class="filename">meta-intel</code> Git repository and is named
-                    <code class="filename">meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend</code>.
-                    Here are the related statements from the append file:
-                    </p><pre class="literallayout">
-     COMPATIBLE_MACHINE_crownbay = "crownbay"
-     KMACHINE_crownbay  = "crownbay"
-     KBRANCH_crownbay  = "standard/crownbay"
-
-     COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
-     KMACHINE_crownbay-noemgd  = "crownbay"
-     KBRANCH_crownbay-noemgd  = "standard/crownbay"
-                    </pre><p>
-                        The <code class="filename">KBRANCH_*</code> statements identify the kernel branch to
-                        use when building for the Crown Bay BSP.
-                        In this case there are two identical statements: one for each type of
-                        Crown Bay machine.
-                </p></dd><dt><a id="var-KERNEL_FEATURES"></a>KERNEL_FEATURES</dt><dd><p>Includes additional metadata from the Yocto Project kernel Git repository.
-                    In the OpenEmbedded build system, the default Board Support Packages (BSPs)
-                    metadata is provided through
-                    the <code class="filename">KMACHINE</code> and <code class="filename">KBRANCH</code> variables.
-                    You can use the <code class="filename">KERNEL_FEATURES</code> variable to further
-                    add metadata for all BSPs.</p><p>The metadata you add through this variable includes config fragments and
-                    features descriptions,
-                    which usually includes patches as well as config fragments.
-                    You typically override the <code class="filename">KERNEL_FEATURES</code> variable
-                    for a specific machine.
-                    In this way, you can provide validated, but optional, sets of kernel
-                    configurations and features.</p><p>For example, the following adds <code class="filename">netfilter</code> to all
-                    the Yocto Project kernels and adds sound support to the <code class="filename">qemux86</code>
-                    machine:
-                    </p><pre class="literallayout">
-     # Add netfilter to all linux-yocto kernels
-     KERNEL_FEATURES="features/netfilter"
-
-     # Add sound support to the qemux86 machine
-     KERNEL_FEATURES_append_qemux86=" cfg/sound"
-                    </pre></dd><dt><a id="var-KERNEL_IMAGETYPE"></a>KERNEL_IMAGETYPE</dt><dd><p>The type of kernel to build for a device, usually set by the
-                    machine configuration files and defaults to "zImage".
-                    This variable is used
-                    when building the kernel and is passed to <code class="filename">make</code> as the target to
-                    build.</p></dd><dt><a id="var-KMACHINE"></a>KMACHINE</dt><dd><p>
-                    The machine as known by the kernel.
-                    Sometimes the machine name used by the kernel does not match the machine name
-                    used by the OpenEmbedded build system.
-                    For example, the machine name that the OpenEmbedded build system understands as
-                    <code class="filename">qemuarm</code> goes by a different name in the Linux Yocto kernel.
-                    The kernel understands that machine as <code class="filename">arm_versatile926ejs</code>.
-                    For cases like these, the <code class="filename">KMACHINE</code> variable maps the
-                    kernel machine name to the OpenEmbedded build system machine name.
-                </p><p>
-                    Kernel machine names are initially defined in the
-                    <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi" target="_top">Yocto Linux Kernel</a> in
-                    the <code class="filename">meta</code> branch.
-                    From the <code class="filename">meta</code> branch, look in
-                    the <code class="filename">meta/cfg/kernel-cache/bsp/&lt;bsp_name&gt;/&lt;bsp-name&gt;-&lt;kernel-type&gt;.scc</code> file.
-                    For example, from the <code class="filename">meta</code> branch in the
-                    <code class="filename">linux-yocto-3.0</code> kernel, the
-                    <code class="filename">meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc</code> file
-                    has the following:
-                    </p><pre class="literallayout">
-     define KMACHINE cedartrail
-     define KTYPE standard
-     define KARCH i386
-
-     include ktypes/standard
-     branch cedartrail
-
-     include cedartrail.scc
-                    </pre><p>
-                    You can see that the kernel understands the machine name for the Cedar Trail BSP as
-                    <code class="filename">cedartrail</code>.
-                </p><p>
-                    If you look in the Cedar Trail BSP layer in the <code class="filename">meta-intel</code> source
-                    repository at <code class="filename">meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend</code>,
-                    you will find the following statements among others:
-                    </p><pre class="literallayout">
-     COMPATIBLE_MACHINE_cedartrail = "cedartrail"
-     KMACHINE_cedartrail  = "cedartrail"
-     KBRANCH_cedartrail  = "yocto/standard/cedartrail"
-     KERNEL_FEATURES_append_cedartrail += "bsp/cedartrail/cedartrail-pvr-merge.scc"
-     KERNEL_FEATURES_append_cedartrail += "cfg/efi-ext.scc"
-
-     COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
-     KMACHINE_cedartrail-nopvr  = "cedartrail"
-     KBRANCH_cedartrail-nopvr  = "yocto/standard/cedartrail"
-     KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
-                    </pre><p>
-                    The <code class="filename">KMACHINE</code> statements in the kernel's append file make sure that
-                    the OpenEmbedded build system and the Yocto Linux kernel understand the same machine
-                    names.
-                </p><p>
-                    This append file uses two <code class="filename">KMACHINE</code> statements.
-                    The first is not really necessary but does ensure that the machine known to the
-                    OpenEmbedded build system as <code class="filename">cedartrail</code> maps to the machine
-                    in the kernel also known as <code class="filename">cedartrail</code>:
-                    </p><pre class="literallayout">
-     KMACHINE_cedartrail  = "cedartrail"
-                    </pre><p>
-                </p><p>
-                    The second statement is a good example of why the <code class="filename">KMACHINE</code> variable
-                    is needed.
-                    In this example, the OpenEmbedded build system uses the <code class="filename">cedartrail-nopvr</code>
-                    machine name to refer to the Cedar Trail BSP that does not support the propriatory
-                    PowerVR driver.
-                    The kernel, however, uses the machine name <code class="filename">cedartrail</code>.
-                    Thus, the append file must map the <code class="filename">cedartrail-nopvr</code> machine name to
-                    the kernel's <code class="filename">cedartrail</code> name:
-                    </p><pre class="literallayout">
-     KMACHINE_cedartrail-nopvr  = "cedartrail"
-                    </pre><p>
-                </p><p>
-                    BSPs that ship with the Yocto Project release provide all mappings between the Yocto
-                    Project kernel machine names and the OpenEmbedded machine names.
-                    Be sure to use the <code class="filename">KMACHINE</code> if you create a BSP and the machine
-                    name you use is different than that used in the kernel.
-                </p></dd></dl></div><div class="glossdiv" title="L"><h3 class="title">L</h3><dl><dt><a id="var-LAYERDEPENDS"></a>LAYERDEPENDS</dt><dd><p>Lists the layers that this recipe depends upon, separated by spaces.
-                    Optionally, you can specify a specific layer version for a dependency
-                    by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
-                    to be compared against <code class="filename">LAYERVERSION_anotherlayer</code> in this case).
-                    An error will be produced if any dependency is missing or
-                    the version numbers do not match exactly (if specified).
-                    This variable is used in the <code class="filename">conf/layer.conf</code> file
-                    and must be suffixed with the name of the specific layer (e.g.
-                    <code class="filename">LAYERDEPENDS_mylayer</code>).</p></dd><dt><a id="var-LAYERDIR"></a>LAYERDIR</dt><dd><p>When used inside the <code class="filename">layer.conf</code> configuration
-                    file, this variable provides the path of the current layer.
-                    This variable requires immediate expansion
-                    (see the BitBake manual) as lazy expansion can result in
-                    the expansion happening in the wrong directory and therefore
-                    giving the wrong value.</p></dd><dt><a id="var-LAYERVERSION"></a>LAYERVERSION</dt><dd><p>Optionally specifies the version of a layer as a single number.
-                    You can use this within <code class="filename">LAYERDEPENDS</code> for another layer in order to
-                    depend on a specific version of the layer.
-                    This variable is used in the <code class="filename">conf/layer.conf</code> file
-                    and must be suffixed with the name of the specific layer (e.g.
-                    <code class="filename">LAYERVERSION_mylayer</code>).</p></dd><dt><a id="var-LIC_FILES_CHKSUM"></a>LIC_FILES_CHKSUM</dt><dd><p>Checksums of the license text in the recipe source code.</p><p>This variable tracks changes in license text of the source
-                    code files.
-                    If the license text is changed, it will trigger a build
-                    failure, which gives the developer an opportunity to review any
-                    license change.</p><p>
-                    This variable must be defined for all recipes (unless <code class="filename">LICENSE</code>
-                    is set to "CLOSED")</p><p>For more information, see the
-                    <a class="link" href="#usingpoky-configuring-LIC_FILES_CHKSUM" title="3.4.1. Tracking License Changes">
-                    Tracking License Changes</a> section</p></dd><dt><a id="var-LICENSE"></a>LICENSE</dt><dd><p>
-                    The list of source licenses for the recipe.
-                    Follow these rules:
-                    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Do not use spaces within individual
-                            license names.</p></li><li class="listitem"><p>Separate license names using
-                            | (pipe) when there is a choice between licenses.
-                            </p></li><li class="listitem"><p>Separate license names using
-                            &amp; (ampersand) when multiple licenses exist
-                            that cover different parts of the source.
-                            </p></li><li class="listitem"><p>You can use spaces between license
-                            names.</p></li></ul></div><p>
-                </p><p>
-                    Here are some examples:
-                    </p><pre class="literallayout">
-     LICENSE = "LGPLv2.1 | GPLv3"
-     LICENSE = "MPL-1 &amp; LGPLv2.1"
-     LICENSE = "GPLv2+"
-                    </pre><p>
-                    The first example is from the recipes for Qt, which the user
-                    may choose to distribute under either the LGPL version
-                    2.1 or GPL version 3.
-                    The second example is from Cairo where two licenses cover
-                    different parts of the source code.
-                    The final example is from <code class="filename">sysstat</code>,
-                    which presents a single license.
-                </p></dd><dt><a id="var-LICENSE_PATH"></a>LICENSE_PATH</dt><dd><p>Path to additional licenses used during the build.
-                    By default, the OpenEmbedded build system uses <code class="filename">COMMON_LICENSE_DIR</code>
-                    to define the directory that holds common license text used during the build.
-                    The <code class="filename">LICENSE_PATH</code> variable allows you to extend that
-                    location to other areas that have additional licenses:
-                    </p><pre class="literallayout">
-  LICENSE_PATH += "/path/to/additional/common/licenses"
-                    </pre></dd></dl></div><div class="glossdiv" title="M"><h3 class="title">M</h3><dl><dt><a id="var-MACHINE"></a>MACHINE</dt><dd><p>
-                    Specifies the target device for which the image is built.
-                    You define <code class="filename">MACHINE</code> in the
-                    <code class="filename">local.conf</code> file found in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                    By default, <code class="filename">MACHINE</code> is set to
-                    "qemux86", which is an x86-based architecture machine to
-                    be emulated using QEMU:
-                    </p><pre class="literallayout">
-     MACHINE ?= "qemux86"
-                    </pre><p>
-                    The variable corresponds to a machine configuration file of the
-                    same name, through which machine-specific configurations are set.
-                    Thus, when <code class="filename">MACHINE</code> is set to "qemux86" there
-                    exists the corresponding <code class="filename">qemux86.conf</code> machine
-                    configuration file, which can be found in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>
-                    in <code class="filename">meta/conf/machine</code>.
-                </p><p>
-                    The list of machines supported by the Yocto Project as
-                    shipped include the following:
-                    </p><pre class="literallayout">
-     MACHINE ?= "qemuarm"
-     MACHINE ?= "qemumips"
-     MACHINE ?= "qemuppc"
-     MACHINE ?= "qemux86"
-     MACHINE ?= "qemux86-64"
-     MACHINE ?= "atom-pc"
-     MACHINE ?= "beagleboard"
-     MACHINE ?= "mpc8315e-rdb"
-     MACHINE ?= "routerstationpro"
-                    </pre><p>
-                    The last four are Yocto Project reference hardware boards, which
-                    are provided in the <code class="filename">meta-yocto-bsp</code> layer.
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>Adding additional Board Support Package (BSP) layers
-                        to your configuration adds new possible settings for
-                        <code class="filename">MACHINE</code>.
-                    </div><p>
-                </p></dd><dt><a id="var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS"></a>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</dt><dd><p></p><p>
-                    A list of required machine-specific packages to install as part of
-                    the image being built.
-                    The build process depends on these packages being present.
-                    Furthermore, because this is a "machine essential" variable, the list of
-                    packages are essential for the machine to boot.
-                    The impact of this variable affects images based on
-                    <code class="filename">packagegroup-core-boot</code>,
-                    including the <code class="filename">core-image-minimal</code> image.
-                </p><p>
-                    This variable is similar to the
-                    <code class="filename"><a class="link" href="#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS" title="MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS">MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</a></code>
-                    variable with the exception that the image being built has a build
-                    dependency on the variable's list of packages.
-                    In other words, the image will not build if a file in this list is not found.
-                </p><p>
-                    As an example, suppose the machine for which you are building requires
-                    <code class="filename">example-init</code> to be run during boot to initialize the hardware.
-                    In this case, you would use the following in the machine's
-                    <code class="filename">.conf</code> configuration file:
-                    </p><pre class="literallayout">
-     MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"
-                    </pre><p>
-                </p></dd><dt><a id="var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS"></a>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</dt><dd><p></p><p>
-                    A list of recommended machine-specific packages to install as part of
-                    the image being built.
-                    The build process does not depend on these packages being present.
-                    However, because this is a "machine essential" variable, the list of
-                    packages are essential for the machine to boot.
-                    The impact of this variable affects images based on
-                    <code class="filename">packagegroup-core-boot</code>,
-                    including the <code class="filename">core-image-minimal</code> image.
-                </p><p>
-                    This variable is similar to the
-                    <code class="filename"><a class="link" href="#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS" title="MACHINE_ESSENTIAL_EXTRA_RDEPENDS">MACHINE_ESSENTIAL_EXTRA_RDEPENDS</a></code>
-                    variable with the exception that the image being built does not have a build
-                    dependency on the variable's list of packages.
-                    In other words, the image will still build if a package in this list is not found.
-                    Typically, this variable is used to handle essential kernel modules, whose
-                    functionality may be selected to be built into the kernel rather than as a module,
-                    in which case a package will not be produced.
-                </p><p>
-                    Consider an example where you have a custom kernel where a specific touchscreen
-                    driver is required for the machine to be usable.
-                    However, the driver can be built as a module or
-                    into the kernel depending on the kernel configuration.
-                    If the driver is built as a module, you want it to be installed.
-                    But, when the driver is built into the kernel, you still want the
-                    build to succeed.
-                    This variable sets up a "recommends" relationship so that in the latter case,
-                    the build will not fail due to the missing package.
-                    To accomplish this, assuming the package for the module was called
-                    <code class="filename">kernel-module-ab123</code>, you would use the
-                    following in the machine's <code class="filename">.conf</code> configuration
-                    file:
-                    </p><pre class="literallayout">
-     MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
-                    </pre><p>
-                </p><p>
-                    Some examples of these machine essentials are flash, screen, keyboard, mouse,
-                    or touchscreen drivers (depending on the machine).
-                </p></dd><dt><a id="var-MACHINE_EXTRA_RDEPENDS"></a>MACHINE_EXTRA_RDEPENDS</dt><dd><p>
-                    A list of machine-specific packages to install as part of the
-                    image being built that are not essential for the machine to boot.
-                    However, the build process for more fully-featured images
-                    depends on the packages being present.
-                </p><p>
-                    This variable affects all images based on
-                    <code class="filename">packagegroup-base</code>, which does not include the
-                    <code class="filename">core-image-minimal</code> or <code class="filename">core-image-basic</code>
-                    images.
-                </p><p>
-                    The variable is similar to the
-                    <code class="filename"><a class="link" href="#var-MACHINE_EXTRA_RRECOMMENDS" title="MACHINE_EXTRA_RRECOMMENDS">MACHINE_EXTRA_RRECOMMENDS</a></code>
-                    variable with the exception that the image being built has a build
-                    dependency on the variable's list of packages.
-                    In other words, the image will not build if a file in this list is not found.
-                </p><p>
-                    An example is a machine that has WiFi capability but is not essential
-                    For the machine to boot the image.
-                    However, if you are building a more fully-featured image, you want to enable
-                    the WiFi.
-                    The package containing the firmware for the WiFi hardware is always
-                    expected to exist, so it is acceptable for the build process to depend upon
-                    finding the package.
-                    In this case, assuming the package for the firmware was called
-                    <code class="filename">wifidriver-firmware</code>, you would use the following in the
-                    <code class="filename">.conf</code> file for the machine:
-                    </p><pre class="literallayout">
-     MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware"
-                    </pre><p>
-                </p></dd><dt><a id="var-MACHINE_EXTRA_RRECOMMENDS"></a>MACHINE_EXTRA_RRECOMMENDS</dt><dd><p></p><p>
-                    A list of machine-specific packages to install as part of the
-                    image being built that are not essential for booting the machine.
-                    The image being built has no build dependency on this list of packages.
-                </p><p>
-                    This variable affects only images based on
-                    <code class="filename">packagegroup-base</code>, which does not include the
-                    <code class="filename">core-image-minimal</code> or <code class="filename">core-image-basic</code>
-                    images.
-                </p><p>
-                    This variable is similar to the
-                    <code class="filename"><a class="link" href="#var-MACHINE_EXTRA_RDEPENDS" title="MACHINE_EXTRA_RDEPENDS">MACHINE_EXTRA_RDEPENDS</a></code>
-                    variable with the exception that the image being built does not have a build
-                    dependency on the variable's list of packages.
-                    In other words, the image will build if a file in this list is not found.
-                </p><p>
-                    An example is a machine that has WiFi capability but is not essential
-                    For the machine to boot the image.
-                    However, if you are building a more fully-featured image, you want to enable
-                    WiFi.
-                    In this case, the package containing the WiFi kernel module will not be produced
-                    if the WiFi driver is built into the kernel, in which case you still want the
-                    build to succeed instead of failing as a result of the package not being found.
-                    To accomplish this, assuming the package for the module was called
-                    <code class="filename">kernel-module-examplewifi</code>, you would use the
-                    following in the <code class="filename">.conf</code> file for the machine:
-                    </p><pre class="literallayout">
-     MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi"
-                    </pre><p>
-                </p></dd><dt><a id="var-MACHINE_FEATURES"></a>MACHINE_FEATURES</dt><dd><p>Specifies the list of hardware features the
-                    <a class="link" href="#var-MACHINE" title="MACHINE">MACHINE</a> supports.
-                    For example, including the "bluetooth" feature causes the
-                    <code class="filename">bluez</code> bluetooth daemon to be built and
-                    added to the image.
-                    It also causes the <code class="filename">connman</code> recipe
-                    to look at <code class="filename">MACHINE_FEATURES</code> and when it
-                    finds "bluetooth" there it enables the bluetooth
-                    support in ConnMan.
-                </p><p>
-                    For a list of features supported by the Yocto Project as shipped,
-                    see the "<a class="link" href="#ref-features-machine" title="9.2. Machine">Machine</a>" section.
-                </p></dd><dt><a id="var-MACHINE_FEATURES_BACKFILL"></a>MACHINE_FEATURES_BACKFILL</dt><dd><p>Features to be added to
-                    <code class="filename"><a class="link" href="#var-MACHINE_FEATURES" title="MACHINE_FEATURES">MACHINE_FEATURES</a></code>
-                    if not also present in
-                    <code class="filename"><a class="link" href="#var-MACHINE_FEATURES_BACKFILL_CONSIDERED" title="MACHINE_FEATURES_BACKFILL_CONSIDERED">MACHINE_FEATURES_BACKFILL_CONSIDERED</a></code>.
-                </p><p>
-                    This variable is set in the <code class="filename">meta/conf/bitbake.conf</code> file.
-                    It is not intended to be user-configurable.
-                    It is best to just reference the variable to see which machine features are
-                    being backfilled for all machine configurations.
-                    See the <a class="link" href="#ref-features-backfill" title="9.4. Feature Backfilling">Feature backfilling</a> section for
-                    more information.
-                </p></dd><dt><a id="var-MACHINE_FEATURES_BACKFILL_CONSIDERED"></a>MACHINE_FEATURES_BACKFILL_CONSIDERED</dt><dd><p>Features from
-                    <code class="filename"><a class="link" href="#var-MACHINE_FEATURES_BACKFILL" title="MACHINE_FEATURES_BACKFILL">MACHINE_FEATURES_BACKFILL</a></code>
-                    that should not be backfilled (i.e. added to
-                    <code class="filename"><a class="link" href="#var-MACHINE_FEATURES" title="MACHINE_FEATURES">MACHINE_FEATURES</a></code>)
-                    during the build.
-                    See the <a class="link" href="#ref-features-backfill" title="9.4. Feature Backfilling">Feature backfilling</a> section for
-                    more information.
-                    </p></dd><dt><a id="var-MAINTAINER"></a>MAINTAINER</dt><dd><p>The email address of the distribution maintainer.</p></dd><dt><a id="var-MLPREFIX"></a>MLPREFIX</dt><dd><p>
-                    Specifies a prefix has been added to
-                    <a class="link" href="#var-PN" title="PN"><code class="filename">PN</code></a> to create a special version
-                    of a recipe or package, such as a multilib version.
-                    The variable is used in places where the prefix needs to be
-                    added to or removed from a the name (e.g. the
-                    <a class="link" href="#var-BPN" title="BPN"><code class="filename">BPN</code></a> variable).
-                    <code class="filename">MLPREFIX</code> gets set when a prefix has been
-                    added to <code class="filename">PN</code>.
-                </p></dd><dt><a id="var-MULTIMACH_TARGET_SYS"></a>MULTIMACH_TARGET_SYS</dt><dd><p>
-                    Separates files for different machines such that you can build
-                    for multiple target machines using the same output directories.
-                    See the <a class="link" href="#var-STAMP" title="STAMP"><code class="filename">STAMP</code></a> variable
-                    for an example.
-                </p></dd></dl></div><div class="glossdiv" title="O"><h3 class="title">O</h3><dl><dt><a id="var-OE_TERMINAL"></a>OE_TERMINAL</dt><dd><p>
-                    Controls how the OpenEmbedded build system spawns
-                    interactive terminals on the host development system
-                    (e.g. using the BitBake command with the
-                    <code class="filename">-c devshell</code> command-line option).
-                    For more information, see the
-                    "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#platdev-appdev-devshell" target="_top">Using a Development Shell</a>" section
-                    in the Yocto Project Development Manual.
-                 </p><p>
-                    You can use the following values for the
-                    <code class="filename">OE_TERMINAL</code> variable:
-                    </p><pre class="literallayout">
-     auto
-     gnome
-     xfce
-     rxvt
-     screen
-     konsole
-     none
-                    </pre><p>
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>Konsole support only works for KDE 3.x.
-                        Also, "auto" is the default behavior for
-                        <code class="filename">OE_TERMINAL</code></div><p>
-                </p></dd></dl></div><div class="glossdiv" title="P"><h3 class="title">P</h3><dl><dt><a id="var-P"></a>P</dt><dd><p>The recipe name and version.
-                    <code class="filename">P</code> is comprised of the following:
-                    </p><pre class="literallayout">
-     ${PN}-${PV}
-                    </pre></dd><dt><a id="var-PACKAGE_ARCH"></a>PACKAGE_ARCH</dt><dd><p>The architecture of the resulting package or packages.</p></dd><dt><a id="var-PACKAGE_BEFORE_PN"></a>PACKAGE_BEFORE_PN</dt><dd><p>Enables easily adding packages to
-                <code class="filename"><a class="link" href="#var-PACKAGES" title="PACKAGES">PACKAGES</a></code>
-                before <code class="filename">${PN}</code> so that the packages can pick
-                up files that would normally be included in the default package.</p></dd><dt><a id="var-PACKAGE_CLASSES"></a>PACKAGE_CLASSES</dt><dd><p>This variable, which is set in the <code class="filename">local.conf</code> configuration
-                    file found in the <code class="filename">conf</code> folder of the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>,
-                    specifies the package manager to use when packaging data.
-                    You can provide one or more arguments for the variable with the first
-                    argument being the package manager used to create images:
-                    </p><pre class="literallayout">
-     PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
-                    </pre><p>
-                    For information on build performance effects as a result of the
-                    package manager use, see
-                    <a class="link" href="#ref-classes-package" title="7.13. Packaging - package*.bbclass">Packaging - <code class="filename">package*.bbclass</code></a>
-                    in this manual.
-                </p></dd><dt><a id="var-PACKAGE_EXTRA_ARCHS"></a>PACKAGE_EXTRA_ARCHS</dt><dd><p>Specifies the list of architectures compatible with the device CPU.
-                    This variable is useful when you build for several different devices that use
-                    miscellaneous processors such as XScale and ARM926-EJS).</p></dd><dt><a id="var-PACKAGECONFIG"></a>PACKAGECONFIG</dt><dd><p>
-                    This variable provides a means of enabling or disabling
-                    features of a recipe on a per-recipe basis.
-                    The <code class="filename">PACKAGECONFIG</code>
-                    variable itself specifies a space-separated list of the
-                    features to enable.
-                    The features themselves are specified as flags on the
-                    <code class="filename">PACKAGECONFIG</code> variable.
-                    You can provide up to four arguments, which are separated by
-                    commas, to determine the behavior of each feature
-                    when it is enabled or disabled.
-                    You can omit any argument you like but must retain the
-                    separating commas.
-                    The arguments specify the following:
-                    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Extra arguments
-                            that should be added to the configure script argument list
-                            (<a class="link" href="#var-EXTRA_OECONF" title="EXTRA_OECONF"><code class="filename">EXTRA_OECONF</code></a>)
-                            if the feature is enabled.</p></li><li class="listitem"><p>Extra arguments
-                            that should be added to <code class="filename">EXTRA_OECONF</code>
-                            if the feature is disabled.
-                            </p></li><li class="listitem"><p>Additional build dependencies
-                            (<a class="link" href="#var-DEPENDS" title="DEPENDS"><code class="filename">DEPENDS</code></a>)
-                            that should be added if the feature is enabled.
-                            </p></li><li class="listitem"><p>Additional runtime dependencies
-                            (<a class="link" href="#var-RDEPENDS" title="RDEPENDS"><code class="filename">RDEPENDS</code></a>)
-                            that should be added if the feature is enabled.
-                            </p></li></ol></div><p>
-                </p><p>
-                    Consider the following example taken from the
-                    <code class="filename">librsvg</code> recipe.
-                    In this example the feature is <code class="filename">croco</code>, which
-                    has three arguments that determine the feature's behavior.
-                        </p><pre class="literallayout">
-     PACKAGECONFIG ??= "croco"
-     PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco"
-                        </pre><p>
-                    The <code class="filename">--with-croco</code> and
-                    <code class="filename">libcroco</code> arguments apply only if
-                    the feature is enabled.
-                    In this case, <code class="filename">--with-croco</code> is
-                    added to the configure script argument list and
-                    <code class="filename">libcroco</code> is added to
-                    <code class="filename"><a class="link" href="#var-DEPENDS" title="DEPENDS">DEPENDS</a></code>.
-                    On the other hand, if the feature is disabled say through
-                    a <code class="filename">.bbappend</code> file in another layer, then
-                    the second argument <code class="filename">--without-croco</code> is
-                    added to the configure script rather than
-                    <code class="filename">--with-croco</code>.
-                </p></dd><dt><a id="var-PACKAGES"></a>PACKAGES</dt><dd><p>The list of packages to be created from the recipe.
-                    The default value is the following:
-                    </p><pre class="literallayout">
-     ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
-                    </pre></dd><dt><a id="var-PACKAGES_DYNAMIC"></a>PACKAGES_DYNAMIC</dt><dd><p>
-                    A promise that your recipe satisfies runtime dependencies
-                    for optional modules that are found in other recipes.
-                    <code class="filename">PACKAGES_DYNAMIC</code>
-                    does not actually satisfy the dependencies, it only states that
-                    they should be satisfied.
-                    For example, if a hard, runtime dependency
-                    (<code class="filename">RDEPENDS</code>) of another package is satisfied
-                    at build time through the <code class="filename">PACKAGES_DYNAMIC</code>
-                    variable, but a package with the module name is never actually
-                    produced, then the other package will be broken.
-                    Thus, if you attempt to include that package in an image,
-                    you will get a dependency failure from the packaging system
-                    during <code class="filename">do_rootfs</code>.
-                    Typically, if there is a chance that such a situation can
-                    occur and the package that is not created is valid
-                    without the dependency being satisfied, then you should use
-                    <code class="filename">RRECOMMENDS</code> (a soft runtime dependency)
-                    instead of <code class="filename">RDEPENDS</code>.
-                </p><p>
-                    For an example of how to use the <code class="filename">PACKAGES_DYNAMIC</code>
-                    variable when you are splitting packages, see the
-                    "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#handling-optional-module-packaging" target="_top">Handling Optional Module Packaging</a>" section
-                    in the Yocto Project Development Manual.
-                </p></dd><dt><a id="var-PARALLEL_MAKE"></a>PARALLEL_MAKE</dt><dd><p>Specifies extra options that are passed to the <code class="filename">make</code> command during the
-                    compile tasks.
-                    This variable is usually in the form <code class="filename">-j 4</code>, where the number
-                    represents the maximum number of parallel threads make can run.
-                    If you development host supports multiple cores a good rule of thumb is to set
-                    this variable to twice the number of cores on the host.</p></dd><dt><a id="var-PF"></a>PF</dt><dd><p>Specifies the recipe or package name and includes all version and revision
-                    numbers (i.e. <code class="filename">eglibc-2.13-r20+svnr15508/</code> and
-                    <code class="filename">bash-4.2-r1/</code>).
-                    This variable is comprised of the following:
-                    </p><pre class="literallayout">
-     ${PN}-${EXTENDPE}${PV}-${PR}
-                    </pre></dd><dt><a id="var-PN"></a>PN</dt><dd><p>This variable can have two separate functions depending on the context: a recipe
-                    name or a resulting package name.</p><p><code class="filename">PN</code> refers to a recipe name in the context of a file used
-                    by the OpenEmbedded build system as input to create a package.
-                    The name is normally extracted from the recipe file name.
-                    For example, if the recipe is named
-                    <code class="filename">expat_2.0.1.bb</code>, then the default value of <code class="filename">PN</code>
-                    will be "expat".</p><p>
-                    The variable refers to a package name in the context of a file created or produced by the
-                    OpenEmbedded build system.</p><p>If applicable, the <code class="filename">PN</code> variable also contains any special
-                    suffix or prefix.
-                    For example, using <code class="filename">bash</code> to build packages for the native
-                    machine, <code class="filename">PN</code> is <code class="filename">bash-native</code>.
-                    Using <code class="filename">bash</code> to build packages for the target and for Multilib,
-                    <code class="filename">PN</code> would be <code class="filename">bash</code> and
-                    <code class="filename">lib64-bash</code>, respectively.
-                </p></dd><dt><a id="var-PR"></a>PR</dt><dd><p>The revision of the recipe.
-                    The default value for this variable is "r0".
-                    </p></dd><dt><a id="var-PRINC"></a>PRINC</dt><dd><p>Causes the <code class="filename">PR</code> variable of
-                    <code class="filename">.bbappend</code> files to dynamically increment.
-                    This increment minimizes the impact of layer ordering.</p><p>In order to ensure multiple <code class="filename">.bbappend</code> files can co-exist,
-                    <code class="filename">PRINC</code> should be self referencing.
-                    This variable defaults to 0.</p><p>Following is an example that increments <code class="filename">PR</code> by two:
-                    </p><pre class="literallayout">
-     PRINC := "${@int(PRINC) + 2}"
-                    </pre><p>
-                    It is adviseable not to use strings such as ".= '.1'" with the variable because
-                    this usage is very sensitive to layer ordering.
-                    Explicit assignments should be avoided as they cannot adequately represent multiple
-                    <code class="filename">.bbappend</code> files.</p></dd><dt><a id="var-PV"></a>PV</dt><dd><p>The version of the recipe.
-                    The version is normally extracted from the recipe filename.
-                    For example, if the recipe is named
-                    <code class="filename">expat_2.0.1.bb</code>, then the default value of <code class="filename">PV</code>
-                    will be "2.0.1".
-                    <code class="filename">PV</code> is generally not overridden within
-                    a recipe unless it is building an unstable (i.e. development) version from a source code repository
-                    (e.g. Git or Subversion).
-                 </p></dd><dt><a id="var-PE"></a>PE</dt><dd><p>
-                    the epoch of the recipe.
-                    The default value is "0".
-                    The field is used to make upgrades possible when the versioning scheme changes in
-                    some backwards incompatible way.
-                </p></dd><dt><a id="var-PREFERRED_PROVIDER"></a>PREFERRED_PROVIDER</dt><dd><p>
-                    If multiple recipes provide an item, this variable
-                    determines which recipe should be given preference.
-                    The variable must always be suffixed with the name of the
-                    provided item, and should be set to the
-                    <code class="filename">PN</code> of the recipe
-                    to which you want to give precedence.
-                    Here is an example:
-                    </p><pre class="literallayout">
-     PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
-                    </pre><p>
-                </p></dd><dt><a id="var-PREFERRED_VERSION"></a>PREFERRED_VERSION</dt><dd><p>
-                    If there are multiple versions of recipes available, this
-                    variable determines which recipe should be given preference.
-                    The variable must always be suffixed with the <code class="filename">PN</code>
-                    for which to select, and should be set to the
-                    <code class="filename">PV</code> to which you want to give precedence.
-                    You can use the "<code class="filename">%</code>" character as a wildcard
-                    to match any number of characters, which can be useful when
-                    specifying versions that contain long revision number that could
-                    potentially change.
-                    Here are two examples:
-                    </p><pre class="literallayout">
-     PREFERRED_VERSION_python = "2.6.6"
-     PREFERRED_VERSION_linux-yocto = "3.0+git%"
-                    </pre><p>
-                </p></dd></dl></div><div class="glossdiv" title="R"><h3 class="title">R</h3><dl><dt><a id="var-RCONFLICTS"></a>RCONFLICTS</dt><dd><p>The list of packages that conflict with a package.
-                    Note that the package will not be installed if the conflicting packages are not
-                    first removed.</p><p>
-                   Like all package-controlling variables, you must always use them in
-                   conjunction with a package name override.
-                   Here is an example:
-                   </p><pre class="literallayout">
-     RCONFLICTS_${PN} = "another-conflicting-package-name"
-                   </pre><p>
-                </p></dd><dt><a id="var-RDEPENDS"></a>RDEPENDS</dt><dd><p>
-                    Lists a package's run-time dependencies (i.e. other packages)
-                    that must be installed for the package to be built.
-                    In other words, in order for the package to be built and
-                    run correctly, it depends on the listed packages.
-                    If a package in this list cannot be found, it is probable
-                    that a dependency error would occur before the build.
-                </p><p>
-                    The names of the variables you list with
-                    <code class="filename">RDEPENDS</code> must be the names of other
-                    packages as listed in the
-                    <a class="link" href="#var-PACKAGES" title="PACKAGES"><code class="filename">PACKAGES</code></a>
-                    variable.
-                    You should not list recipe names (<code class="filename">PN</code>).
-                </p><p>
-                    Because the <code class="filename">RDEPENDS</code> variable applies
-                    to packages being built, you should
-                    always attach a package name to the variable to specify the
-                    particular run-time package that has the dependency.
-                    For example, suppose you are building a development package
-                    that depends on the <code class="filename">perl</code> package.
-                    In this case, you would use the following
-                    <code class="filename">RDEPENDS</code> statement:
-                    </p><pre class="literallayout">
-     RDEPENDS_${PN}-dev += "perl"
-                    </pre><p>
-                    In the example, the package name
-                    (<code class="filename">${PN}-dev</code>) must appear as it would
-                    in the
-                    <code class="filename"><a class="link" href="#var-PACKAGES" title="PACKAGES">PACKAGES</a></code>
-                    namespace before any renaming of the output package by
-                    classes like <code class="filename">debian.bbclass</code>.
-                </p><p>
-                    In many cases you do not need to explicitly add dependencies
-                    to <code class="filename">RDEPENDS</code> since some automatic
-                    handling occurs:
-                    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><code class="filename">shlibdeps</code></em></span>:  If
-                            a run-time package contains a shared library
-                            (<code class="filename">.so</code>), the build
-                            processes the library in order to determine other
-                            libraries to which it is dynamically linked.
-                            The build process adds these libraries to
-                            <code class="filename">RDEPENDS</code> when creating the run-time
-                            package.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">pcdeps</code></em></span>:  If
-                            the package ships a <code class="filename">pkg-config</code>
-                            information file, the build process uses this file
-                            to add items to the <code class="filename">RDEPENDS</code>
-                            variable to create the run-time packages.
-                            </p></li></ul></div><p>
-                </p></dd><dt><a id="var-RRECOMMENDS"></a>RRECOMMENDS</dt><dd><p>
-                    A list of packages that extend the usability of a package being
-                    built.
-                    The package being built does not depend on this list of packages in
-                    order to successfully build, but needs them for the extended usability.
-                    To specify runtime dependencies for packages, see the
-                    <code class="filename"><a class="link" href="#var-RDEPENDS" title="RDEPENDS">RDEPENDS</a></code> variable.
-                </p><p>
-                    The OpenEmbedded build process automatically installs the list of packages
-                    as part of the built package.
-                    However, you can remove them later if you want.
-                    If, during the build, a package from the list cannot be found, the build
-                    process continues without an error.
-                </p><p>
-                    Because the <code class="filename">RRECOMMENDS</code> variable applies to packages
-                    being built, you should
-                    always attach an override to the variable to specify the particular package
-                    whose usability is being extended.
-                    For example, suppose you are building a development package that is extended
-                    to support wireless functionality.
-                    In this case, you would use the following:
-                    </p><pre class="literallayout">
-     RRECOMMENDS_${PN}-dev += "&lt;wireless_package_name&gt;"
-                    </pre><p>
-                    In the example, the package name (<code class="filename">${PN}-dev</code>) must
-                    appear as it would in the
-                    <code class="filename"><a class="link" href="#var-PACKAGES" title="PACKAGES">PACKAGES</a></code> namespace before any
-                    renaming of the output package by classes like <code class="filename">debian.bbclass</code>.
-                </p></dd><dt><a id="var-RREPLACES"></a>RREPLACES</dt><dd><p>The list of packages that are replaced with this package.</p></dd></dl></div><div class="glossdiv" title="S"><h3 class="title">S</h3><dl><dt><a id="var-S"></a>S</dt><dd><p>
-                    The location in the <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>
-                    where unpacked package source code resides.
-                    This location is within the working directory
-                    (<code class="filename"><a class="link" href="#var-WORKDIR" title="WORKDIR">WORKDIR</a></code>), which
-                    is not static.
-                    The unpacked source location depends on the package name
-                    (<code class="filename"><a class="link" href="#var-PN" title="PN">PN</a></code>) and
-                    package version (<code class="filename"><a class="link" href="#var-PV" title="PV">PV</a></code>) as
-                    follows:
-                    </p><pre class="literallayout">
- ${WORKDIR}/${PN}/${PV}
-                    </pre><p>
-                    As an example, assume a
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a> top-level
-                    folder named <code class="filename">poky</code>
-                    and a default <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>
-                    at <code class="filename">poky/build</code>.
-                    In this case, the working directory the build system uses to build
-                    the <code class="filename">db</code> package is the following:
-                    </p><pre class="literallayout">
- ~/poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
-                    </pre><p>
-                </p></dd><dt><a id="var-SDKIMAGE_FEATURES"></a>SDKIMAGE_FEATURES</dt><dd><p>Equivalent to
-                <code class="filename"><a class="link" href="#var-IMAGE_FEATURES" title="IMAGE_FEATURES">IMAGE_FEATURES</a></code>.
-                However, this variable applies to the SDK generated from an image using
-                <code class="filename">bitbake -c populate_sdk imagename</code>).
-                </p></dd><dt><a id="var-SECTION"></a>SECTION</dt><dd><p>The section in which packages should be categorized.
-                    Package management utilities can make use of this variable.</p></dd><dt><a id="var-SELECTED_OPTIMIZATION"></a>SELECTED_OPTIMIZATION</dt><dd><p>
-                    The variable takes the value of
-                    <code class="filename"><a class="link" href="#var-FULL_OPTIMIZATION" title="FULL_OPTIMIZATION">FULL_OPTIMIZATION</a></code>
-                    unless <code class="filename"><a class="link" href="#var-DEBUG_BUILD" title="DEBUG_BUILD">DEBUG_BUILD</a></code> = "1".
-                    In this case the value of
-                    <code class="filename"><a class="link" href="#var-DEBUG_OPTIMIZATION" title="DEBUG_OPTIMIZATION">DEBUG_OPTIMIZATION</a></code> is used.
-                </p></dd><dt><a id="var-SERIAL_CONSOLE"></a>SERIAL_CONSOLE</dt><dd><p>The speed and device for the serial port used to attach the serial console.
-                    This variable is given to the kernel as the "console"
-                    parameter and after booting occurs <code class="filename">getty</code> is started on that port
-                    so remote login is possible.</p></dd><dt><a id="var-SITEINFO_ENDIANNESS"></a>SITEINFO_ENDIANNESS</dt><dd><p>
-                    Specifies the endian byte order of the target system.
-                    The value should be either "le" for little-endian or "be" for big-endian.
-                </p></dd><dt><a id="var-SITEINFO_BITS"></a>SITEINFO_BITS</dt><dd><p>
-                    Specifies the number of bits for the target system CPU.
-                    The value should be either "32" or "64".
-                </p></dd><dt><a id="var-SPECIAL_PKGSUFFIX"></a>SPECIAL_PKGSUFFIX</dt><dd><p>
-                    A list of prefixes for <a class="link" href="#var-PN" title="PN"><code class="filename">PN</code></a> used by the
-                    OpenEmbedded build system to create variants of recipes or packages.
-                    The list specifies the prefixes to strip off during certain circumstances
-                    such as the generation of the <a class="link" href="#var-BPN" title="BPN"><code class="filename">BPN</code></a> variable.
-                </p></dd><dt><a id="var-SRC_URI"></a>SRC_URI</dt><dd><p>The list of source files - local or remote.
-                    This variable tells the OpenEmbedded build system which bits to pull
-                    in for the build and how to pull them in.
-                    For example, if the recipe only needs to fetch a tarball from the
-                    internet, the recipe uses a single <code class="filename">SRC_URI</code> entry.
-                    On the other hand, if the recipe needs to fetch a tarball, apply
-                    two patches, and include a custom file, the recipe would include four
-                    instances of the variable.</p><p>The following list explains the available URI protocols:
-                    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><code class="filename">file://</code> -</em></span> Fetches files, which is usually
-                            a file shipped with the metadata, from the local machine.
-                            The path is relative to the
-                            <a class="link" href="#var-FILESPATH" title="FILESPATH"><code class="filename">FILESPATH</code></a>
-                            variable.
-                            Thus, the build system searches, in order, from the following directories,
-                            which are assumed to be a subdirectories of the directory in which the
-                            recipe file resides:
-                            </p><div class="itemizedlist"><ul class="itemizedlist" type="circle"><li class="listitem"><p><span class="emphasis"><em><code class="filename">${PN}</code> -</em></span> The recipe name
-                                    with any special suffix or prefix, if applicable.
-                                    For example, using <code class="filename">bash</code> to build for the native
-                                    machine, <code class="filename">PN</code> is <code class="filename">bash-native</code>.
-                                    Using <code class="filename">bash</code> to build for the target and for Multilib,
-                                    <code class="filename">PN</code> would be <code class="filename">bash</code> and
-                                    <code class="filename">lib64-bash</code>, respectively.
-                                    </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">${PF}</code> - </em></span>
-                                    <code class="filename">${PN}-${EXTENDPE}${PV}-${PR}</code>.
-                                    The recipe name including all version and revision numbers
-                                    (i.e. <code class="filename">eglibc-2.13-r20+svnr15508/</code> and
-                                    <code class="filename">bash-4.2-r1/</code>).</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">${P}</code> -</em></span>
-                                    <code class="filename">${PN}-${PV}</code>.
-                                    The recipe name and version (i.e. <code class="filename">bash-4.2</code>).
-                                    </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">${BPN}</code> -</em></span> The
-                                    base recipe name without any special suffix or version numbers.
-                                    </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">${BP}</code> -</em></span>
-                                    <code class="filename">${BPN}-${PV}</code>.
-                                    The base recipe name and version but without any special
-                                    package name suffix.</p></li><li class="listitem"><p><span class="emphasis"><em>Files -</em></span> Files beneath the directory in which the recipe
-                                    resides.</p></li><li class="listitem"><p><span class="emphasis"><em>Directory -</em></span> The directory itself in which the recipe
-                                    resides.</p></li></ul></div></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">bzr://</code> -</em></span> Fetches files from a
-                            Bazaar revision control repository.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">git://</code> -</em></span> Fetches files from a
-                            Git revision control repository.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">osc://</code> -</em></span> Fetches files from
-                            an OSC (OpenSuse Build service) revision control repository.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">repo://</code> -</em></span> Fetches files from
-                            a repo (Git) repository.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">svk://</code> -</em></span> Fetches files from
-                            an SVK revision control repository.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">http://</code> -</em></span> Fetches files from
-                            the Internet using <code class="filename">http</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">https://</code> -</em></span> Fetches files
-                            from the Internet using <code class="filename">https</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">ftp://</code> -</em></span> Fetches files
-                            from the Internet using <code class="filename">ftp</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">cvs://</code> -</em></span> Fetches files from
-                            a CVS revision control repository.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">hg://</code> -</em></span> Fetches files from
-                            a Mercurial (<code class="filename">hg</code>) revision control repository.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">p4://</code> -</em></span> Fetches files from
-                            a Perforce (<code class="filename">p4</code>) revision control repository.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">ssh://</code> -</em></span> Fetches files from
-                            a secure shell.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">svn://</code> -</em></span> Fetches files from
-                            a Subversion (<code class="filename">svn</code>) revision control repository.</p></li></ul></div><p>
-                </p><p>Standard and recipe-specific options for <code class="filename">SRC_URI</code> exist.
-                    Here are standard options:
-                    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><code class="filename">apply</code> -</em></span> Whether to apply
-                            the patch or not.
-                            The default action is to apply the patch.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">striplevel</code> -</em></span> Which
-                            striplevel to use when applying the patch.
-                            The default level is 1.</p></li></ul></div><p>
-                </p><p>Here are options specific to recipes building code from a revision control system:
-                    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><code class="filename">mindate</code> -</em></span> Only applies
-                            the patch if <a class="link" href="#var-SRCDATE" title="SRCDATE"><code class="filename">SRCDATE</code></a>
-                            is equal to or greater than <code class="filename">mindate</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">maxdate</code> -</em></span> Only applies
-                            the patch if <a class="link" href="#var-SRCDATE" title="SRCDATE"><code class="filename">SRCDATE</code></a>
-                            is not later than <code class="filename">mindate</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">minrev</code> -</em></span> Only applies
-                            the patch if <a class="link" href="#var-SRCREV" title="SRCREV"><code class="filename">SRCREV</code></a>
-                            is equal to or greater than <code class="filename">minrev</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">maxrev</code> -</em></span> Only applies
-                            the patch if <a class="link" href="#var-SRCREV" title="SRCREV"><code class="filename">SRCREV</code></a>
-                            is not later than <code class="filename">maxrev</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">rev</code> -</em></span> Only applies the
-                            patch if <a class="link" href="#var-SRCREV" title="SRCREV"><code class="filename">SRCREV</code></a>
-                            is equal to <code class="filename">rev</code>.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">notrev</code> -</em></span> Only applies
-                            the patch if <a class="link" href="#var-SRCREV" title="SRCREV"><code class="filename">SRCREV</code></a>
-                            is not equal to <code class="filename">rev</code>.</p></li></ul></div><p>
-                </p><p>Here are some additional options worth mentioning:
-                    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><code class="filename">unpack</code> -</em></span> Controls
-                            whether or not to unpack the file if it is an archive.
-                            The default action is to upack the file.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">subdir</code> -</em></span> Places the file
-                            (or extracts its contents) into the specified
-                            subdirectory of <a class="link" href="#var-WORKDIR" title="WORKDIR"><code class="filename">WORKDIR</code></a>.
-                            This option is useful for unusual tarballs or other archives that
-                            don't have their files already in a subdirectory within the archive.
-                            </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">name</code> -</em></span> Specifies a
-                            name to be used for association with <code class="filename">SRC_URI</code> checksums
-                            when you have more than one file specified in <code class="filename">SRC_URI</code>.
-                            </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">downloadfilename</code> -</em></span> Specifies
-                            the filename used when storing the downloaded file.</p></li></ul></div><p>
-                </p></dd><dt><a id="var-SRC_URI_OVERRIDES_PACKAGE_ARCH"></a>SRC_URI_OVERRIDES_PACKAGE_ARCH</dt><dd><p></p><p>
-                    By default, the OpenEmbedded build system automatically detects whether
-                    <code class="filename"><a class="link" href="#var-SRC_URI" title="SRC_URI">SRC_URI</a></code>
-                    contains files that are machine-specific.
-                    If so, the build system automatically changes
-                    <code class="filename"><a class="link" href="#var-PACKAGE_ARCH" title="PACKAGE_ARCH">PACKAGE_ARCH</a></code>.
-                    Setting this variable to "0" disables this behavior.
-                </p></dd><dt><a id="var-SRCDATE"></a>SRCDATE</dt><dd><p>
-                    The date of the source code used to build the package.
-                    This variable applies only if the source was fetched from a Source Code Manager (SCM).
-                </p></dd><dt><a id="var-SRCREV"></a>SRCREV</dt><dd><p>
-                    The revision of the source code used to build the package.
-                    This variable applies to Subversion, Git, Mercurial and Bazaar
-                    only.
-                    Note that if you wish to build a fixed revision and you wish
-                    to avoid performing a query on the remote repository every time
-                    BitBake parses your recipe, you should specify a <code class="filename">SRCREV</code> that is a
-                    full revision identifier and not just a tag.
-                </p></dd><dt><a id="var-SSTATE_DIR"></a>SSTATE_DIR</dt><dd><p>The directory for the shared state.</p></dd><dt><a id="var-SSTATE_MIRRORS"></a>SSTATE_MIRRORS</dt><dd><p>
-                    Configures the OpenEmbedded build system to search other
-                    mirror locations for prebuilt cache data objects before
-                    building out the data.
-                    This variable works like fetcher
-                    <code class="filename">MIRRORS</code>/<code class="filename">PREMIRRORS</code>
-                    and points to the cache locations to check for the shared
-                    objects.
-                </p><p>
-                    You can specify a filesystem directory or a remote URL such
-                    as HTTP or FTP.
-                    The locations you specify need to contain the shared state
-                    cache (sstate-cache) results from previous builds.
-                    The sstate-cache you point to can also be from builds on
-                    other machines.
-                </p><p>
-                    If a mirror uses the same structure as
-                    <a class="link" href="#var-SSTATE_DIR" title="SSTATE_DIR"><code class="filename">SSTATE_DIR</code></a>,
-                    you need to add
-                    "PATH" at the end as shown in the examples below.
-                    The build system substitues the correct path within the
-                    directory structure.
-                    </p><pre class="literallayout">
-     SSTATE_MIRRORS ?= "\
-     file://.* http://someserver.tld/share/sstate/PATH \n \
-     file://.* file:///some/local/dir/sstate/PATH"
-                    </pre><p>
-                </p></dd><dt><a id="var-STAGING_KERNEL_DIR"></a>STAGING_KERNEL_DIR</dt><dd><p>
-                    The directory with kernel headers that are required to build out-of-tree
-                    modules.
-                </p></dd><dt><a id="var-STAMP"></a>STAMP</dt><dd><p>
-                    Specifies the base path used to create recipe stamp files.
-                    The path to an actual stamp file is constructed by evaluating this
-                    string and then appending additional information.
-                    Currently, the default assignment for <code class="filename">STAMP</code>
-                    as set in the <code class="filename">meta/conf/bitbake.conf</code> file
-                    is:
-                    </p><pre class="literallayout">
-     STAMP = "${TMPDIR}/stamps/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
-                    </pre><p>
-                    See <a class="link" href="#var-TMPDIR" title="TMPDIR"><code class="filename">TMPDIR</code></a>,
-                    <a class="link" href="#var-MULTIMACH_TARGET_SYS" title="MULTIMACH_TARGET_SYS"><code class="filename">MULTIMACH_TARGET_SYS</code></a>,
-                    <a class="link" href="#var-PN" title="PN"><code class="filename">PN</code></a>,
-                    <a class="link" href="#var-EXTENDPE" title="EXTENDPE"><code class="filename">EXTENDPE</code></a>,
-                    <a class="link" href="#var-PV" title="PV"><code class="filename">PV</code></a>, and
-                    <a class="link" href="#var-PR" title="PR"><code class="filename">PR</code></a> for related variable
-                    information.
-                </p></dd><dt><a id="var-SUMMARY"></a>SUMMARY</dt><dd><p>The short (72 characters or less) summary of the binary package for packaging
-                    systems such as <code class="filename">opkg</code>, <code class="filename">rpm</code> or
-                    <code class="filename">dpkg</code>.
-                    By default, <code class="filename">SUMMARY</code> is used to define
-                    the <a class="link" href="#var-DESCRIPTION" title="DESCRIPTION"><code class="filename">DESCRIPTION</code></a>
-                    variable if <code class="filename">DESCRIPTION</code> is not set
-                    in the recipe.
-                </p></dd></dl></div><div class="glossdiv" title="T"><h3 class="title">T</h3><dl><dt><a id="var-T"></a>T</dt><dd><p>This variable points to a directory were Bitbake places temporary
-                    files when building a particular package.
-                    It is typically set as follows:
-                    </p><pre class="literallayout">
-     T = ${WORKDIR}/temp
-                    </pre><p>
-                    The <a class="link" href="#var-WORKDIR" title="WORKDIR"><code class="filename">WORKDIR</code></a>
-                    is the directory into which Bitbake unpacks and builds the package.
-                    The default <code class="filename">bitbake.conf</code> file sets this variable.</p><p>The <code class="filename">T</code> variable is not to be confused with
-                    the <a class="link" href="#var-TMPDIR" title="TMPDIR"><code class="filename">TMPDIR</code></a> variable,
-                    which points to the root of the directory tree where Bitbake
-                    places the output of an entire build.
-                </p></dd><dt><a id="var-TARGET_ARCH"></a>TARGET_ARCH</dt><dd><p>The architecture of the device being built.
-                While a number of values are possible, the OpenEmbedded build system primarily supports
-                <code class="filename">arm</code> and <code class="filename">i586</code>.</p></dd><dt><a id="var-TARGET_CFLAGS"></a>TARGET_CFLAGS</dt><dd><p>
-                    Flags passed to the C compiler for the target system.
-                    This variable evaluates to the same as
-                    <code class="filename"><a class="link" href="#var-CFLAGS" title="CFLAGS">CFLAGS</a></code>.
-                </p></dd><dt><a id="var-TARGET_FPU"></a>TARGET_FPU</dt><dd><p>Specifies the method for handling FPU code.
-                    For FPU-less targets, which include most ARM CPUs, the variable must be
-                    set to "soft".
-                    If not, the kernel emulation gets used, which results in a performance penalty.</p></dd><dt><a id="var-TARGET_OS"></a>TARGET_OS</dt><dd><p>Specifies the target's operating system.
-                    The variable can be set to "linux" for <code class="filename">eglibc</code>-based systems and
-                    to "linux-uclibc" for <code class="filename">uclibc</code>.
-                    For ARM/EABI targets, there are also "linux-gnueabi" and
-                    "linux-uclibc-gnueabi" values possible.</p></dd><dt><a id="var-TCLIBC"></a>TCLIBC</dt><dd><p>
-                    Specifies which variant of the GNU standard C library (<code class="filename">libc</code>)
-                    to use during the build process.
-                    This variable replaces <code class="filename">POKYLIBC</code>, which is no longer
-                    supported.
-                </p><p>
-                    You can select <code class="filename">eglibc</code> or <code class="filename">uclibc</code>.
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                        This release of the Yocto Project does not support the
-                        <code class="filename">glibc</code> implementation of <code class="filename">libc</code>.
-                    </div><p>
-                </p></dd><dt><a id="var-TCMODE"></a>TCMODE</dt><dd><p>
-                    The toolchain selector.
-                    This variable replaces <code class="filename">POKYMODE</code>, which is no longer
-                    supported.
-                </p><p>
-                    The <code class="filename">TCMODE</code> variable selects the external toolchain
-                    built using the OpenEmbedded build system or a few supported combinations of
-                    the upstream GCC or CodeSourcery Labs toolchain.
-                    The variable identifies the <code class="filename">tcmode-*</code> files used in
-                    the <code class="filename">meta/conf/distro/include</code> directory, which is found in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-                </p><p>
-                    By default, <code class="filename">TCMODE</code> is set to "default", which
-                    chooses the <code class="filename">tcmode-default.inc</code> file.
-                    The variable is similar to
-                    <a class="link" href="#var-TCLIBC" title="TCLIBC"><code class="filename">TCLIBC</code></a>, which controls
-                    the variant of the GNU standard C library (<code class="filename">libc</code>)
-                    used during the build process: <code class="filename">eglibc</code> or <code class="filename">uclibc</code>.
-                </p></dd><dt><a id="var-TMPDIR"></a>TMPDIR</dt><dd><p>
-                    This variable is the temporary directory the OpenEmbedded build system
-                    uses when it does its work building images.
-                    By default, the <code class="filename">TMPDIR</code> variable is named
-                    <code class="filename">tmp</code> within the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                </p><p>
-                    If you want to establish this directory in a location other than the
-                    default, you can uncomment the following statement in the
-                    <code class="filename">conf/local.conf</code> file in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>:
-                    </p><pre class="literallayout">
-     #TMPDIR = "${TOPDIR}/tmp"
-                    </pre><p>
-                </p></dd><dt><a id="var-TOPDIR"></a>TOPDIR</dt><dd><p>
-                    This variable is the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>.
-                    BitBake automatically sets this variable.
-                    The OpenEmbedded build system uses the Build Directory when building images.
-                </p></dd></dl></div><div class="glossdiv" title="W"><h3 class="title">W</h3><dl><dt><a id="var-WORKDIR"></a>WORKDIR</dt><dd><p>
-                    The pathname of the working directory in which the OpenEmbedded build system
-                    builds a recipe.
-                    This directory is located within the
-                    <a class="link" href="#var-TMPDIR" title="TMPDIR"><code class="filename">TMPDIR</code></a> directory structure and changes
-                    as different packages are built.
-                </p><p>
-                    The actual <code class="filename">WORKDIR</code> directory depends on several things:
-                    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">The temporary directory - <a class="link" href="#var-TMPDIR" title="TMPDIR"><code class="filename">TMPDIR</code></a></li><li class="listitem">The package architecture - <a class="link" href="#var-PACKAGE_ARCH" title="PACKAGE_ARCH"><code class="filename">PACKAGE_ARCH</code></a></li><li class="listitem">The target machine - <a class="link" href="#var-MACHINE" title="MACHINE"><code class="filename">MACHINE</code></a></li><li class="listitem">The target operating system - <a class="link" href="#var-TARGET_OS" title="TARGET_OS"><code class="filename">TARGET_OS</code></a></li><li class="listitem">The recipe name - <a class="link" href="#var-PN" title="PN"><code class="filename">PN</code></a></li><li class="listitem">The recipe version - <a class="link" href="#var-PV" title="PV"><code class="filename">PV</code></a></li><li class="listitem">The recipe revision - <a class="link" href="#var-PR" title="PR"><code class="filename">PR</code></a></li></ul></div><p>
-                </p><p>
-                    For packages that are not dependent on a particular machine,
-                    <code class="filename">WORKDIR</code> is defined as follows:
-                    </p><pre class="literallayout">
- ${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}/${PV}-${PR}
-                    </pre><p>
-                    As an example, assume a
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a> top-level
-                    folder name <code class="filename">poky</code> and a default
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">Build Directory</a>
-                    at <code class="filename">poky/build</code>.
-                    In this case, the working directory the build system uses to build
-                    the <code class="filename">v86d</code> package is the following:
-                    </p><pre class="literallayout">
-     ~/poky/build/tmp/work/qemux86-poky-linux/v86d/01.9-r0
-                    </pre><p>
-                </p><p>
-                    For packages that are dependent on a particular machine, <code class="filename">WORKDIR</code>
-                    is defined slightly different:
-                    </p><pre class="literallayout">
- ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}/${PV}-${PR}
-                    </pre><p>
-                    As an example, again assume a Source Directory top-level folder
-                    named <code class="filename">poky</code> and a default Build Directory
-                    at <code class="filename">poky/build</code>.
-                    In this case, the working directory the build system uses to build
-                    the <code class="filename">acl</code> recipe, which is being built for a
-                    MIPS-based device, is the following:
-                    </p><pre class="literallayout">
-     ~/poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
-                    </pre><p>
-                </p></dd></dl></div></div></div>
-
-    <div class="chapter" title="Chapter 11. Variable Context"><div class="titlepage"><div><div><h2 class="title"><a id="ref-varlocality"></a>Chapter 11. Variable Context</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#ref-varlocality-configuration">11.1. Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#ref-varlocality-config-distro">11.1.1. Distribution (Distro)</a></span></dt><dt><span class="section"><a href="#ref-varlocality-config-machine">11.1.2. Machine</a></span></dt><dt><span class="section"><a href="#ref-varlocality-config-local">11.1.3. Local</a></span></dt></dl></dd><dt><span class="section"><a href="#ref-varlocality-recipes">11.2. Recipes</a></span></dt><dd><dl><dt><span class="section"><a href="#ref-varlocality-recipe-required">11.2.1. Required</a></span></dt><dt><span class="section"><a href="#ref-varlocality-recipe-dependencies">11.2.2. Dependencies</a></span></dt><dt><span class="section"><a href="#ref-varlocality-recipe-paths">11.2.3. Paths</a></span></dt><dt><span class="section"><a href="#ref-varlocality-recipe-build">11.2.4. Extra Build Information</a></span></dt></dl></dd></dl></div><p>
-        While most variables can be used in almost any context such as
-        <code class="filename">.conf</code>, <code class="filename">.bbclass</code>,
-        <code class="filename">.inc</code>, and <code class="filename">.bb</code> files,
-        some variables are often associated with a particular locality or context.
-        This chapter describes some common associations.
-    </p><div class="section" title="11.1. Configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-varlocality-configuration"></a>11.1. Configuration</h2></div></div></div><p>
-            The following subsections provide lists of variables whose context is
-            configuration: distribution, machine, and local.
-        </p><div class="section" title="11.1.1. Distribution (Distro)"><div class="titlepage"><div><div><h3 class="title"><a id="ref-varlocality-config-distro"></a>11.1.1. Distribution (Distro)</h3></div></div></div><p>
-               This section lists variables whose context is the distribution, or distro.
-               </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename"><a class="link" href="#var-DISTRO" title="DISTRO">DISTRO</a></code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-DISTRO_NAME" title="DISTRO_NAME">DISTRO_NAME</a></code>
-                       </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-DISTRO_VERSION" title="DISTRO_VERSION">DISTRO_VERSION</a>
-                       </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-MAINTAINER" title="MAINTAINER">MAINTAINER</a></code>
-                       </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-PACKAGE_CLASSES" title="PACKAGE_CLASSES">PACKAGE_CLASSES</a>
-                       </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-TARGET_OS" title="TARGET_OS">TARGET_OS</a></code>
-                       </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-TARGET_FPU" title="TARGET_FPU">TARGET_FPU</a></code>
-                       </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-TCMODE" title="TCMODE">TCMODE</a></code>
-                       </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-TCLIBC" title="TCLIBC">TCLIBC</a></code>
-                       </p></li></ul></div><p>
-            </p></div><div class="section" title="11.1.2. Machine"><div class="titlepage"><div><div><h3 class="title"><a id="ref-varlocality-config-machine"></a>11.1.2. Machine</h3></div></div></div><p>
-                This section lists variables whose context is the machine.
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename"><a class="link" href="#var-TARGET_ARCH" title="TARGET_ARCH">TARGET_ARCH</a></code>
-                        </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-SERIAL_CONSOLE" title="SERIAL_CONSOLE">SERIAL_CONSOLE</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-PACKAGE_EXTRA_ARCHS" title="PACKAGE_EXTRA_ARCHS">PACKAGE_EXTRA_ARCHS</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-IMAGE_FSTYPES" title="IMAGE_FSTYPES">IMAGE_FSTYPES</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-MACHINE_FEATURES" title="MACHINE_FEATURES">MACHINE_FEATURES</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-MACHINE_EXTRA_RDEPENDS" title="MACHINE_EXTRA_RDEPENDS">MACHINE_EXTRA_RDEPENDS
-                        </a></code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-MACHINE_EXTRA_RRECOMMENDS" title="MACHINE_EXTRA_RRECOMMENDS">MACHINE_EXTRA_RRECOMMENDS
-                        </a></code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS" title="MACHINE_ESSENTIAL_EXTRA_RDEPENDS">MACHINE_ESSENTIAL_EXTRA_RDEPENDS
-                        </a></code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS" title="MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS">
-                        MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</a></code></p></li></ul></div><p>
-            </p></div><div class="section" title="11.1.3. Local"><div class="titlepage"><div><div><h3 class="title"><a id="ref-varlocality-config-local"></a>11.1.3. Local</h3></div></div></div><p>
-                This section lists variables whose context is the local configuration through the
-                <code class="filename">local.conf</code> file.
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename"><a class="link" href="#var-DISTRO" title="DISTRO">DISTRO</a></code>
-                        </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-MACHINE" title="MACHINE">MACHINE</a></code>
-                        </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-DL_DIR" title="DL_DIR">DL_DIR</a></code>
-                        </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-BBFILES" title="BBFILES">BBFILES</a></code>
-                        </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-EXTRA_IMAGE_FEATURES" title="EXTRA_IMAGE_FEATURES">EXTRA_IMAGE_FEATURES
-                        </a></code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-PACKAGE_CLASSES" title="PACKAGE_CLASSES">PACKAGE_CLASSES</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-BB_NUMBER_THREADS" title="BB_NUMBER_THREADS">BB_NUMBER_THREADS</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-BBINCLUDELOGS" title="BBINCLUDELOGS">BBINCLUDELOGS</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-ENABLE_BINARY_LOCALE_GENERATION" title="ENABLE_BINARY_LOCALE_GENERATION">
-                        ENABLE_BINARY_LOCALE_GENERATION</a></code></p></li></ul></div><p>
-            </p></div></div><div class="section" title="11.2. Recipes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ref-varlocality-recipes"></a>11.2. Recipes</h2></div></div></div><p>
-            The following subsections provide lists of variables whose context is
-            recipes: required, dependencies, path, and extra build information.
-        </p><div class="section" title="11.2.1. Required"><div class="titlepage"><div><div><h3 class="title"><a id="ref-varlocality-recipe-required"></a>11.2.1. Required</h3></div></div></div><p>
-                This section lists variables that are required for recipes.
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename"><a class="link" href="#var-LICENSE" title="LICENSE">LICENSE</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-LIC_FILES_CHKSUM" title="LIC_FILES_CHKSUM">LIC_FILES_CHKSUM</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-SRC_URI" title="SRC_URI">SRC_URI</a></code> - used
-                        in recipes that fetch local or remote files.
-                        </p></li></ul></div><p>
-            </p></div><div class="section" title="11.2.2. Dependencies"><div class="titlepage"><div><div><h3 class="title"><a id="ref-varlocality-recipe-dependencies"></a>11.2.2. Dependencies</h3></div></div></div><p>
-                This section lists variables that define recipe dependencies.
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename"><a class="link" href="#var-DEPENDS" title="DEPENDS">DEPENDS</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-RDEPENDS" title="RDEPENDS">RDEPENDS</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-RRECOMMENDS" title="RRECOMMENDS">RRECOMMENDS</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-RCONFLICTS" title="RCONFLICTS">RCONFLICTS</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-RREPLACES" title="RREPLACES">RREPLACES</a>
-                        </code></p></li></ul></div><p>
-            </p></div><div class="section" title="11.2.3. Paths"><div class="titlepage"><div><div><h3 class="title"><a id="ref-varlocality-recipe-paths"></a>11.2.3. Paths</h3></div></div></div><p>
-                This section lists variables that define recipe paths.
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename"><a class="link" href="#var-WORKDIR" title="WORKDIR">WORKDIR</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-S" title="S">S</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-FILES" title="FILES">FILES</a>
-                        </code></p></li></ul></div><p>
-            </p></div><div class="section" title="11.2.4. Extra Build Information"><div class="titlepage"><div><div><h3 class="title"><a id="ref-varlocality-recipe-build"></a>11.2.4. Extra Build Information</h3></div></div></div><p>
-                This section lists variables that define extra build information for recipes.
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename"><a class="link" href="#var-EXTRA_OECMAKE" title="EXTRA_OECMAKE">EXTRA_OECMAKE</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-EXTRA_OECONF" title="EXTRA_OECONF">EXTRA_OECONF</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-EXTRA_OEMAKE" title="EXTRA_OEMAKE">EXTRA_OEMAKE</a>
-                        </code></p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-PACKAGES" title="PACKAGES">PACKAGES</a></code>
-                        </p></li><li class="listitem"><p><code class="filename"><a class="link" href="#var-DEFAULT_PREFERENCE" title="DEFAULT_PREFERENCE">DEFAULT_PREFERENCE
-                        </a></code></p></li></ul></div><p>
-            </p></div></div></div>
-
-    <div class="chapter" title="Chapter 12. FAQ"><div class="titlepage"><div><div><h2 class="title"><a id="faq"></a>Chapter 12. FAQ</h2></div></div></div><div class="qandaset" title="Frequently Asked Questions"><a id="idm975296"></a><dl><dt>12.1. <a href="#idm974832">
-                How does Poky differ from OpenEmbedded?
-            </a></dt><dt>12.2. <a href="#idp1801248">
-                I only have Python 2.4 or 2.5 but BitBake requires Python 2.6 or 2.7.
-                Can I still use the Yocto Project?
-            </a></dt><dt>12.3. <a href="#idm1781424">
-                How can you claim Poky / OpenEmbedded-Core is stable?
-            </a></dt><dt>12.4. <a href="#idm1777456">
-                How do I get support for my board added to the Yocto Project?
-            </a></dt><dt>12.5. <a href="#idm345792">
-                Are there any products built using the OpenEmbedded build system?
-            </a></dt><dt>12.6. <a href="#idm343136">
-                What does the OpenEmbedded build system produce as output?
-            </a></dt><dt>12.7. <a href="#idm341840">
-                How do I add my package to the Yocto Project?
-            </a></dt><dt>12.8. <a href="#idp1600368">
-                Do I have to reflash my entire board with a new Yocto Project image when recompiling
-                a package?
-            </a></dt><dt>12.9. <a href="#idp1603824">
-                What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME?
-            </a></dt><dt>12.10. <a href="#idp1605872">
-                I see the error 'chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x'.
-                What is wrong?
-            </a></dt><dt>12.11. <a href="#idp1662416">
-                How do I make the Yocto Project work in RHEL/CentOS?
-            </a></dt><dt>12.12. <a href="#idp562304">
-                I see lots of 404 responses for files on
-                http://www.yoctoproject.org/sources/*. Is something wrong?
-            </a></dt><dt>12.13. <a href="#idp179952">
-                I have machine-specific data in a package for one machine only but the package is
-                being marked as machine-specific in all cases, how do I prevent this?
-            </a></dt><dt>12.14. <a href="#idp184672">
-                I'm behind a firewall and need to use a proxy server. How do I do that?
-            </a></dt><dt>12.15. <a href="#idp1585952">
-                What’s the difference between foo and foo-native?
-            </a></dt><dt>12.16. <a href="#idp3269536">
-                I'm seeing random build failures. Help?!
-            </a></dt><dt>12.17. <a href="#idp3271104">
-                What do we need to ship for license compliance?
-            </a></dt><dt>12.18. <a href="#idp3272560">
-                How do I disable the cursor on my touchscreen device?
-            </a></dt><dt>12.19. <a href="#idp3244640">
-                How do I make sure connected network interfaces are brought up by default?
-            </a></dt><dt>12.20. <a href="#idp3248256">
-                How do I create images with more free space?
-            </a></dt><dt>12.21. <a href="#idp348464">
-                Why don't you support directories with spaces in the pathnames?
-            </a></dt><dt>12.22. <a href="#idp350512">
-                How do I use an external toolchain?
-            </a></dt><dt>12.23. <a href="#idm184288">
-                How does the OpenEmbedded build system obtain source code and will it work behind my
-                firewall or proxy server?
-            </a></dt><dt>12.24. <a href="#idm1036560">
-                Can I get rid of build output so I can start over?
-            </a></dt></dl><table border="0" width="100%" summary="Q and A Set"><col align="left" width="1%" /><col /><tbody><tr class="question" title="12.1."><td align="left" valign="top"><a id="idm974832"></a><a id="idm974704"></a><p><strong>12.1.</strong></p></td><td align="left" valign="top"><p>
-                How does Poky differ from <a class="ulink" href="http://www.openembedded.org" target="_top">OpenEmbedded</a>?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                The term "Poky" refers to the specific reference build system that
-                the Yocto Project provides.
-                Poky is based on <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#oe-core" target="_top">OE-Core</a>
-                and BitBake.
-                Thus, the generic term used here for the build system is
-                the "OpenEmbedded build system."
-                Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with
-                changes always being merged to OE-Core or BitBake first before being pulled back
-                into Poky.
-                This practice benefits both projects immediately.
-                For a fuller description of the term "Poky", see the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#poky" target="_top">poky</a> term in the Yocto Project
-                Development Manual.
-            </p></td></tr><tr class="question" title="12.2."><td align="left" valign="top"><a id="idp1801248"></a><a id="idp1801376"></a><p><strong>12.2.</strong></p></td><td align="left" valign="top"><p>
-                I only have Python 2.4 or 2.5 but BitBake requires Python 2.6 or 2.7.
-                Can I still use the Yocto Project?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                You can use a stand-alone tarball to provide Python 2.6.
-                You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://downloads.yoctoproject.org/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2" target="_top">32-bit tarball</a></p></li><li class="listitem"><p><a class="ulink" href="http://downloads.yoctoproject.org/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2" target="_top">64-bit tarball</a></p></li></ul></div><p>
-            </p><p>
-                These tarballs are self-contained with all required libraries and should work
-                on most Linux systems.
-                To use the tarballs extract them into the root
-                directory and run the appropriate command:
-                </p><pre class="literallayout">
-     $ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH
-     $ export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH
-                </pre><p>
-            </p><p>
-                Once you run the command, BitBake uses Python 2.6.
-            </p></td></tr><tr class="question" title="12.3."><td align="left" valign="top"><a id="idm1781424"></a><a id="idm1781296"></a><p><strong>12.3.</strong></p></td><td align="left" valign="top"><p>
-                How can you claim Poky / OpenEmbedded-Core is stable?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                There are three areas that help with stability;
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>The Yocto Project team keeps
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#oe-core" target="_top">OE-Core</a> small
-                        and focused, containing around 830 recipes as opposed to the thousands
-                        available in other OpenEmbedded community layers.
-                        Keeping it small makes it easy to test and maintain.</p></li><li class="listitem"><p>The Yocto Project team runs manual and automated tests
-                        using a small, fixed set of reference hardware as well as emulated
-                        targets.</p></li><li class="listitem"><p>The Yocto Project uses an an autobuilder,
-                        which provides continuous build and integration tests.</p></li></ul></div><p>
-            </p></td></tr><tr class="question" title="12.4."><td align="left" valign="top"><a id="idm1777456"></a><a id="idm1777328"></a><p><strong>12.4.</strong></p></td><td align="left" valign="top"><p>
-                How do I get support for my board added to the Yocto Project?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                Support for an additional board is added by creating a BSP layer for it.
-                For more information on how to create a BSP layer, see the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/bsp-guide/bsp-guide.html" target="_top">Yocto Project Board Support Package (BSP) Developer's Guide</a>.
-            </p><p>
-                Usually, if the board is not completely exotic, adding support in
-                the Yocto Project is fairly straightforward.
-            </p></td></tr><tr class="question" title="12.5."><td align="left" valign="top"><a id="idm345792"></a><a id="idm345664"></a><p><strong>12.5.</strong></p></td><td align="left" valign="top"><p>
-                Are there any products built using the OpenEmbedded build system?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                The software running on the <a class="ulink" href="http://vernier.com/labquest/" target="_top">Vernier LabQuest</a>
-                is built using the OpenEmbedded build system.
-                See the <a class="ulink" href="http://www.vernier.com/products/interfaces/labq/" target="_top">Vernier LabQuest</a>
-                website for more information.
-                There are a number of pre-production devices using the OpenEmbedded build system
-                and the Yocto Project team
-                announces them as soon as they are released.
-            </p></td></tr><tr class="question" title="12.6."><td align="left" valign="top"><a id="idm343136"></a><a id="idm343008"></a><p><strong>12.6.</strong></p></td><td align="left" valign="top"><p>
-                What does the OpenEmbedded build system produce as output?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                Because the same set of recipes can be used to create output of various formats, the
-                output of an OpenEmbedded build depends on how it was started.
-                Usually, the output is a flashable image ready for the target device.
-            </p></td></tr><tr class="question" title="12.7."><td align="left" valign="top"><a id="idm341840"></a><a id="idm341712"></a><p><strong>12.7.</strong></p></td><td align="left" valign="top"><p>
-                How do I add my package to the Yocto Project?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                To add a package, you need to create a BitBake recipe.
-                For information on how to add a package, see the section
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#usingpoky-extend-addpkg" target="_top">Adding a Package</a>"
-                in the Yocto Project Development Manual.
-            </p></td></tr><tr class="question" title="12.8."><td align="left" valign="top"><a id="idp1600368"></a><a id="idp1600496"></a><p><strong>12.8.</strong></p></td><td align="left" valign="top"><p>
-                Do I have to reflash my entire board with a new Yocto Project image when recompiling
-                a package?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                The OpenEmbedded build system can build packages in various formats such as
-                <code class="filename">ipk</code> for <code class="filename">opkg</code>,
-                Debian package (<code class="filename">.deb</code>), or RPM.
-                The packages can then be upgraded using the package tools on the device, much like
-                on a desktop distribution such as Ubuntu or Fedora.
-            </p></td></tr><tr class="question" title="12.9."><td align="left" valign="top"><a id="idp1603824"></a><a id="idp1603952"></a><p><strong>12.9.</strong></p></td><td align="left" valign="top"><p>
-                What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                GNOME Mobile is a subset of the <a class="ulink" href="http://www.gnome.org" target="_top">GNOME</a>
-                platform targeted at mobile and embedded devices.
-                The the main difference between GNOME Mobile and standard GNOME is that
-                desktop-orientated libraries have been removed, along with deprecated libraries,
-                creating a much smaller footprint.
-            </p></td></tr><tr class="question" title="12.10."><td align="left" valign="top"><a id="idp1605872"></a><a id="idp1606000"></a><p><strong>12.10.</strong></p></td><td align="left" valign="top"><p>
-                I see the error '<code class="filename">chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x</code>'.
-                What is wrong?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                You are probably running the build on an NTFS filesystem.
-                Use <code class="filename">ext2</code>, <code class="filename">ext3</code>, or <code class="filename">ext4</code> instead.
-            </p></td></tr><tr class="question" title="12.11."><td align="left" valign="top"><a id="idp1662416"></a><a id="idp1662544"></a><p><strong>12.11.</strong></p></td><td align="left" valign="top"><p>
-                How do I make the Yocto Project work in RHEL/CentOS?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                To get the Yocto Project working under RHEL/CentOS 5.1 you need to first
-                install some required packages.
-                The standard CentOS packages needed are:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>"Development tools" (selected during installation)</p></li><li class="listitem"><p><code class="filename">texi2html</code></p></li><li class="listitem"><p><code class="filename">compat-gcc-34</code></p></li></ul></div><p>
-                On top of these, you need the following external packages:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename">python-sqlite2</code> from
-                        <a class="ulink" href="http://dag.wieers.com/rpm/packages/python-sqlite2/" target="_top">DAG repository</a>
-                        </p></li><li class="listitem"><p><code class="filename">help2man</code> from
-                        <a class="ulink" href="http://centos.karan.org/el4/extras/stable/x86_64/RPMS/repodata/repoview/help2man-0-1.33.1-2.html" target="_top">Karan repository</a></p></li></ul></div><p>
-            </p><p>
-                Once these packages are installed, the OpenEmbedded build system will be able
-                to build standard images.
-                However, there might be a problem with the QEMU emulator segfaulting.
-                You can either disable the generation of binary locales by setting
-                <code class="filename"><a class="link" href="#var-ENABLE_BINARY_LOCALE_GENERATION" title="ENABLE_BINARY_LOCALE_GENERATION">ENABLE_BINARY_LOCALE_GENERATION</a>
-                </code> to "0" or by removing the <code class="filename">linux-2.6-execshield.patch</code>
-                from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.
-            </p></td></tr><tr class="question" title="12.12."><td align="left" valign="top"><a id="idp562304"></a><a id="idp562432"></a><p><strong>12.12.</strong></p></td><td align="left" valign="top"><p>
-                I see lots of 404 responses for files on
-                <code class="filename">http://www.yoctoproject.org/sources/*</code>. Is something wrong?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                Nothing is wrong.
-                The OpenEmbedded build system checks any configured source mirrors before downloading
-                from the upstream sources.
-                The build system does this searching for both source archives and
-                pre-checked out versions of SCM managed software.
-                These checks help in large installations because it can reduce load on the SCM servers
-                themselves.
-                The address above is one of the default mirrors configured into the
-                build system.
-                Consequently, if an upstream source disappears, the team
-                can place sources there so builds continue to work.
-            </p></td></tr><tr class="question" title="12.13."><td align="left" valign="top"><a id="idp179952"></a><a id="idp180080"></a><p><strong>12.13.</strong></p></td><td align="left" valign="top"><p>
-                I have machine-specific data in a package for one machine only but the package is
-                being marked as machine-specific in all cases, how do I prevent this?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                Set <code class="filename"><a class="link" href="#var-SRC_URI_OVERRIDES_PACKAGE_ARCH" title="SRC_URI_OVERRIDES_PACKAGE_ARCH">SRC_URI_OVERRIDES_PACKAGE_ARCH</a>
-                </code> = "0" in the <code class="filename">.bb</code> file but make sure the package is
-                manually marked as
-                machine-specific in the case that needs it.
-                The code that handles <code class="filename">SRC_URI_OVERRIDES_PACKAGE_ARCH</code> is in <code class="filename">base.bbclass</code>.
-            </p></td></tr><tr class="question" title="12.14."><td align="left" valign="top"><a id="idp184672"></a><a id="idp1581568"></a><p><strong>12.14.</strong></p></td><td align="left" valign="top"><p>
-                I'm behind a firewall and need to use a proxy server. How do I do that?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                Most source fetching by the OpenEmbedded build system is done by <code class="filename">wget</code>
-                and you therefore need to specify the proxy settings in a
-                <code class="filename">.wgetrc</code> file in your home directory.
-                Example settings in that file would be
-                </p><pre class="literallayout">
-     http_proxy = http://proxy.yoyodyne.com:18023/
-     ftp_proxy = http://proxy.yoyodyne.com:18023/
-                </pre><p>
-                The Yocto Project also includes a <code class="filename">site.conf.sample</code>
-                file that shows how to configure CVS and Git proxy servers
-                if needed.
-            </p></td></tr><tr class="question" title="12.15."><td align="left" valign="top"><a id="idp1585952"></a><a id="idp1586080"></a><p><strong>12.15.</strong></p></td><td align="left" valign="top"><p>
-                What’s the difference between <code class="filename">foo</code> and <code class="filename">foo-native</code>?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                The <code class="filename">*-native</code> targets are designed to run on the system
-                being used for the build.
-                These are usually tools that are needed to assist the build in some way such as
-                <code class="filename">quilt-native</code>, which is used to apply patches.
-                The non-native version is the one that runs on the target device.
-            </p></td></tr><tr class="question" title="12.16."><td align="left" valign="top"><a id="idp3269536"></a><a id="idp3269664"></a><p><strong>12.16.</strong></p></td><td align="left" valign="top"><p>
-                I'm seeing random build failures. Help?!
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                If the same build is failing in totally different and random ways,
-                the most likely explanation is that either the hardware you're running the
-                build on has some problem, or, if you are running the build under virtualisation,
-                the virtualisation probably has bugs.
-                The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and
-                CPU activity and is sensitive to even single bit failures in any of these areas.
-                True random failures have always been traced back to hardware or virtualisation issues.
-            </p></td></tr><tr class="question" title="12.17."><td align="left" valign="top"><a id="idp3271104"></a><a id="idp3271232"></a><p><strong>12.17.</strong></p></td><td align="left" valign="top"><p>
-                What do we need to ship for license compliance?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                This is a difficult question and you need to consult your lawyer for the answer
-                for your specific case.
-                It is worth bearing in mind that for GPL compliance there needs to be enough
-                information shipped to allow someone else to rebuild the same end result
-                you are shipping.
-                This means sharing the source code, any patches applied to it, and also any
-                configuration information about how that package was configured and built.
-            </p></td></tr><tr class="question" title="12.18."><td align="left" valign="top"><a id="idp3272560"></a><a id="idp3272688"></a><p><strong>12.18.</strong></p></td><td align="left" valign="top"><p>
-                How do I disable the cursor on my touchscreen device?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                You need to create a form factor file as described in the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/bsp-guide/bsp-guide.html#bsp-filelayout-misc-recipes" target="_top">Miscellaneous Recipe Files</a>"
-                section and set the <code class="filename">HAVE_TOUCHSCREEN</code> variable equal to one as follows:
-                </p><pre class="literallayout">
-     HAVE_TOUCHSCREEN=1
-                </pre><p>
-            </p></td></tr><tr class="question" title="12.19."><td align="left" valign="top"><a id="idp3244640"></a><a id="idp3244768"></a><p><strong>12.19.</strong></p></td><td align="left" valign="top"><p>
-                How do I make sure connected network interfaces are brought up by default?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                The default interfaces file provided by the netbase recipe does not
-                automatically bring up network interfaces.
-                Therefore, you will need to add a BSP-specific netbase that includes an interfaces
-                file.
-                See the "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/bsp-guide/bsp-guide.html#bsp-filelayout-misc-recipes" target="_top">Miscellaneous Recipe Files</a>"
-                section for information on creating these types of miscellaneous recipe files.
-            </p><p>
-                For example, add the following files to your layer:
-                </p><pre class="literallayout">
-     meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
-     meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
-                </pre><p>
-            </p></td></tr><tr class="question" title="12.20."><td align="left" valign="top"><a id="idp3248256"></a><a id="idp3248384"></a><p><strong>12.20.</strong></p></td><td align="left" valign="top"><p>
-                How do I create images with more free space?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                Images are created to be 1.2 times the size of the populated root filesystem.
-                To modify this ratio so that there is more free space available, you need to
-                set the configuration value <code class="filename">IMAGE_OVERHEAD_FACTOR</code>.
-                For example, setting <code class="filename">IMAGE_OVERHEAD_FACTOR</code> to 1.5 sets
-                the image size ratio to one and a half times the size of the populated
-                root filesystem.
-                </p><pre class="literallayout">
-     IMAGE_OVERHEAD_FACTOR = "1.5"
-                </pre><p>
-            </p></td></tr><tr class="question" title="12.21."><td align="left" valign="top"><a id="idp348464"></a><a id="idp348592"></a><p><strong>12.21.</strong></p></td><td align="left" valign="top"><p>
-                Why don't you support directories with spaces in the pathnames?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                The Yocto Project team has tried to do this before but too many of the tools
-                the OpenEmbedded build system depends on such as <code class="filename">autoconf</code>
-                break when they find spaces in pathnames.
-                Until that situation changes, the team will not support spaces in pathnames.
-            </p></td></tr><tr class="question" title="12.22."><td align="left" valign="top"><a id="idp350512"></a><a id="idp350640"></a><p><strong>12.22.</strong></p></td><td align="left" valign="top"><p>
-                How do I use an external toolchain?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                The toolchain configuration is very flexible and customizable.
-                It is primarily controlled with the
-                <code class="filename"><a class="link" href="#var-TCMODE" title="TCMODE">TCMODE</a></code> variable.
-                This variable controls which <code class="filename">tcmode-*.inc</code> file to include
-                from the <code class="filename">meta/conf/distro/include</code> directory within the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">source directory</a>.
-            </p><p>
-                The default value of <code class="filename">TCMODE</code> is "default"
-                (i.e. <code class="filename">tcmode-default.inc</code>).
-                However, other patterns are accepted.
-                In particular, "external-*" refers to external toolchains of which there are some
-                basic examples included in the OpenEmbedded Core (<code class="filename">meta</code>).
-                You can use your own custom toolchain definition in your own layer
-                (or as defined in the <code class="filename">local.conf</code> file) at the location
-                <code class="filename">conf/distro/include/tcmode-*.inc</code>.
-            </p><p>
-                In addition to the toolchain configuration, you also need a corresponding toolchain recipe file.
-                This recipe file needs to package up any pre-built objects in the toolchain such as
-                <code class="filename">libgcc</code>, <code class="filename">libstdcc++</code>,
-                any locales, and <code class="filename">libc</code>.
-                An example is the <code class="filename">external-sourcery-toolchain.bb</code>, which is located
-                in <code class="filename">meta/recipes-core/meta/</code> within the source directory.
-            </p></td></tr><tr class="question" title="12.23."><td align="left" valign="top"><a id="idm184288"></a><a id="idm1835680"></a><p><strong>12.23.</strong></p></td><td align="left" valign="top"><p><a id="how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server"></a>
-                How does the OpenEmbedded build system obtain source code and will it work behind my
-                firewall or proxy server?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                The way the build system obtains source code is highly configurable.
-                You can setup the build system to get source code in most environments if
-                HTTP transport is available.
-            </p><p>
-                When the build system searches for source code, it first tries the local download directory.
-                If that location fails, Poky tries PREMIRRORS, the upstream source,
-                and then MIRRORS in that order.
-            </p><p>
-                By default, the OpenEmbedded build system uses the Yocto Project source PREMIRRORS
-                for SCM-based sources,
-                upstreams for normal tarballs, and then falls back to a number of other mirrors
-                including the Yocto Project source mirror if those fail.
-            </p><p>
-                As an example, you could add a specific server for Poky to attempt before any
-                others by adding something like the following to the <code class="filename">local.conf</code>
-                configuration file:
-                </p><pre class="literallayout">
-     PREMIRRORS_prepend = "\
-     git://.*/.* http://www.yoctoproject.org/sources/ \n \
-     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
-     http://.*/.* http://www.yoctoproject.org/sources/ \n \
-     https://.*/.* http://www.yoctoproject.org/sources/ \n"
-                </pre><p>
-            </p><p>
-                These changes cause Poky to intercept Git, FTP, HTTP, and HTTPS
-                requests and direct them to the <code class="filename">http://</code> sources mirror.
-                You can use <code class="filename">file://</code> URLs to point to local directories
-                or network shares as well.
-            </p><p>
-                Aside from the previous technique, these options also exist:
-                </p><pre class="literallayout">
-     BB_NO_NETWORK = "1"
-                </pre><p>
-                 This statement tells BitBake to throw an error instead of trying to access the
-                 Internet.
-                 This technique is useful if you want to ensure code builds only from local sources.
-             </p><p>
-                 Here is another technique:
-                 </p><pre class="literallayout">
-     BB_FETCH_PREMIRRORONLY = "1"
-                 </pre><p>
-                 This statement limits Poky to pulling source from the PREMIRRORS only.
-                 Again, this technique is useful for reproducing builds.
-             </p><p>
-                 Here is another technique:
-                 </p><pre class="literallayout">
-     BB_GENERATE_MIRROR_TARBALLS = "1"
-                 </pre><p>
-                 This statement tells Poky to generate mirror tarballs.
-                 This technique is useful if you want to create a mirror server.
-                 If not, however, the technique can simply waste time during the build.
-             </p><p>
-                 Finally, consider an example where you are behind an HTTP-only firewall.
-                 You could make the following changes to the <code class="filename">local.conf</code>
-                 configuration file as long as the PREMIRROR server is up to date:
-                 </p><pre class="literallayout">
-     PREMIRRORS_prepend = "\
-     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
-     http://.*/.* http://www.yoctoproject.org/sources/ \n \
-     https://.*/.* http://www.yoctoproject.org/sources/ \n"
-     BB_FETCH_PREMIRRORONLY = "1"
-                 </pre><p>
-                 These changes would cause Poky to successfully fetch source over HTTP and
-                 any network accesses to anything other than the PREMIRROR would fail.
-             </p><p>
-                 The build system also honors the standard shell environment variables
-                 <code class="filename">http_proxy</code>, <code class="filename">ftp_proxy</code>,
-                 <code class="filename">https_proxy</code>, and <code class="filename">all_proxy</code>
-                 to redirect requests through proxy servers.
-             </p></td></tr><tr class="question" title="12.24."><td align="left" valign="top"><a id="idm1036560"></a><a id="idm1036432"></a><p><strong>12.24.</strong></p></td><td align="left" valign="top"><p>
-                Can I get rid of build output so I can start over?
-            </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
-                Yes - you can easily do this.
-                When you use BitBake to build an image, all the build output goes into the
-                directory created when you source the <code class="filename">oe-init-build-env</code>
-                setup file.
-                By default, this <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#build-directory" target="_top">build directory</a>
-                is named <code class="filename">build</code> but can be named
-                anything you want.
-            </p><p>
-                Within the build directory is the <code class="filename">tmp</code> directory.
-                To remove all the build output yet preserve any source code or downloaded files
-                from previous builds, simply remove the <code class="filename">tmp</code> directory.
-            </p></td></tr></tbody></table></div></div>
-
-    <div class="chapter" title="Chapter 13. Contributing to the Yocto Project"><div class="titlepage"><div><div><h2 class="title"><a id="resources"></a>Chapter 13. Contributing to the Yocto Project</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#resources-intro">13.1. Introduction</a></span></dt><dt><span class="section"><a href="#resources-bugtracker">13.2. Tracking Bugs</a></span></dt><dt><span class="section"><a href="#resources-mailinglist">13.3. Mailing lists</a></span></dt><dt><span class="section"><a href="#resources-irc">13.4. Internet Relay Chat (IRC)</a></span></dt><dt><span class="section"><a href="#resources-links">13.5. Links</a></span></dt><dt><span class="section"><a href="#resources-contributions">13.6. Contributions</a></span></dt></dl></div><div class="section" title="13.1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="resources-intro"></a>13.1. Introduction</h2></div></div></div><p>
-        The Yocto Project team is happy for people to experiment with the Yocto Project.
-        A number of places exist to find help if you run into difficulties or find bugs.
-        To find out how to download source code,
-        see the "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#local-yp-release" target="_top">Yocto Project Release</a>"
-        list item in the Yocto Project Development Manual.
-    </p></div><div class="section" title="13.2. Tracking Bugs"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="resources-bugtracker"></a>13.2. Tracking Bugs</h2></div></div></div><p>
-        If you find problems with the Yocto Project, you should report them using the
-        Bugzilla application at <a class="ulink" href="http://bugzilla.yoctoproject.org" target="_top">http://bugzilla.yoctoproject.org</a>.
-    </p></div><div class="section" title="13.3. Mailing lists"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="resources-mailinglist"></a>13.3. Mailing lists</h2></div></div></div><p>
-        There are a number of mailing lists maintained by the Yocto Project as well as
-        related OpenEmbedded mailing lists for discussion, patch submission and announcements.
-        To subscribe to one of the following mailing lists, click on the appropriate URL
-        in the following list and follow the instructions:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://lists.yoctoproject.org/listinfo/yocto" target="_top">http://lists.yoctoproject.org/listinfo/yocto</a> -
-                General Yocto Project discussion mailing list. </p></li><li class="listitem"><p><a class="ulink" href="http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core" target="_top">http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core</a> -
-                Discussion mailing list about OpenEmbedded-Core (the core metadata).</p></li><li class="listitem"><p><a class="ulink" href="http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel" target="_top">http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel</a> -
-                Discussion mailing list about OpenEmbedded.</p></li><li class="listitem"><p><a class="ulink" href="http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel" target="_top">http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel</a> -
-                Discussion mailing list about the BitBake build tool.</p></li><li class="listitem"><p><a class="ulink" href="http://lists.yoctoproject.org/listinfo/poky" target="_top">http://lists.yoctoproject.org/listinfo/poky</a> -
-                Discussion mailing list about Poky.</p></li><li class="listitem"><p><a class="ulink" href="http://lists.yoctoproject.org/listinfo/yocto-announce" target="_top">http://lists.yoctoproject.org/listinfo/yocto-announce</a> -
-                Mailing list to receive official Yocto Project release and milestone
-                announcements.</p></li></ul></div><p>
-    </p></div><div class="section" title="13.4. Internet Relay Chat (IRC)"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="resources-irc"></a>13.4. Internet Relay Chat (IRC)</h2></div></div></div><p>
-        Two IRC channels on freenode are available for the Yocto Project and Poky discussions:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename">#yocto</code></p></li><li class="listitem"><p><code class="filename">#poky</code></p></li></ul></div><p>
-    </p></div><div class="section" title="13.5. Links"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="resources-links"></a>13.5. Links</h2></div></div></div><p>
-        Following is a list of resources you will find helpful:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><a class="ulink" href="http://www.yoctoproject.org" target="_top">The Yocto Project website</a>:
-                </em></span> The home site for the Yocto Project.</p></li><li class="listitem"><p><span class="emphasis"><em><a class="ulink" href="http://www.intel.com/" target="_top">Intel Corporation</a>:</em></span>
-                The company who acquired OpenedHand in 2008 and began development on the
-                Yocto Project.</p></li><li class="listitem"><p><span class="emphasis"><em><a class="ulink" href="http://www.openembedded.org" target="_top">OpenEmbedded</a>:</em></span>
-                The upstream, generic, embedded distribution used as the basis for the build system in the
-                Yocto Project.
-                Poky derives from and contributes back to the OpenEmbedded project.</p></li><li class="listitem"><p><span class="emphasis"><em><a class="ulink" href="http://developer.berlios.de/projects/bitbake/" target="_top">
-                BitBake</a>:</em></span> The tool used to process metadata.</p></li><li class="listitem"><p><span class="emphasis"><em>BitBake User Manual:</em></span>
-                A comprehensive guide to the BitBake tool.
-                You can find the BitBake User Manual in the <code class="filename">bitbake/doc/manual</code>
-                directory, which is found in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#source-directory" target="_top">Source Directory</a>.
-                </p></li><li class="listitem"><p><span class="emphasis"><em><a class="ulink" href="http://wiki.qemu.org/Index.html" target="_top">QEMU</a>:
-                </em></span> An open source machine emulator and virtualizer.</p></li></ul></div><p>
-    </p></div><div class="section" title="13.6. Contributions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="resources-contributions"></a>13.6. Contributions</h2></div></div></div><p>
-        The Yocto Project gladly accepts contributions.
-        You can submit changes to the project either by creating and sending pull requests,
-        or by submitting patches through email.
-        For information on how to do both, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#how-to-submit-a-change" target="_top">How to Submit a Change</a>"
-        section in the Yocto Project Development Manual.
-    </p></div></div>
-
-
-
-</div></body></html>
diff --git a/documentation/ref-manual/ref-manual.pdf b/documentation/ref-manual/ref-manual.pdf
deleted file mode 100644
index 4dd9f7a..0000000
--- a/documentation/ref-manual/ref-manual.pdf
+++ /dev/null
diff --git a/documentation/ref-manual/ref-manual.tgz b/documentation/ref-manual/ref-manual.tgz
deleted file mode 100644
index e4a17c8..0000000
--- a/documentation/ref-manual/ref-manual.tgz
+++ /dev/null
author	Scott Rifenbark <scott.m.rifenbark@intel.com>	2012-12-12 09:31:39 -0600
committer	Richard Purdie <richard.purdie@linuxfoundation.org>	2013-01-07 14:43:26 +0000
commit	2855f7e92f656ee1517ef5733b5b6fdcac1cddc8 (patch)
tree	d0eb34fdce79a5a8e63dc5fd4dcfe15437023c77 /documentation/ref-manual
parent	8753c6b2888cbe64760800cba1e55e4ce53309d2 (diff)
download	ast2050-yocto-poky-2855f7e92f656ee1517ef5733b5b6fdcac1cddc8.zip ast2050-yocto-poky-2855f7e92f656ee1517ef5733b5b6fdcac1cddc8.tar.gz