documentation: Updated Manual Revision Tables for 1.1.2

Updated the tables for the adt, bsp, dev, kernel, and ref manuals
so the release date is "July 2012".

(From yocto-docs rev: fc4cb441031bca79f09203f9268f0528078fb652)

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

bitbake/lib/bb/persist_data.py

@@ -47,9 +47,10 @@ if hasattr(sqlite3, 'enable_shared_cache'):
 @total_ordering
 class SQLTable(collections.MutableMapping):
     """Object representing a table/domain in the database"""
-    def __init__(self, cursor, table):
-        self.cursor = cursor
+    def __init__(self, cachefile, table):
+        self.cachefile = cachefile
         self.table = table
+        self.cursor = connect(self.cachefile)
 
         self._execute("CREATE TABLE IF NOT EXISTS %s(key TEXT, value TEXT);"
                       % table)
@@ -63,6 +64,8 @@ class SQLTable(collections.MutableMapping):
             except sqlite3.OperationalError as exc:
                 if 'database is locked' in str(exc) and count < 500:
                     count = count + 1
+                    self.cursor.close()
+                    self.cursor = connect(self.cachefile)
                     continue
                 raise
 
@@ -188,7 +191,7 @@ class PersistData(object):
         del self.data[domain][key]
 
 def connect(database):
-    return sqlite3.connect(database, timeout=30, isolation_level=None)
+    return sqlite3.connect(database, timeout=5, isolation_level=None)
 
 def persist(domain, d):
     """Convenience factory for SQLTable objects based upon metadata"""
@@ -201,5 +204,4 @@ def persist(domain, d):
 
     bb.utils.mkdirhier(cachedir)
     cachefile = os.path.join(cachedir, "bb_persist_data.sqlite3")
-    connection = connect(cachefile)
-    return SQLTable(connection, domain)
+    return SQLTable(cachefile, domain)

bitbake/lib/bb/runqueue.py

@@ -1421,18 +1421,20 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
             sq_revdeps.append(copy.copy(self.rqdata.runq_revdeps[task]))
             sq_revdeps_new.append(set())
             if (len(self.rqdata.runq_revdeps[task]) == 0) and task not in self.rqdata.runq_setscene:
-                endpoints[task] = None
+                endpoints[task] = set()
 
         for task in self.rqdata.runq_setscene:
             for dep in self.rqdata.runq_depends[task]:
-                    endpoints[dep] = task
+                    if dep not in endpoints:
+                        endpoints[dep] = set()
+                    endpoints[dep].add(task)
 
         def process_endpoints(endpoints):
             newendpoints = {}
             for point, task in endpoints.items():
                 tasks = set()
                 if task:
-                    tasks.add(task)
+                    tasks |= task
                 if sq_revdeps_new[point]:
                     tasks |= sq_revdeps_new[point]
                 sq_revdeps_new[point] = set()
@@ -1457,6 +1459,28 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
             elif len(sq_revdeps_new[task]) != 0:
                 bb.msg.fatal("RunQueue", "Something went badly wrong during scenequeue generation, aborting. Please report this problem.")
 
+        # Resolve setscene inter-task dependencies
+        # e.g. do_sometask_setscene[depends] = "targetname:do_someothertask_setscene"
+        # Note that anything explicitly depended upon will have its reverse dependencies removed to avoid circular dependencies
+        for task in self.rqdata.runq_setscene:
+                realid = self.rqdata.taskData.gettask_id(self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]], self.rqdata.runq_task[task] + "_setscene", False)
+                idepends = self.rqdata.taskData.tasks_idepends[realid]
+                for (depid, idependtask) in idepends:
+                    if depid not in self.rqdata.taskData.build_targets:
+                        continue
+
+                    depdata = self.rqdata.taskData.build_targets[depid][0]
+                    if depdata is None:
+                         continue
+                    dep = self.rqdata.taskData.fn_index[depdata]
+                    taskid = self.rqdata.get_task_id(self.rqdata.taskData.getfn_id(dep), idependtask.replace("_setscene", ""))
+                    if taskid is None:
+                        bb.msg.fatal("RunQueue", "Task %s depends upon nonexistant task %s:%s" % (self.rqdata.taskData.tasks_name[realid], dep, idependtask))
+
+                    sq_revdeps_squash[self.rqdata.runq_setscene.index(task)].add(self.rqdata.runq_setscene.index(taskid))
+                    # Have to zero this to avoid circular dependencies
+                    sq_revdeps_squash[self.rqdata.runq_setscene.index(taskid)] = set()
+
         #for task in xrange(len(sq_revdeps_squash)):
         #    print "Task %s: %s.%s is %s " % (task, self.taskData.fn_index[self.runq_fnid[self.runq_setscene[task]]], self.runq_task[self.runq_setscene[task]] + "_setscene", sq_revdeps_squash[task])
 

documentation/adt-manual/adt-command.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='using-the-command-line'>
 <title>Using the Command Line</title>

documentation/adt-manual/adt-eclipse.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='adt-eclipse'>
 <title>Working Within Eclipse</title>
@@ -34,6 +35,11 @@
             <listitem><para>Install the Eclipse Yocto Plug-in.</para></listitem>
             <listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem>
         </orderedlist>
+        <note>
+            Do not install Eclipse from your distribution's package repository.
+            Be sure to install Eclipse from the official Eclipse download site as directed
+            in the next section.
+        </note>
     </para>
 
     <section id='installing-eclipse-ide'>
@@ -43,7 +49,7 @@
             It is recommended that you have the Indigo 3.7 version of the 
             Eclipse IDE installed on your development system.  
             If you don’t have this version, you can find it at 
-            <ulink url='http://www.eclipse.org/downloads'></ulink>.  
+            <ulink url='&ECLIPSE_MAIN_URL;'></ulink>.  
             From that site, choose the Eclipse Classic version particular to your development
             host.  
             This version contains the Eclipse Platform, the Java Development 
@@ -100,20 +106,22 @@
                 <listitem><para>Make sure you are in your Workbench and select 
                     "Install New Software" from the "Help" pull-down menu.
                     </para></listitem>
-                <listitem><para>Select <filename>indigo - http://download.eclipse.org/releases/indigo</filename>
+                <listitem><para>Select <filename>indigo - &ECLIPSE_INDIGO_URL;</filename>
                     from the "Work with:" pull-down menu.</para></listitem>
                 <listitem><para>Expand the box next to <filename>Programming Languages</filename>
                     and select the <filename>Autotools Support for CDT (incubation)</filename>
                     and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
+                <listitem><para>Expand the box next to "Linux Tools" and select the 
+                    "LTTng - Linux Tracing Toolkit(incubation)" boxes.</para></listitem>
                 <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
                 <listitem><para>After the Eclipse IDE restarts and from the Workbench, select 
                     "Install New Software" from the "Help" pull-down menu.</para></listitem>
                 <listitem><para>Click the 
                     "Available Software Sites" link.</para></listitem>
                 <listitem><para>Check the box next to 
-                    <filename>http://download.eclipse.org/tm/updates/3.3</filename>
+                    <filename>&ECLIPSE_UPDATES_URL;</filename>
                     and click "OK".</para></listitem>
-                <listitem><para>Select <filename>http://download.eclipse.org/tm/updates/3.3</filename>
+                <listitem><para>Select <filename>&ECLIPSE_UPDATES_URL;</filename>
                     from the "Work with:" pull-down menu.</para></listitem>
                 <listitem><para>Check the box next to <filename>TM and RSE Main Features</filename>.
                     </para></listitem>
@@ -127,7 +135,7 @@
                 <listitem><para>After clicking "Available Software Sites", check the box next to 
                     <filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename>
                     and click "OK".</para></listitem>
-                <listitem><para>Select <filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename>
+                <listitem><para>Select <filename>&ECLIPSE_INDIGO_CDT_URL;</filename>
                     from the "Work with:" pull-down menu.</para></listitem>
                 <listitem><para>Check the box next to <filename>CDT Main Features</filename>.
                     </para></listitem>
@@ -162,7 +170,7 @@
                     <listitem><para>In Eclipse, select "Install New Software" from the "Help" menu.</para></listitem>
                     <listitem><para>Click "Add..." in the "Work with:" area.</para></listitem>
                     <listitem><para>Enter 
-                        <filename>http://downloads.yoctoproject.org/releases/eclipse-plugin/1.1.1</filename> 
+                        <filename>&ECLIPSE_DL_PLUGIN_URL;</filename> 
                         in the URL field and provide a meaningful name in the "Name" field.</para></listitem>
                     <listitem><para>Click "OK" to have the entry added to the "Work with:" 
                         drop-down list.</para></listitem>
@@ -204,9 +212,9 @@
                         name of the Git branch along with the Yocto Project release you are 
                         using.
                         Here is an example that uses the <filename>master</filename> Git repository
-                        and the <filename>1.1.1</filename> release:
+                        and the <filename>&DISTRO;</filename> release:
                         <literallayout class='monospaced'>
-     $ scripts/build.sh master 1.1.1 
+     $ scripts/build.sh master &DISTRO; 
                         </literallayout>
                         After running the script, the file
                         <filename>org.yocto.sdk-&lt;release&gt;-&lt;date&gt;-archive.zip</filename>
@@ -322,7 +330,7 @@
                         </para></listitem>
                     <listitem><para><emphasis>Point to the Toolchain:</emphasis>
                         If you are using a stand-alone pre-built toolchain, you should be pointing to the
-                        <filename>/opt/poky/1.1.1</filename> directory.
+                        <filename>&YOCTO_ADTPATH_DIR;</filename> directory.
                         This is the location for toolchains installed by the ADT Installer or by hand.
                         Sections "<link linkend='configuring-and-running-the-adt-installer-script'>Configuring 
                         and Running the ADT Installer Script</link>" and 
@@ -354,7 +362,7 @@
                         The pull-down menu should have the supported architectures.  
                         If the architecture you need is not listed in the menu, you 
                         will need to build the image.
-                        See the "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section 
+                        See the "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section 
                         of The Yocto Project Quick Start for more information.</para></listitem>
                 </itemizedlist>
             </para>
@@ -581,14 +589,14 @@
                 host can use, you must have <filename>oprofile</filename> version 0.9.4 or 
                 greater installed on the host.</para>
                 <para>You can locate both the viewer and server from 
-                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/oprofileui/'></ulink>.
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>.
                 <note>The <filename>oprofile-server</filename> is installed by default on 
                 the <filename>core-image-sato-sdk</filename> image.</note></para></listitem>
-            <listitem><para><emphasis><filename>Lttng-ust</filename>:</emphasis> Selecting this tool runs 
-                <filename>usttrace</filename> on the remote target, transfers the output data back to the 
-                local host machine, and uses <filename>lttv-gui</filename> to graphically display the output.  
-                The <filename>lttv-gui</filename> must be installed on the local host machine to use this tool.  
-                For information on how to use <filename>lttng</filename> to trace an application, see 
+            <listitem><para><emphasis><filename>Lttng-ust</filename>:</emphasis> Selecting this tool runs
+                <filename>usttrace</filename> on the remote target, transfers the output data back 
+                to the local host machine, and uses the <filename>lttng</filename> Eclipse plug-in to 
+                graphically display the output. 
+                For information on how to use <filename>lttng</filename> to trace an application, see
                 <ulink url='http://lttng.org/files/ust/manual/ust.html'></ulink>.</para>
                 <para>For <filename>Application</filename>, you must supply the absolute path name of the 
                 application to be traced by user mode <filename>lttng</filename>.  
@@ -596,7 +604,32 @@
                 <filename>usttrace /path/to/foo</filename> on the remote target to trace the 
                 program <filename>/path/to/foo</filename>.</para>
                 <para><filename>Argument</filename> is passed to <filename>usttrace</filename>
-                running on the remote target.</para></listitem>
+                running on the remote target.</para>
+                <para>Before you use the <filename>lttng-ust</filename> tool, you need to setup 
+                the <filename>lttng</filename> Eclipse plug-in and create a <filename>lttng</filename>
+                project.
+                Do the following:
+                <orderedlist>
+                    <listitem><para>Follow these 
+                        <ulink url='http://wiki.eclipse.org/Linux_Tools_Project/LTTng#Downloading_and_installing_the_LTTng_parser_library'>instructions</ulink>
+                        to download and install the <filename>lttng</filename> parser library.
+                        </para></listitem>
+                    <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
+                        and then select <filename>LTTng</filename>.</para></listitem>
+                    <listitem><para>Click <filename>OK</filename> to change the Eclipse perspective 
+                        into the <filename>LTTng</filename> perspective.</para></listitem>
+                    <listitem><para>Create a new <filename>LTTng</filename> project by selecting 
+                        <filename>File -> New -> Project</filename>.</para></listitem>
+                    <listitem><para>Choose <filename>LTTng -> LTTng Project</filename>.</para></listitem>
+                    <listitem><para>Click <filename>YoctoTools -> lttng-ust</filename> to start user mode 
+                        <filename>lttng</filename> on the remote target.</para></listitem>
+                </orderedlist></para>
+                <para>After the output data has been transferred from the remote target back to the local
+                host machine, new traces will be imported into the selected <filename>LTTng</filename> project.
+                Then you can go to the <filename>LTTng</filename> project, right click the imported 
+                trace, and set the trace type as the <filename>LTTng</filename> kernel trace.
+                Finally, right click the imported trace and select <filename>Open</filename>
+                to display the data graphically.</para></listitem>
             <listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis> Selecting this tool runs 
                 <filename>powertop</filename> on the remote target machine and displays the results in a 
                 new view called <filename>powertop</filename>.</para>

documentation/adt-manual/adt-intro.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='adt-intro'>
 
@@ -106,7 +107,7 @@
                 <listitem><para><emphasis>PowerTOP:</emphasis> Helps you determine what   
                     software is using the most power.  
                     You can find out more about PowerTOP at 
-                    <ulink url='http://www.linuxpowertop.org/'></ulink>.</para></listitem>
+                    <ulink url='https://01.org/powertop/'></ulink>.</para></listitem>
                 <listitem><para><emphasis>OProfile:</emphasis> A system-wide profiler for Linux 
                     systems that is capable of profiling all running code at low overhead.  
                     You can find out more about OProfile at 

documentation/adt-manual/adt-manual.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='adt-manual' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -48,10 +49,15 @@
                 <date>15 March 2012</date>
                 <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2010-2012</year>
+      <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -63,9 +69,9 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and the 
-          <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
+          <ulink url='&YOCTO_DOCS_ADT_URL;'>
           Application Developer's Toolkit (ADT) User's Guide</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
 

documentation/adt-manual/adt-package.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='adt-package'>
 <title>Optionally Customizing the Development Packages Installation</title>
@@ -54,7 +55,7 @@
 
     <note>
         For build performance information related to the PMS, see
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in The Yocto Project Reference Manual.
+        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in The Yocto Project Reference Manual.
     </note>
 
     <para>

documentation/adt-manual/adt-prepare.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='adt-prepare'>
 
@@ -56,9 +57,9 @@
             <para>
                 The ADT Installer is contained in the ADT Installer tarball.
                 You can download the tarball into any directory from the 
-                <ulink url='http://downloads.yoctoproject.org/releases'>Index of Releases</ulink>, specifically
+                <ulink url='&YOCTO_DL_URL;/releases'>Index of Releases</ulink>, specifically
                 at  
-                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/adt_installer'></ulink>.
+                <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink>.
                 Or, you can use BitBake to generate the tarball inside the existing Yocto Project 
                 build tree.
             </para>
@@ -81,9 +82,9 @@
      $ cd ~
      $ mkdir yocto-project
      $ cd yocto-project
-     $ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/poky-edison-6.0.1.tar.bz2
-     $ tar xjf poky-edison-6.0.1.tar.bz2
-     $ source poky-edison-6.0.1/oe-init-build-env
+     $ wget &YOCTO_RELEASE_DL_URL;/&YOCTO_POKY_TARBALL;
+     $ tar xjf &YOCTO_POKY_TARBALL;
+     $ source &OE_INIT_PATH;
      $ bitbake adt-installer
                 </literallayout>
             </para>
@@ -100,7 +101,7 @@
                 a top-level directory named <filename>adt-installer</filename>:
                 <literallayout class='monospaced'>
      $ cd ~
-     $ cp ~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
+     $ cp ~/poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
      $ tar -xjf adt_installer.tar.bz2
                 </literallayout>
                 Unpacking it creates the directory <filename>adt-installer</filename>, 
@@ -165,20 +166,20 @@
 
             <para>
                 After you have configured the <filename>adt_installer.conf</filename> file, 
-                run the installer for this example using the following commands:
+                run the installer using the following command.
+                Be sure that you are not trying to use cross-compilation tools. 
+                When you run the installer, the environment must use a 
+                host <filename>gcc</filename>:
                 <literallayout class='monospaced'>
-     $ cd ~/adt-installer
      $ ./adt_installer
                 </literallayout>
             </para>
 
             <note>
                 The ADT Installer requires the <filename>libtool</filename> package to complete.  
-                If you install the recommended packages as described in the 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>Packages</ulink>"
-                section of 
-                <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
-                The Yocto Project Quick Start</ulink>, then you will have libtool installed.
+                If you install the recommended packages as described in  
+                "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>"
+                section of The Yocto Project Quick Start, then you will have libtool installed.
             </note>
 
             <para>
@@ -192,7 +193,7 @@
             <para>
                 Once the installation completes, the ADT, which includes the cross-toolchain, is installed.
                 You will notice environment setup files for the cross-toolchain in 
-                <filename>/opt/poky/1.1.1</filename>,
+                <filename>&YOCTO_ADTPATH_DIR;</filename>,
                 and image tarballs in the <filename>adt-installer</filename>
                 directory according to your installer configurations, and the target sysroot located
                 according to the <filename>YOCTOADT_TARGET_SYSROOT_LOC_&lt;arch&gt;</filename> variable
@@ -215,17 +216,17 @@
             Follow these steps:
             <orderedlist>
                 <listitem><para>Go to  
-                    <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain'></ulink> 
+                    <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink> 
                     and find the folder that matches your host development system 
                     (i.e. <filename>i686</filename> for 32-bit machines or 
-                    <filename>x86_64</filename> for 64-bit machines).</para></listitem>
+                    <filename>x86-64</filename> for 64-bit machines).</para></listitem>
                 <listitem><para>Go into that folder and download the toolchain tarball whose name 
                     includes the appropriate target architecture.
                     For example, if your host development system is an Intel-based 64-bit system and 
                     you are going to use your cross-toolchain for an Intel-based 32-bit target, go into the 
                     <filename>x86_64</filename> folder and download the following tarball:
                     <literallayout class='monospaced'>
-     poky-eglibc-x86_64-i586-toolchain-1.1.1.tar.bz2
+     poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2
                     </literallayout>
                     <note><para>As an alternative to steps one and two, you can build the toolchain tarball 
                         if you have a Yocto Project build tree.
@@ -242,15 +243,9 @@
                         </para></note></para></listitem>
                 <listitem><para>Make sure you are in the root directory with root privileges and then expand 
                     the tarball.  
-                    The tarball expands into <filename>/opt/poky/1.1.1</filename>.
+                    The tarball expands into <filename>&YOCTO_ADTPATH_DIR;</filename>.
                     Once the tarball is expanded, the cross-toolchain is installed.
                     You will notice environment setup files for the cross-toolchain in the directory.
-                    Here is an example where the tarball exists in the user's <filename>Downloads</filename>
-                    directory:
-                    <literallayout class='monospaced'>
-     # cd /
-     # tar -xjf /home/scottrif/Downloads/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
-                    </literallayout>     
                     </para></listitem>
             </orderedlist>
         </para>
@@ -287,7 +282,7 @@
                         command.</note></para></listitem>
                 <listitem><para>Run <filename>bitbake meta-ide-support</filename> to complete the 
                     cross-toolchain installation.
-                    <note>If you change out of your working directory after you 
+                    <note>If change out of your working directory after you 
                         <filename>source</filename> the environment setup script and before you run
                         the <filename>bitbake</filename> command, the command might not work. 
                         Be sure to run the <filename>bitbake</filename> command immediately 
@@ -311,21 +306,21 @@
         Before you can develop using the cross-toolchain, you need to set up the 
         cross-development environment by sourcing the toolchain's environment setup script.  
         If you used the ADT Installer or used an existing ADT tarball to install the ADT,
-        then you can find this script in the <filename>/opt/poky/1.1.1</filename>
+        then you can find this script in the <filename>&YOCTO_ADTPATH_DIR;</filename>
         directory.  
         If you installed the toolchain in the build tree, you can find the environment setup 
         script for the toolchain in the Yocto Project build tree's <filename>tmp</filename> directory.
     </para>
 
     <para> 
-        Be sure to source the environment setup script that matches the architecture for 
+        Be sure to run the environment setup script that matches the architecture for 
         which you are developing.  
         Environment setup scripts begin with the string “<filename>environment-setup</filename>”
         and include as part of their name the architecture.  
-        For example, the command to source the toolchain environment setup script 
-        for a 64-bit IA-based machine would be the following: 
+        For example, the toolchain environment setup script for a 64-bit IA-based architecture would 
+        be the following: 
         <literallayout class='monospaced'>
-     $ source /opt/poky/1.1.1/environment-setup-x86_64-poky-linux
+     &YOCTO_ADTPATH_DIR;/environment-setup-x86_64-poky-linux
         </literallayout>
     </para>
 </section>
@@ -347,8 +342,8 @@
             To get the kernel and filesystem images, you either have to build them or download
             pre-built versions.
             You can find examples for both these situations in the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#test-run'>A
-            Quick Test Run</ulink>" section of The Yocto Project Quick Start.
+            "<ulink url='&YOCTO_DOCS_QS_URL;#test-run'>A Quick Test Run</ulink>" section of   
+            The Yocto Project Quick Start.
         </para>
 
         <para> 
@@ -357,10 +352,11 @@
             <filename>mips</filename>, <filename>powerpc</filename>, and <filename>arm</filename>) 
             that you can use unaltered in the QEMU emulator.  
             These kernel images reside in the Yocto Project release 
-            area - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'></ulink>
+            area - <ulink url='&YOCTO_MACHINES_DL_URL;'></ulink>
             and are ideal for experimentation within Yocto Project.
             For information on the image types you can build using the Yocto Project, see the
-            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" appendix in The Yocto Project Reference Manual.
+            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" appendix in  
+            The Yocto Project Reference Manual.
         </para>
 
         <para>
@@ -391,11 +387,11 @@
                         <listitem><para>Set up the cross-development environment as described in the 
                             "<link linkend='setting-up-the-cross-development-environment'>Setting 
                             Up the Cross-Development Environment</link>" section.</para></listitem>
-                        <listitem><para>Get the <filename>tcf-agent</filename> source code, which is 
-                            stored using the Subversion SCM, using the following command:
+                        <listitem><para>Get the <filename>tcf-agent</filename> source code using
+                            the following commands:
                             <literallayout class='monospaced'>
-     $ svn checkout svn://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent \
-        &lt;-r #rev_number&gt;
+     $ git clone http://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git
+     $ cd agent
                             </literallayout></para></listitem>
                         <listitem><para>Modify the <filename>Makefile.inc</filename> file
                             for the cross-compilation environment by setting the 
@@ -432,9 +428,8 @@
             To extract the root filesystem, first <filename>source</filename>
             the cross-development environment setup script and then 
             use the <filename>runqemu-extract-sdk</filename> command on the 
-            filesystem image tarball. 
-            For example, the following commands set up the environment by sourcing 
-            the setup script from within the build directory and then extracting
+            filesystem image. 
+            For example, the following commands set up the environment and then extract
             the root filesystem from a previously built filesystem image tarball named  
             <filename>core-image-sato-sdk-qemux86.tar.bz2</filename>.
             The example extracts the root filesystem into the <filename>$HOME/qemux86-sato</filename>

documentation/adt-manual/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -946,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -958,11 +958,26 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

documentation/bsp-guide/bsp-guide.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='bsp-guide' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -60,10 +61,15 @@
                 <date>15 March 2012</date>
                 <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2010-2012</year>
+      <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -75,9 +81,9 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and the 
-          <ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
+          <ulink url='&YOCTO_DOCS_BSP_URL;'>
           Board Support Package (BSP) Developer's Guide</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>

documentation/bsp-guide/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -771,6 +771,17 @@ h6,
 h7{
 }
 
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
 div.preface .titlepage .title, 
 div.colophon .title, 
 div.chapter .titlepage .title {
@@ -936,8 +947,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -948,11 +959,26 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

documentation/dev-manual/dev-manual-bsp-appendix.xml

@@ -1,12 +1,13 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='dev-manual-bsp-appendix'>
 
 <title>BSP Development Example</title>
 
 <para>
-    This appendix provides a complete BSP example.
+    This appendix provides a complete BSP development example.
     The example assumes the following:
     <itemizedlist>
         <listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
@@ -31,47 +32,77 @@
         The following paragraphs describe both methods.
         For additional information, see the bulleted item
         "<link linkend='local-yp-release'>Yocto Project Release</link>".
-    </para>
+    </para> 
 
     <para>
         As mentioned, one way to get the Yocto Project files is to use Git to clone the 
-        <filename>poky</filename> repository:
+        <filename>poky</filename> repository. 
+        These commands create a local copy of the Git repository.
+        By default, the top-level directory of the repository is named <filename>poky</filename>:
         <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
         </literallayout> 
-        Alternatively, you can start with the downloaded Poky "edison" tarball:
+        Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball.
+        These commands unpack the tarball into a Yocto Project File directory structure.
+        By default, the top-level directory of the file structure is named
+        <filename>&YOCTO_POKY;</filename>:
         <literallayout class='monospaced'>
-     $ tar xfj poky-edison-6.0.1.tar.bz2
-     $ cd poky
+     $ tar xfj &YOCTO_POKY_TARBALL;
+     $ cd &YOCTO_POKY;
         </literallayout> 
-        <note>If you're using the tarball method, you can ignore all the following steps that
+        <note><para>If you're using the tarball method, you can ignore all the following steps that
         ask you to carry out Git operations.  
         You already have the results of those operations
-        in the form of the edison release tarballs.
+        in the form of the &DISTRO_NAME; release tarballs.
         Consequently, there is nothing left to do other than extract those tarballs into the 
-        proper locations.</note>
+        proper locations.</para>
+
+        <para>Once you expand the released tarball, you have a snapshot of the Git repository
+        that represents a specific release.
+        Fundamentally, this is different than having a local copy of the Yocto Project 
+        Git repository.  
+        Given the tarball method, changes you make are building on top of a release.
+        With the Git repository method you have the ability to track development
+        and keep changes in revision control.</para></note>
     </para>
 
     <para>
-        Once you have the local <filename>poky</filename> Git repository set up, 
-        you have many development branches from which you can work. 
-        From inside the repository you can see the branch names and the tag names used 
-        in the Git repository using either of the following two commands:
+        With the local <filename>poky</filename> Git repository set up, 
+        you have all the development branches available to you from which you can work. 
+        Next, you need to be sure that your local repository reflects the exact
+        release in which you are interested.
+        From inside the repository you can see the development branches that represent
+        areas of development that have diverged from the main (master) branch
+        at some point, such as a branch to track a maintenance release's development.  
+        You can also see the tag names used to mark snapshots of stable releases or 
+        points in the repository.
+        Use the following commands to list out the branches and the tags in the repository, 
+        respectively.
         <literallayout class='monospaced'>
      $ git branch -a
      $ git tag -l
         </literallayout> 
-        For this example we are going to use the Yocto Project 1.1.1 Release, which is code
-        named "edison". 
-        These commands create a local branch named <filename>edison</filename>
-        that tracks the remote branch of the same name.
+        For this example, we are going to use the Yocto Project &DISTRO; Release, which is code
+        named "&DISTRO_NAME;". 
+        To make sure we have a local area (branch in Git terms) on our machine that 
+        reflects the &DISTRO; release, we can use the following commands:
         <literallayout class='monospaced'>
-     $ git checkout -b edison origin/edison
-     Switched to a new branch 'edison'
+     $ cd ~/poky
+     $ git fetch --tags
+     $ git checkout &DISTRO_NAME;-&POKYVERSION; -b &DISTRO_NAME;
+     Switched to a new branch '&DISTRO_NAME;'
         </literallayout>
+        The <filename>git fetch --tags</filename> is somewhat redundant since you just set 
+        up the repository and should have all the tags.
+        The <filename>fetch</filename> command makes sure all the tags are available in your
+        local repository.
+        The Git <filename>checkout</filename> command with the <filename>-b</filename> option
+        creates a local branch for you named <filename>&DISTRO_NAME;</filename>.
+        Your local branch begins in the same state as the Yocto Project &DISTRO; released tarball 
+        marked with the <filename>&DISTRO_NAME;-&POKYVERSION;</filename> tag in the source repositories.
     </para>
-</section>
+</section> 
 
 <section id='choosing-a-base-bsp-app'>
     <title>Choosing a Base BSP</title>
@@ -100,7 +131,7 @@
     <para>
         You need to have the base BSP layer on your development system.  
         Similar to the local Yocto Project files, you can get the BSP 
-        layer a couple of different ways:  
+        layer in couple of different ways:  
         download the BSP tarball and extract it, or set up a local Git repository that 
         has the Yocto Project BSP layers.  
         You should use the same method that you used to get the local Yocto Project files earlier.
@@ -113,8 +144,8 @@
         <filename>meta-intel</filename> contained within the <filename>poky</filename>
         parent directory.  
         The following steps will automatically create the
-        <filename>meta-intel</filename> directory and the contained meta-crownbay
-        starting point in both the Git and the tarball cases.
+        <filename>meta-intel</filename> directory and the contained 
+        <filename>meta-crownbay</filename> starting point in both the Git and the tarball cases.
     </para>
 
     <para>
@@ -125,12 +156,16 @@
      $ git clone git://git.yoctoproject.org/meta-intel.git
      $ cd meta-intel
         </literallayout> 
-        Alternatively, you can start with the downloaded <filename>meta-intel</filename>
-        edison tarball.
+        Alternatively, you can start with the downloaded Crown Bay tarball.
+        You can download the &DISTRO_NAME; version of the BSP tarball from the
+        <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page of the 
+        Yocto Project website. 
+        Here is the specific link for the tarball needed for this example:
+        <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-1.1/machines/crownbay-noemgd/crownbay-noemgd-edison-6.0.0.tar.bz2'></ulink>.
         Again, be sure that you are already in the <filename>poky</filename> directory
-        as described previously:
+        as described previously before installing the tarball:
         <literallayout class='monospaced'>
-     $ tar xfj crownbay-noemgd-edison-6.0.1.tar.bz2
+     $ tar xfj crownbay-noemgd-&DISTRO_NAME;-6.0.0.tar.bz2
      $ cd meta-intel
         </literallayout> 
     </para>
@@ -139,15 +174,16 @@
         The <filename>meta-intel</filename> directory contains all the metadata 
         that supports BSP creation.  
         If you're using the Git method, the following
-        step will switch to the edison metadata.
+        step will switch to the &DISTRO_NAME; metadata.
         If you're using the tarball method, you already have the correct metadata and can 
         skip to the next step.
         Because <filename>meta-intel</filename> is its own Git repository, you will want
         to be sure you are in the appropriate branch for your work.
-        For this example we are going to use the <filename>edison</filename> branch. 
+        For this example we are going to use the <filename>&DISTRO_NAME;</filename> branch. 
         <literallayout class='monospaced'>
-     $ git checkout -b edison origin/edison
-     Switched to a new branch 'edison'
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
         </literallayout>
     </para>
 </section>
@@ -234,10 +270,8 @@
             <filename>meta-mymachine/conf/layer.conf</filename>.
             This file identifies build information needed for the new layer.  
             You can see the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>The Board 
-            Support Packages (BSP) Development Guide</ulink>
-            for more information on this configuration file.  
+            "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-layer'>Layer Configuration File</ulink>" section
+            in The Board Support Packages (BSP) Development Guide for more information on this configuration file.  
             Basically, we are changing the existing statements to work with our BSP. 
         </para>
 
@@ -268,7 +302,8 @@
             Now we will take a look at the recipes in your new layer.  
             The standard BSP structure has areas for BSP, graphics, core, and kernel recipes.  
             When you create a BSP, you use these areas for appropriate recipes and append files.  
-            Recipes take the form of <filename>.bb</filename> files.  
+            Recipes take the form of <filename>.bb</filename> files, while append files take
+            the form of <filename>.bbappend</filename> files.  
             If you want to leverage the existing recipes the Yocto Project build system uses
             but change those recipes, you can use <filename>.bbappend</filename> files.  
             All new recipes and append files for your layer must go in the layer’s 
@@ -278,7 +313,7 @@
         </para>
 
         <section id='changing-recipes-bsp'>
-            <title>Changing <filename>recipes-bsp</filename></title>
+            <title>Changing&nbsp;&nbsp;<filename>recipes-bsp</filename></title>
 
             <para>
                 First, let's look at <filename>recipes-bsp</filename>.
@@ -295,7 +330,7 @@
         </section>
 
         <section id='changing-recipes-graphics'>
-            <title>Changing <filename>recipes-graphics</filename></title>
+            <title>Changing&nbsp;&nbsp;<filename>recipes-graphics</filename></title>
 
             <para>
                 Now let's look at <filename>recipes-graphics</filename>.
@@ -316,7 +351,7 @@
         </section>
 
         <section id='changing-recipes-core'>
-            <title>Changing <filename>recipes-core</filename></title>
+            <title>Changing&nbsp;&nbsp;<filename>recipes-core</filename></title>
 
             <para>
                 Now let's look at changes in <filename>recipes-core</filename>.
@@ -324,7 +359,7 @@
                 <filename>recipes-core/tasks</filename> appends the similarly named recipe
                 located in the local Yocto Project files at 
                 <filename>meta/recipes-core/tasks</filename>.
-                The "append" file in our layer right now is Crown Bay-specific and supports 
+                The append file in our layer right now is Crown Bay-specific and supports 
                 EMGD and non-EMGD.
                 Here are the contents of the file:
                 <literallayout class='monospaced'>
@@ -345,7 +380,7 @@
         </section>
 
         <section id='changing-recipes-kernel'>
-            <title>Changing <filename>recipes-kernel</filename></title>
+            <title>Changing&nbsp;&nbsp;<filename>recipes-kernel</filename></title>
 
             <para>
                 Finally, let's look at <filename>recipes-kernel</filename> changes.
@@ -368,15 +403,18 @@
                 However, in the <filename>meta-mymachine</filename> layer in 
                 <filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename>
                 file named <filename>linux-yocto_3.0.bbappend</filename> that 
-                is appended to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
-                Thus, the <filename>SRCREV</filename> statements in the "append" file override
+                appends information to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
+                Thus, the <filename>SRCREV</filename> statements in the append file override
                 the more general statements found in <filename>meta</filename>.
             </para>
 
             <para>
-                The <filename>SRCREV</filename> statements in the "append" file currently identify
+                The <filename>SRCREV</filename> statements in the append file currently identify
                 the kernel that supports the Crown Bay BSP with and without EMGD support.
-                Here are the statements: 
+                Here are the statements:
+                <note>The commit ID strings used in this manual might not match the actual commit
+                    ID strings found in the <filename>linux-yocto_3.0.bbappend</filename> file.
+                    For the example, this difference does not matter.</note> 
                 <literallayout class='monospaced'>
      SRCREV_machine_pn-linux-yocto_crownbay ?= \
         "2247da9131ea7e46ed4766a69bb1353dba22f873"
@@ -408,11 +446,11 @@
                 and insert the commit identifiers to identify the kernel in which we 
                 are interested, which will be based on the <filename>atom-pc-standard</filename>
                 kernel.
-                In this case, because we're working with the edison branch of everything, we
+                In this case, because we're working with the &DISTRO_NAME; branch of everything, we
                 need to use the <filename>SRCREV</filename> values for the atom-pc branch
-                that are associated with the edison release.  
+                that are associated with the &DISTRO_NAME; release.  
                 To find those values, we need to find the <filename>SRCREV</filename>
-                values that edison uses for the atom-pc branch, which we find in the
+                values that &DISTRO_NAME; uses for the atom-pc branch, which we find in the
                 <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
                 file.
             </para>
@@ -423,9 +461,7 @@
                 The meta <filename>SRCREV</filename> isn't specified in this file, so it must be 
                 specified in the base kernel recipe in the
                 <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb</filename>
-                file, in the <filename>SRCREV_meta variable</filename> found there.  
-                It happens to be the same as the value we already inherited from the 
-                <filename>meta-crownbay</filename> BSP.
+                file, in the <filename>SRCREV_meta</filename>  variable found there.  
                 Here are the final <filename>SRCREV</filename> statements:
                 <literallayout class='monospaced'>
      SRCREV_machine_pn-linux-yocto_mymachine ?= \ 
@@ -437,8 +473,8 @@
 
             <para>
                 In this example, we're using the <filename>SRCREV</filename> values we 
-                found already captured in the edison release because we're creating a BSP based on 
-                edison.  
+                found already captured in the &DISTRO_NAME; release because we're creating a BSP based on 
+                &DISTRO_NAME;.  
                 If, instead, we had based our BSP on the master branches, we would want to use 
                 the most recent <filename>SRCREV</filename> values taken directly from the kernel repo.
                 We will not be doing that for this example.
@@ -447,8 +483,8 @@
                 exact commit strings in the Yocto Project source repositories you need to change 
                 the <filename>SRCREV</filename> statements.  
                 You can find all the <filename>machine</filename> and <filename>meta</filename> 
-                branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at
-                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0'></ulink>.  
+                branch points (commits) for the <filename>linux-yocto-3.0-1.1.x</filename> kernel at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.0-1.1.x/'></ulink>.  
             </para>
 
             <para>
@@ -477,12 +513,12 @@
                 Because we are not interested in supporting EMGD those three can be deleted.
                 The remaining three must be changed so that <filename>mymachine</filename> replaces
                 <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
-                Because we are using the atom-pc branch for this new BSP, we can also find
-                the exact branch we need for the KMACHINE variable in our new BSP from the value
+                Because we are using the <filename>atom-pc</filename> branch for this new BSP, we can also find
+                the exact branch we need for the <filename>KMACHINE</filename> variable in our new BSP from the value
                 we find in the
                 <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
                 file we looked at in a previous step.  
-                In this case, the value we want is in the KMACHINE_atom-pc variable in that file.
+                In this case, the value we want is in the <filename>KMACHINE_atom-pc</filename> variable in that file.
                 Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all 
                 the edits:
                 <literallayout class='monospaced'>
@@ -509,7 +545,7 @@
             statements that do not support your targeted hardware in addition to the inclusion 
             of any new recipes you might need.  
             In this example, it was simply a matter of ridding the new layer 
-            <filename>meta-machine</filename> of any code that supported the EMGD features
+            <filename>meta-mymachine</filename> of any code that supported the EMGD features
             and making sure we were identifying the kernel that supports our example, which
             is the <filename>atom-pc-standard</filename> kernel.  
             We did not introduce any new recipes to the layer. 
@@ -544,7 +580,7 @@
                 Thus, entering the previous command created the <filename>yocto-build</filename> directory.  
                 If you do not provide a name for the build directory it defaults to 
                 <filename>build</filename>.  
-                The <filename>yocot-build</filename> directory contains a 
+                The <filename>yocto-build</filename> directory contains a
                 <filename>conf</filename> directory that has 
                 two configuration files you will need to check:  <filename>bblayers.conf</filename>
                 and <filename>local.conf</filename>.</para></listitem>
@@ -558,14 +594,14 @@
                 You should also be sure any other variables in which you are interested are set.  
                 Some variables to consider are <filename>BB_NUMBER_THREADS</filename>
                 and <filename>PARALLEL_MAKE</filename>, both of which can greatly reduce your build time 
-                if you are using a multi-threaded development system (e.g. values of 
-                <filename>8</filename> and <filename>j 6</filename>, respectively are optimal 
-                for a development machine that has four available cores).</para></listitem>
+                if your development system supports multiple cores.
+                For development systems that support multiple cores, a good rule of thumb is to set 
+                both the <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename> 
+                variables to twice the number of cores your system supports.</para></listitem>
             <listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes 
                 the path to your new BSP layer.  
-                In this example you need to include the pathname to <filename>meta-mymachine</filename>.
-                For this example the 
-                <filename>BBLAYERS</filename> variable in the file would need to include the following path:
+                In this example, you need to include this path as part of the 
+                <filename>BBLAYERS</filename> variable:
                 <literallayout class='monospaced'>
      $HOME/poky/meta-intel/meta-mymachine
                 </literallayout></para></listitem>
@@ -574,7 +610,7 @@
 
     <para>
         The appendix 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
+        <ulink url='&YOCTO_DOCS_REF_URL;#ref-variables-glos'>
         Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information 
          on configuration variables.
     </para>
@@ -607,7 +643,7 @@
         Finally, once you have an image, you can try booting it from a device
         (e.g. a USB device).
         To prepare a bootable USB device, insert a USB flash drive into your build system and
-        copy the <filename>.hddimage</filename>, located in the 
+        copy the <filename>.hddimg</filename> file, located in the 
         <filename>poky/build/tmp/deploy/images</filename>
         directory after a successful build to the flash drive.  
         Assuming the USB flash drive takes device <filename>/dev/sdc</filename>, 
@@ -625,10 +661,26 @@
         Insert the device
         into a bootable USB socket on the target, and power it on.  
         The system should boot to the Sato graphical desktop.
+        <footnote><para>Because 
+            this new image is not in any way tailored to the system you're
+            booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
+            example, it might not be completely functional though it should at least boot to a text
+            prompt.  
+            Specifically, it might fail to boot into graphics without some tweaking.  
+            If this ends up being the case, a possible next step would be to replace the 
+            <filename>mymachine.conf</filename>
+            contents with the contents of <filename>atom-pc.conf</filename> and replace 
+            <filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
+            in <filename>meta-yocto</filename> and see if it fares any better.  
+            In any case, following the previous steps will give you a buildable image that 
+            will probably boot on most systems.
+            Getting things working like you want
+            them to for your hardware will normally require some amount of experimentation with
+            configuration settings.</para></footnote> 
     </para>
 
     <para>
-        For reference, the sato image produced by the previous steps for edison 
+        For reference, the sato image produced by the previous steps for &DISTRO_NAME; 
         should look like the following in terms of size.
         If your sato image is much different from this,
         you probably made a mistake in one of the above steps:
@@ -643,24 +695,6 @@
         also provides some suggestions for things to try if booting fails and produces
         strange error messages.</note>
     </para>
-
-    <para>
-        Because this new image is not in any way tailored to the system you're
-        booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
-        example, it might not be completely functional though it should at least boot to a text
-        prompt.  
-        Specifically, it might fail to boot into graphics without some tweaking.  
-        If this ends up being the case, a possible next step would be to replace the 
-        <filename>mymachine.conf</filename>
-        contents with the contents of <filename>atom-pc.conf</filename> and replace 
-        <filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
-        in <filename>meta-yocto</filename> and see if it fares any better.  
-        In any case, following the previous steps should
-        probably give you a buildable and bootable image.  
-        Getting things working like you want
-        them to for your hardware will normally require some amount of experimentation with
-        configuration settings.
-    </para>
 </section>
 </appendix>
 

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='dev-manual-intro'>
 
@@ -15,9 +16,10 @@
             using the Yocto Project. 
             Because much of the information in this manual is general, it contains many references to other
             sources where you can find more detail.
-            For example, detailed information on Git, repositories and open-source in general 
+            For example, detailed information on Git, repositories and open source in general
             can be found in many places.  
-            Another example is how to get set up to use the Yocto Project, which our Yocto Project Quick Start covers.
+            Another example is how to get set up to use the Yocto Project, which our 
+            <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink> covers.
         </para>
 
         <para>  
@@ -35,10 +37,10 @@
             <itemizedlist>
                 <listitem><para>Information that lets you get set 
                     up to develop using the Yocto Project.</para></listitem>
-                <listitem><para>Information to help developers that are new to the open source environment 
+                <listitem><para>Information to help developers who are new to the open source environment 
                     and to the distributed revision control system Git, which the Yocto Project 
                     uses.</para></listitem>
-                <listitem><para>An understanding of common end-to-end development models.</para></listitem>
+                <listitem><para>An understanding of common end-to-end development models and tasks.</para></listitem>
                 <listitem><para>Development case overviews for both system development and user-space 
                     applications.</para></listitem>
                 <listitem><para>An overview and understanding of the emulation environment used with 
@@ -63,13 +65,15 @@
             <itemizedlist>
                 <listitem><para>Step-by-step instructions if those instructions exist in other Yocto 
                     Project documentation.  
-                    For example, The Application Development Toolkit (ADT) User’s Guide contains detailed 
+                    For example, the 
+                    <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Development Toolkit (ADT)
+                    User's Guide</ulink> contains detailed 
                     instruction on how to obtain and configure the 
                     <trademark class='trade'>Eclipse</trademark> Yocto Plug-in.</para></listitem>
                 <listitem><para>Reference material.  
                     This type of material resides in an appropriate reference manual.  
                     For example, system variables are documented in the 
-                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
+                    <ulink url='&YOCTO_DOCS_REF_URL;'>
                     Yocto Project Reference Manual</ulink>.</para></listitem>
                 <listitem><para>Detailed public information that is not specific to the Yocto Project.  
                     For example, exhaustive information on how to use Git is covered better through the 
@@ -86,31 +90,31 @@
             need to supplement it with other information.
             The following list presents other sources of information you might find helpful:
             <itemizedlist>
-                <listitem><para><emphasis>The <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>:
+                <listitem><para><emphasis>The <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:
                     </emphasis> The home page for the Yocto Project provides lots of information on the project 
                     as well as links to software and documentation.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
+                    <ulink url='&YOCTO_DOCS_QS_URL;'>
                     The Yocto Project Quick Start</ulink>:</emphasis> This short document lets you get started 
                     with the Yocto Project quickly and start building an image.</para></listitem>
                 <listitem><para><emphasis> 
-                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
+                    <ulink url='&YOCTO_DOCS_REF_URL;'>
                     The Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference 
                     guide to the Yocto Project build component known as "Poky."  
                     The manual also contains a reference chapter on Board Support Package (BSP) 
                     layout.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
+                    <ulink url='&YOCTO_DOCS_ADT_URL;'>
                     The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>:</emphasis>
                     This guide provides information that lets you get going with the ADT to 
                     develop projects using the Yocto Project.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
+                    <ulink url='&YOCTO_DOCS_BSP_URL;'>
                     The Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
                     This guide defines the structure for BSP components.  
                     Having a commonly understood structure encourages standardization.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
+                    <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
                     The Yocto Project Kernel Architecture and Use Manual</ulink>:</emphasis>
                     This manual describes the architecture of the Yocto Project kernel and provides 
                     some work flow examples.</para></listitem>
@@ -120,14 +124,14 @@
                     demonstrates how an application developer uses Yocto Plug-in features within 
                     the Eclipse IDE.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://wiki.yoctoproject.org/wiki/FAQ'>FAQ</ulink>:</emphasis>
+                    <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:</emphasis>
                     A list of commonly asked questions and their answers.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/download/yocto/yocto-project-1.0-release-notes-poky-5.0'>
+                    <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-1.1.2-release-notes-poky-&POKYVERSION;'>
                     Release Notes</ulink>:</emphasis> Features, updates and known issues for the current 
                     release of the Yocto Project.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://bugzilla.yoctoproject.org/'>Bugzilla</ulink>:</emphasis>
+                    <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>:</emphasis>
                     The bug tracking application the Yocto Project uses.
                     If you find problems with the Yocto Project, you should report them using this
                     application.</para></listitem>
@@ -135,11 +139,11 @@
                     Yocto Project Mailing Lists:</emphasis> To subscribe to the Yocto Project mailing 
                     lists, click on the following URLs and follow the instructions:
                     <itemizedlist>
-                        <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a 
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> for a 
                             Yocto Project Discussions mailing list.</para></listitem>
-                        <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a 
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> for a 
                             Yocto Project Discussions mailing list about the Poky build system.</para></listitem>
-                        <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink>
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink>
                             for a mailing list to receive offical Yocto Project announcements for developments and 
                             as well as Yocto Project milestones.</para></listitem>
                     </itemizedlist></para></listitem>
@@ -148,20 +152,20 @@
                     for Yocto Project and Poky discussions: <filename>#yocto</filename> and 
                     <filename>#poky</filename>.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.openedhand.com/'>OpenedHand</ulink>:</emphasis>
+                    <ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
                     The company where the Yocto Project build system Poky was first developed.
                     OpenedHand has since been acquired by Intel Corporation.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
-                    The company who acquired OpenedHand in 2008 and continues development on the 
+                    The company that acquired OpenedHand in 2008 and continues development on the 
                     Yocto Project.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>:</emphasis>
+                    <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
                     The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
                     from and to which it contributes.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://developer.berlios.de/projects/bitbake/'>
-                    Bitbake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
+                    BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://bitbake.berlios.de/manual/'>
                     BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.

documentation/dev-manual/dev-manual-kernel-appendix.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='dev-manual-kernel-appendix'>
 
@@ -149,14 +150,14 @@
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1.1 Release code named "edison", 
-                which maps to the <filename>edison</filename> branch in the repository. 
-                The following commands create and checkout the local <filename>edison</filename>
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
+                which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
-     $ git checkout -b edison origin/edison
-     Branch edison set up to track remote branch edison from origin.
-     Switched to a new branch 'edison'
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
                 </literallayout>
             </para>
         </section>
@@ -179,18 +180,18 @@
                 From inside the repository you can see the branch names and the tag names used 
                 in the Git repository using either of the following two commands:
                 <literallayout class='monospaced'>
-     $ cd poky
+     $ cd poky/poky-extras
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1.1 Release code named "edison", 
-                which maps to the <filename>edison</filename> branch in the repository. 
-                The following commands create and checkout the local <filename>edison</filename>
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
+                which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
-     $ git checkout -b edison origin/edison
-     Branch edison set up to track remote branch edison from origin.
-     Switched to a new branch 'edison'
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
                 </literallayout>
             </para>
         </section>
@@ -244,9 +245,9 @@
                     If your host development system supports multi-core and multi-thread capabilities,
                     you can uncomment these statements and set the variables to significantly shorten
                     the full build time.
-                    As a guideline, set <filename>BB_NUMBER_THREADS</filename> to twice the number 
-                    of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and 
-                    a half times the number of cores your machine supports.
+                    As a guideline, set both <filename>BB_NUMBER_THREADS</filename> and 
+                    <filename>PARALLEL_MAKE</filename> to twice the number 
+                    of cores your machine supports.
                 </note>
                 The following two commands <filename>source</filename> the build environment setup script
                 and build the default <filename>qemux86</filename> image.
@@ -411,9 +412,8 @@
                        build time if your host supports multi-core and multi-thread capabilities:
                        <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>.
                        If the host system has multiple cores then you can optimize build time 
-                       by setting <filename>BB_NUMBER_THREADS</filename> to twice the number of 
-                       cores and setting <filename>PARALLEL_MAKE</filename> to one and a half times the 
-                       number of cores.</para></listitem>
+                       by setting both these variables to twice the number of 
+                       cores.</para></listitem>
                    <listitem><para><emphasis>Identify Your <filename>meta-kernel-dev</filename>
                        Layer:</emphasis> The <filename>BBLAYERS</filename> variable in the 
                        <filename>bblayers.conf</filename> file found in the 
@@ -455,15 +455,19 @@
            </para>
 
            <note>
-               Before attempting to build the modified kernel, there is one more set of changes you 
+               <para>Before attempting to build the modified kernel, there is one more set of changes you 
                need to make in the <filename>meta-kernel-dev</filename> layer.
                Because all the kernel <filename>.bbappend</filename> files are parsed during the 
                build process regardless of whether you are using them or not, you should either 
                comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all 
-               unused <filename>.bbappend</filename> files.
-               Alternatively, you can simply remove all the files 
+               unused <filename>.bbappend</filename> files, or simply remove (or rename) all the files 
                except the one your are using for the build 
-               (i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).
+               (i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).</para>
+               <para>If you do not make one of these two adjustments, your machine will be compatible
+               with all the kernel recipes in the <filename>meta-kernel-dev</filename> layer. 
+               When your machine is comapatible with all the kernel recipes, the build attempts
+               to build all kernels in the layer.
+               You could end up with build errors blocking your work.</para>
            </note>            
        </section>
 
@@ -477,18 +481,21 @@
                     <listitem><para>Your environment should be set up since you previously sourced
                         the <filename>oe-init-build-env</filename> script.
                         If it isn't, source the script again from <filename>poky</filename>.
-                        </para></listitem>
-                    <listitem><para>Be sure old images are cleaned out by running the 
-                        <filename>cleanall</filename> BitBake task as follows:
                         <literallayout class='monospaced'>
      $ cd ~/poky
+     $ source oe-init-build-env
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>Be sure old images are cleaned out by running the 
+                        <filename>cleanall</filename> BitBake task as follows from your build directory:
+                        <literallayout class='monospaced'>
      $ bitbake -c cleanall linux-yocto
                         </literallayout></para>
                         <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
                         directory insided the local Yocto Project files build directory.
                         Always use the BitBake <filename>cleanall</filename> task to clear
                         out previous builds.</note></para></listitem>
-                    <listitem><para>Build the kernel image using this command:
+                    <listitem><para>Next, build the kernel image using this command:
                         <literallayout class='monospaced'>
      $ bitbake -k core-image-minimal
                         </literallayout></para></listitem>
@@ -532,9 +539,9 @@
                 in "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
                 Code</link>" you should already have the Yocto Project files set up on your 
                 host machine.
-                If this is the case, go to then next section titled
+                If this is the case, go to the next section, which is titled
                 "<link linkend='examining-the-default-config-smp-behavior'>Examining the Default
-                <filename>CONFIG_SMP</filename> Behavior</link>" and continue with the 
+                <filename>CONFIG_SMP</filename> Behavior</link>", and continue with the 
                 example.
             </para>
 
@@ -559,14 +566,14 @@
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1.1 Release code named "edison", 
-                which maps to the <filename>edison</filename> branch in the repository. 
-                The following commands create and checkout the local <filename>edison</filename>
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
+                which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
-     $ git checkout -b edison origin/edison
-     Branch edison set up to track remote branch edison from origin.
-     Switched to a new branch 'edison'
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
                 </literallayout>
             </para>
 
@@ -623,7 +630,7 @@
         </section>
 
         <section id='examining-the-default-config-smp-behavior'>
-            <title>Examining the Default <filename>CONFIG_SMP</filename> Behavior</title>
+            <title>Examining the Default&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Behavior</title>
 
             <para>
                 By default, <filename>CONFIG_SMP</filename> supports single processor machines.
@@ -649,8 +656,10 @@
             </para>
         </section>
 
+
+
         <section id='changing-the-config-smp-configuration-using-menuconfig'>
-            <title>Changing the <filename>CONFIG_SMP</filename> Configuration Using <filename>menuconfig</filename></title>
+            <title>Changing the&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Configuration Using&nbsp;&nbsp;<filename>menuconfig</filename></title>
 
             <para>
                 The <filename>menuconfig</filename> tool provides an interactive method with which
@@ -672,11 +681,20 @@
                 kernel.
                 The Yocto Project build environment recognizes this kernel as 
                 <filename>linux-yocto</filename>.
-                Thus, the following command from the shell in which you previously sourced the 
-                environment initialization script launches <filename>menuconfig</filename>:
+                Thus, the following commands from the shell in which you previously sourced the 
+                environment initialization script cleans the shared state memory and 
+                the <filename>WORKDIR</filename> direcotry and then builds and 
+                launches <filename>menuconfig</filename>:
                 <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c cleansstate
      $ bitbake linux-yocto -c menuconfig
                 </literallayout>
+                <note>Due to a bug in the release, it is necessary to clean the shared state
+                    memory in order for configurations made using <filename>menuconfig</filename>
+                    to take effect.
+                    For information on the bug, see 
+                    <ulink url='&YOCTO_BUGZILLA_URL;/show_bug.cgi?id=2256'></ulink>.
+                </note>
             </para>
                   
             <para>
@@ -694,16 +712,19 @@
                 is updated. 
                 This is the file that the build system uses to configure the Linux Yocto kernel
                 when it is built. 
-                You can find and examine this file in the Yocto Project files Git repository in 
+                You can find and examine this file in the Yocto Project Files Git repository in 
                 the build directory. 
-                This example uses the following.
-                Note that this example directory is artificially split and many of the characters 
-                in the actually filename are omitted in order to make it more
-                readable:
+                This example uses the following:
                 <literallayout class='monospaced'>
      ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.10+git1+d38...
         ...3a9ac596f7a-r3/linux-qemux86-standard-build
                 </literallayout>
+                <note>
+                    The previous example directory is artificially split and many of the characters 
+                    in the actual filename are omitted in order to make it more readable.
+                    Also, depending on the kernel you are using, the exact pathname might differ 
+                    slightly.
+                </note>
             </para>
 
             <para>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='dev-manual-model'>
 
@@ -23,9 +24,8 @@
     "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>" appendix.
     For a user-space application development example that uses the 
     <trademark class='trade'>Eclipse</trademark> IDE,
-    see the 
-    <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
-    The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>.
+    see <ulink url='&YOCTO_DOCS_ADT_URL;'>The Yocto Project Application Development 
+    Toolkit (ADT) User's Guide</ulink>.
 </para>
 
 <section id='system-development-model'>
@@ -35,8 +35,8 @@
         System development involves modification or creation of an image that you want to run on 
         a specific hardware target.  
         Usually, when you want to create an image that runs on embedded hardware, the image does 
-        not require the same amount of features that a full-fledged Linux distribution provides.  
-        Thus, you can create a much smaller image that is designed to just use the hardware 
+        not require the same number of features that a full-fledged Linux distribution provides.
+        Thus, you can create a much smaller image that is designed to use only the hardware
         features for your particular hardware.
     </para>
 
@@ -50,8 +50,8 @@
         <title>Developing a Board Support Package (BSP)</title>
 
         <para>
-            A BSP is a package of recipes that, when applied, during a build results in 
-            an image you can run on a particular board.  
+            A BSP is a packageof recipes that, when applied, during a build results in 
+            an image that you can run on a particular board.  
             Thus, the package, when compiled into the new image, supports the operation of the board.  
         </para>
 
@@ -61,8 +61,8 @@
         </note>
 
         <para>
-            The remainder of this section presents the basic steps to create a BSP basing it on an 
-            existing BSP that ships with the Yocto Project.
+            The remainder of this section presents the basic steps used to create a BSP 
+            based on an existing BSP that ships with the Yocto Project.
             You can reference the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>"
             appendix for a detailed example that uses the Crown Bay BSP as a base BSP from which to start.
         </para>
@@ -79,18 +79,19 @@
             <orderedlist>
                 <listitem><para><emphasis>Set up your host development system to support 
                     development using the Yocto Project</emphasis>:  See the
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and the 
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" 
+                    and the 
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
                 <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
                     system</emphasis>:  You need to have the Yocto Project files available on your host system. 
                     Having the Yocto Project files on your system gives you access to the build
-                    process and tools you need.
+                    process and to the tools you need.
                     For information on how to get these files, see the
                     "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
                 <listitem><para><emphasis>Establish a local copy of the base BSP files</emphasis>:  Having    
                     the BSP files on your system gives you access to the build
-                    process and tools you need for creating a BSP.
+                    process and to the tools you need for creating a BSP.
                     For information on how to get these files, see the
                     "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>    
                 <listitem><para><emphasis>Choose a Yocto Project-supported BSP as your base BSP</emphasis>:  
@@ -111,13 +112,15 @@
                     Crown Bay that does not support the <trademark class='registered'>Intel</trademark> 
                     Embedded Media Graphics Driver (EMGD).  
                     The remainder of this example uses that base BSP.</para>
-                    <para>To see the supported BSPs, go to the Yocto Project
-                    <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click 
-                    on “BSP Downloads.”</para></listitem>
+                    <para>To see the supported BSPs, go to the 
+                    <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page on the Yocto Project
+                    website and click on “BSP Downloads.”</para></listitem>
                 <listitem><para><emphasis>Create your own BSP layer</emphasis>:  Layers are ideal for 
                     isolating and storing work for a given piece of hardware.  
-                    A layer is really just a location or area in which you place the recipes for your BSP.  
+                    A layer is really just a location or area in which you place the recipes for your BSP.
                     In fact, a BSP is, in itself, a special type of layer.   
+                    </para>
+                    <para>
                     Another example that illustrates a layer is an application.  
                     Suppose you are creating an application that has library or other dependencies in 
                     order for it to compile and run.  
@@ -137,16 +140,17 @@
                     N450, and Sugar Bay are isolated.</note>
                     <para>When you set up a layer for a new BSP, you should follow a standard layout.  
                     This layout is described in the section
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>Example Filesystem Layout</ulink>" section of the Board Support Package (BSP) Development Guide.  
+                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
+                    section of the Board Support Package (BSP) Development Guide.  
                     In the standard layout, you will notice a suggested structure for recipes and  
                     configuration information.  
                     You can see the standard layout for the Crown Bay BSP in this example by examining the 
                     directory structure of the <filename>meta-crownbay</filename> layer inside the 
                     local Yocto Project files.</para></listitem>
                 <listitem><para><emphasis>Make configuration changes to your new BSP 
-                    layer</emphasis>:  The standard BSP layer structure organizes the files you need to edit in 
-                    <filename>conf</filename> and several <filename>recipes-*</filename> directories within the 
-                    BSP layer.
+                    layer</emphasis>:  The standard BSP layer structure organizes the files you need 
+                    to edit in <filename>conf</filename> and several <filename>recipes-*</filename>
+                    directories within the BSP layer.
                     Configuration changes identify where your new layer is on the local system
                     and identify which kernel you are going to use.
                     </para></listitem>
@@ -160,7 +164,8 @@
                     You need to get the build environment ready by sourcing an environment setup script 
                     and you need to be sure two key configuration files are configured appropriately.</para>
                     <para>The entire process for building an image is overviewed in the section
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.    
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section 
+                    of the Yocto Project Quick Start.    
                     You might want to reference this information.</para></listitem>
                 <listitem><para><emphasis>Build the image</emphasis>:  The Yocto Project uses the BitBake 
                     tool to build images based on the type of image you want to create.  
@@ -168,8 +173,8 @@
                     <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
                     <para>The build process supports several types of images to satisfy different needs.  
                     See the 
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" 
-                    appendix in The Yocto Project Reference Manual for information on 
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" appendix 
+                    in The Yocto Project Reference Manual for information on 
                     supported images.</para></listitem>
             </orderedlist>
         </para>
@@ -178,10 +183,10 @@
             You can view a video presentation on "Building Custom Embedded Images with Yocto"
             at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>.  
             You can also find supplemental information in  
-            <ulink url='http://yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
+            <ulink url='&YOCTO_DOCS_BSP_URL;'>
             The Board Support Package (BSP) Development Guide</ulink>.
             Finally, there is wiki page write up of the example also located 
-            <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
+            <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
             here</ulink> that you might find helpful.
        </para>
     </section>
@@ -191,7 +196,7 @@
 
         <para>
             Kernel modification involves changing the Linux Yocto kernel, which could involve changing
-            configuration variables as well as adding new kernel recipes.  
+            configuration options as well as adding new kernel recipes.  
             Configuration changes can be added in the form of configuration fragments, while recipe
             modification comes through the kernel's <filename>recipes-kernel</filename> area
             in a kernel layer you create.
@@ -201,7 +206,7 @@
             The remainder of this section presents a high-level overview of the Linux Yocto 
             kernel architecture and the steps to modify the Linux Yocto kernel.
             For a complete discussion of the kernel, see  
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
+            <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
             The Yocto Project Kernel Architecture and Use Manual</ulink>.
             You can reference the appendix 
             "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>"
@@ -212,39 +217,41 @@
             <title>Kernel Overview</title>
 
             <para>
-                When one thinks of the source files for a kernel they usually think of a fixed structure 
-                of files that contain kernel patches.
-                The Yocto Project, however, employs mechanisims, that in a sense, result in a kernel source
+                Traditionally, when one thinks of a patched kernel, they think of a base kernel
+                source tree and a fixed structure that contains kernel patches.
+                The Yocto Project, however, employs mechanisms, that in a sense, result in a kernel source
                 generator.
                 By the end of this section, this analogy will become clearer.
             </para>
 
             <para>
                 You can find a web interface to the Linux Yocto kernel source repositories at
-                <ulink url='http://git.yoctoproject.org/'></ulink>.
+                <ulink url='&YOCTO_GIT_URL;'></ulink>.
                 If you look at the interface, you will see to the left a grouping of 
                 Git repositories titled "Yocto Linux Kernel."  
-                Within this group, you will find the four different kernels supported by 
+                Within this group, you will find several kernels supported by 
                 the Yocto Project:
                 <itemizedlist>
                     <listitem><para><emphasis><filename>linux-yocto-2.6.34</filename></emphasis> - The 
                     stable Linux Yocto kernel that is based on the Linux 2.6.34 release.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The
                     stable Linux Yocto kernel that is based on the Linux 2.6.37 release.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The 
-                    stable Linux Yocto kernel to use with the Yocto Project current (master) development.
-                    This kernel is based on the Linux 3.0 release.</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The stable
+                    Linux Yocto kernel that is based on the Linux 3.0 release.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The 
-                    stable Linux Yocto kernel to use with the Yocto Project Release 1.1.x.
-                    This kernel is based on the Linux 3.0 release.</para></listitem> 
+                    stable Linux Yocto kernel to use with the Yocto Project Release 1.1.x. This kernel 
+                    is based on the Linux 3.0 release</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.2</filename></emphasis> - The 
+                    stable Linux Yocto kernel to use with the Yocto Project Release 1.2. This kernel 
+                    is based on the Linux 3.2 release</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
                     kernel based on the latest upstream release candidate available.</para></listitem>
                 </itemizedlist>
             </para>
 
             <para>
-                The kernels are maintained using the Git application that, in a sense, structures
-                them in a "tree" complete with branches and leaves.
+                The kernels are maintained using the Git revision control system
+                that structures them using the familiar "tree", "branch", and "leaf" scheme.
                 Branches represent diversions from general code to more specific code, while leaves
                 represent the end-points for a complete and unique kernel whose source files 
                 when gathered from the root of the tree to the leaf accumulate to create the files
@@ -257,7 +264,7 @@
 
             <para>
                 Within the figure, the "Kernel.org Branch Point" represents the point in the tree
-                where a supported base kernel diverges from the Linux kernel.
+                where a supported base kernel is modified from the Linux kernel.
                 For example, this could be the branch point for the <filename>linux-yocto-3.0</filename>
                 kernel.
                 Thus, everything further to the right in the structure is based on the 
@@ -271,14 +278,14 @@
 
             <para>
                 The overall result is a Git-maintained repository from which all the supported
-                Yocto Project kernels can be derived for all the supported Yocto Project devices.
+                Yocto Project kernel types can be derived for all the supported Yocto Project devices.
                 A big advantage to this scheme is the sharing of common features by keeping them in 
                 "larger" branches within the tree.  
                 This practice eliminates redundant storage of similar features shared among kernels.
             </para>
 
             <note>
-                Keep in mind the figure does not take into account all four supported Linux Yocto
+                Keep in mind the figure does not take into account all the supported Linux Yocto
                 kernel types, but rather shows a single generic kernel just for conceptual purposes.
                 Also keep in mind that this structure represents the Yocto Project source repositories 
                 that are either pulled from during the build or established on the host development system
@@ -353,11 +360,11 @@
             <para>
                 Again, for a complete discussion of the Yocto Project kernel's architcture and its 
                 branching strategy,
-                see the <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
+                see <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
                 The Yocto Project Kernel Architecture and Use Manual</ulink>.
-                Also, you can reference 
-                <xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</xref>
-                for a detailed example that modifies the kernel.
+                You can also reference the
+                "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</link>"
+                section for a detailed example that modifies the kernel.
             </para>
         </section> 
 
@@ -377,8 +384,8 @@
                 <orderedlist>
                     <listitem><para><emphasis>Set up your host development system to support 
                         development using the Yocto Project</emphasis>:  See  
-                        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and  
-                        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and  
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                         in the Yocto Project Quick Start for requirements.</para></listitem>
                     <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
                         system</emphasis>:  Having the Yocto Project files on your system gives you access to 
@@ -394,7 +401,10 @@
                         Project files Git repository.
                         For information on how to get these files, see the bulleted item
                         "<link linkend='poky-extras-repo'>The <filename>poky-extras</filename> Git Repository</link>"
-                        earlier in this manual.</para></listitem>
+                        earlier in this manual.
+                        <note>While it is certainly possible to modify the kernel without involving
+                            a local Git repository, the suggested workflow for kernel modification
+                            using the Yocto Project does use a Git repository.</note></para></listitem>
                     <listitem><para><emphasis>Establish a local copy of the Linux Yocto kernel files on your 
                         system</emphasis>:  In order to make modifications to the kernel you need two things:
                         a bare clone of the Linux Yocto kernel you are modifying and  
@@ -416,7 +426,7 @@
                         Once the changes are made, you need to use Git commands to commit the changes
                         and then push them to the bare clone.</para></listitem>                      
                     <listitem><para><emphasis>Make kernel configuration changes
-                        to your local kernel layer if applicable</emphasis>:  
+                        if applicable</emphasis>:  
                         If your situation calls for changing the kernel's configuration, you can 
                         use <filename>menuconfig</filename>
                         to enable and disable kernel configurations.  
@@ -424,11 +434,18 @@
                         configuration changes you are making to the kernel.
                         When saved, changes using <filename>menuconfig</filename> update the kernel's
                         <filename>.config</filename>.
-                        As an alternative method to changing the kernel's configuration, you can simply
-                        edit the <filename>.config</filename> found in the Yocto Project build 
-                        directory at <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename> 
-                        directly.</para></listitem>                      
-                    <listitem><para><emphasis>Add new kernel recipes if applicable</emphasis>:  The standard 
+                        Try to resist the temptation of directly editing the <filename>.config</filename> 
+                        file found in the Yocto Project build directory at 
+                        <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename>.
+                        Doing so, can produce unexpected results when the Yocto Project build system 
+                        regenerates the configuration file.</para>
+                        <para>Once you are satisfied with the configuration changes made using 
+                        <filename>menuconfig</filename>, you can directly examine the 
+                        <filename>.config</filename> file against a saved original and gather those
+                        changes into a config fragment to be referenced from within the kernel's   
+                        <filename>.bbappend</filename> file.</para></listitem>                      
+                    <listitem><para><emphasis>Add or extend kernel recipes if applicable</emphasis>:  
+                        The standard 
                         layer structure organizes recipe files inside the 
                         <filename>meta-kernel-dev</filename> layer that is within the 
                         <filename>poky-extras</filename> Git repository.
@@ -440,14 +457,15 @@
                     <listitem><para><emphasis>Prepare for the build</emphasis>:  Once you have made all the 
                         changes to your kernel (configurations, source code changes, recipe additions, 
                         or recipe changes), there remains a few things 
-                        you need to do in order for the Yocto Project build system to create your image.  
+                        you need to do in order for the Yocto Project build system (BitBake) to create your image.  
                         If you have not done so, you need to get the build environment ready by sourcing 
                         the environment setup script described earlier.
                         You also need to be sure two key configuration files 
                         (<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
                         are configured appropriately.</para>
                         <para>The entire process for building an image is overviewed in the 
-                        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.    
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" 
+                        section of the Yocto Project Quick Start.    
                         You might want to reference this information.
                         Also, you should look at the detailed examples found in the appendices at 
                         at the end of this manual.</para></listitem>
@@ -458,8 +476,8 @@
                         <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
                         <para>The build process supports several types of images to satisfy different needs.  
                         See the appendix
-                        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
-                        in The Yocto Project Reference Manual for information on supported images.</para></listitem>
+                        "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" in 
+                        The Yocto Project Reference Manual for information on supported images.</para></listitem>
                     <listitem><para><emphasis>Make your configuration changes available
                         in the kernel layer</emphasis>:  Up to this point, all the configuration changes to the 
                         kernel have been done and tested iteratively.  
@@ -467,10 +485,10 @@
                         which allows you to distribute the layer.</para></listitem>
                     <listitem><para><emphasis>If applicable, share your in-tree changes</emphasis>:  
                         If the changes you made
-                        are suited for all Linux Yocto users, you might want to push the changes to a 
-                        contribution area for the Linux Yocto Git repository. 
-                        Once the changes are pushed, you can request that they 
-                        be pulled into the master branch of the kernel tree. 
+                        are suited for all Linux Yocto users, you might want to send them on for inclusion
+                        into the Linux Yocto Git repository. 
+                        If the changes are accepted, the Yocto Project Maintainer pulls them into 
+                        the master branch of the kernel tree. 
                         Doing so makes them available to everyone using the kernel.</para></listitem> 
                 </orderedlist>
             </para>
@@ -509,7 +527,7 @@
             provides an overview of the general development process.
             If you want to see a detailed example of the process as it is used from within the Eclipse 
             IDE, see 
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
+            <ulink url='&YOCTO_DOCS_ADT_URL;'>
             The Application Development Toolkit (ADT) User's Manual</ulink>.
         </para>
 
@@ -526,8 +544,8 @@
             <orderedlist>
                 <listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>:  
                     See  
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and  
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and  
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
 
 <!--
@@ -552,15 +570,15 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     You must have a target kernel image that has been built using the Yocto Project.</para>
                     <para>Depending on whether the Yocto Project has a pre-built image that matches your target
                     architecture and where you are going to run the image while you develop your application
-                    (QEMU or real hardware), the area you get the image from differs.
+                    (QEMU or real hardware), the area from which you get the image differs.
                         <itemizedlist>
                             <listitem><para>Download the image from  
-                                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'>  
+                                <ulink url='&YOCTO_MACHINES_DL_URL;'>  
                                 <filename>machines</filename></ulink> if your target architecture is supported
                                 and you are going to develop and test your application on actual hardware. 
                                 </para></listitem>
                             <listitem><para>Download the image from the 
-                                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu/'>  
+                                <ulink url='&YOCTO_QEMU_DL_URL;'>  
                                 <filename>machines/qemu</filename></ulink> if your target architecture is supported
                                 and you are going to develop and test your application using the QEMU 
                                 emulator.</para></listitem>
@@ -575,10 +593,8 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                         </itemizedlist></para>
                     <para>For information on pre-built kernel image naming schemes for images 
                     that can run on the QEMU emulator, see the
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
-                    section in  
-                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
-                    The Yocto Project Quick Start</ulink>.</para></listitem>
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+                    section in the Yocto Project Quick Start.</para></listitem>
                 <listitem><para><emphasis>Install the ADT</emphasis>:  
                     The ADT provides a target-specific cross-development toolchain, the root filesystem,
                     the QEMU emulator, and other tools that can help you develop your application.
@@ -586,9 +602,9 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     easy method.
                     You can get these pieces by running an ADT installer script, which is configurable.
                     For information on how to install the ADT, see the
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-the-adt-installer'>Using the ADT Installer</ulink>" section in
-                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
-                    Application Development (ADT) User's Manual</ulink>.</para></listitem>
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>"
+                    section 
+                    in the Yocto Project Application Development (ADT) User's Manual.</para></listitem>
                 <listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem</emphasis>:  
                     If you choose not to install the ADT using the ADT Installer,
                     you need to find and download the 
@@ -632,14 +648,14 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
             <orderedlist>
                 <listitem><para><emphasis>Install the cross-development toolchain for your target hardware:</emphasis> 
                     For information on how to install the toolchain, see the
-                    "<ulink url='http://www.yoctoproject/docs/1.1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" section in
-                    <ulink url='http://www.yoctoproject/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
-                    Application Development (ADT) User's Manual</ulink>.</para></listitem>
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" 
+                    section
+                    in the Yocto Project Application Development (ADT) User's Manual.</para></listitem>
                 <listitem><para><emphasis>Download the Target Image:</emphasis>  The Yocto Project supports
                     several target architectures and has many pre-built kernel images and root filesystem 
                     images.</para>
                     <para>If you are going to develop your application on hardware, go to the 
-                    <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'>  
+                    <ulink url='&YOCTO_MACHINES_DL_URL;'>  
                     <filename>machines</filename></ulink> download area and choose a target machine area
                     from which to download the kernel image and root filesystem.
                     This download area could have several files in it that support development using   
@@ -649,7 +665,7 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     Be sure to get the files you need for your particular development process.</para>
                     <para>If you are going to develop your application and then run and test it using the QEMU
                     emulator, go to the 
-                    <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu/'>  
+                    <ulink url='&YOCTO_QEMU_DL_URL;'>  
                     <filename>machines/qemu</filename></ulink> download area.
                     From this area, go down into the directory for your target architecture
                     (e.g. <filename>qemux86_64</filename> for an 
@@ -657,7 +673,7 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     Download kernel, root filesystem, and any other files you need for your process.
                     <note>In order to use the root filesystem in QEMU, you need to extract it.
                     See the 
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>" section for information on how to extract the 
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>" section for information on how to extract the 
                     root filesystem.</note></para></listitem>
                 <listitem><para><emphasis>Develop and Test your Application:</emphasis>  At this point, 
                     you have the tools to develop your application.  

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='dev-manual-newbie'>
 
@@ -7,11 +8,11 @@
 
 <para>
     This chapter helps you understand the Yocto Project as an open source development project.
-    In general, working in an open source environment is very different as compared to working in a 
-    proprietary environment.  
+    In general, working in an open source environment is very different from working in a 
+    closed, proprietary environment.  
     Additionally, the Yocto Project uses specific tools and constructs as part of its development 
     environment.  
-    The chapter specifically addresses open source philosophy, licensing issues, code repositories, 
+    This chapter specifically addresses open source philosophy, licensing issues, code repositories, 
     the open source distributed version control system Git, and best practices using the Yocto Project.
 </para>
 
@@ -20,10 +21,10 @@
 
     <para>
         Open source philosophy is characterized by software development directed by peer production 
-        and collaboration through a concerned community of developers.  
+        and collaboration through an active community of developers.
         Contrast this to the more standard centralized development models used by commercial software 
         companies where a finite set of developers produce a product for sale using a defined set 
-        of procedures that ultimately result in an end-product whose architecture and source material 
+        of procedures that ultimately result in an end product whose architecture and source material
         are closed to the public.
     </para>
 
@@ -33,7 +34,7 @@
         stake in the software project.  
         The open source environment contains new copyright, licensing, domain, and consumer issues 
         that differ from the more traditional development environment.  
-        In an open source environment, the end-product, source material, and documentation are 
+        In an open source environment, the end product, source material, and documentation are
         all available to the public at no cost.
     </para>
 
@@ -58,7 +59,7 @@
 
     <para>
         The Yocto Project team maintains complete source repositories for all Yocto Project files 
-        <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>here</ulink>.
+        at <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>.
         This web-based source code browser is organized into categories by function such as
         IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth.
         From the interface, you can click on any particular item in the "Name" column and 
@@ -73,13 +74,13 @@
         Conversely, if you are a developer that is not interested in contributing back to the 
         Yocto Project, you have the ability to simply download and extract release tarballs
         and use them within the Yocto Project environment.
-        All that is required is a particular release of Yocto Project, a kernel, and 
+        All that is required is a particular release of the Yocto Project and 
         your application source code.  
     </para>
 
     <para>
         For any supported release of Yocto Project, you can go to the Yocto Project website’s 
-        <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and get a 
+        <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink> and get a 
         tarball of the release.  
         You can also go to this site to download any supported BSP tarballs.
         Unpacking the tarball gives you a hierarchical directory structure of Yocto Project 
@@ -94,15 +95,15 @@
     <para>
         In summary, here is where you can get the Yocto Project files needed for development:
         <itemizedlist>
-            <listitem><para><emphasis><ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
+            <listitem><para><emphasis><ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
                 This area contains IDE Plugins, Matchbox, Poky, Poky Support, Tools, Yocto Linux Kernel, and Yocto 
                 Metadata Layers.
                 You can create Git repositories for each of these areas.</para>
                 <para>
                 <imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
-            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink></emphasis>
-                This area contains an index releases such as 
+            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink></emphasis>
+                This area contains index releases such as 
                 the <trademark class='trade'>Eclipse</trademark>
                 Yocto Plug-in, miscellaneous support, Poky, pseudo, cross-development toolchains,
                 and all released versions of Yocto Project in the form of images or tarballs.
@@ -111,11 +112,11 @@
                 <para>
                 <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
-            <listitem><para><emphasis><ulink url='http://www.yoctoproject.org/download'>Yocto Project Download Page</ulink></emphasis>
+            <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;/download'>Yocto Project Download Page</ulink></emphasis>
                 This page on the Yocto Project website allows you to download any Yocto Project
                 release or Board Support Package (BSP) in tarball form.
                 The tarballs are similar to those found in the 
-                <ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink> area.</para>
+                <ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink> area.</para>
                 <para>
                 <imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" />
             </para></listitem>
@@ -170,10 +171,8 @@
             Images are the binary output that runs on specific hardware and for specific
             use cases.
             For a list of the supported image types that the Yocto Project provides, see the
-            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
-            appendix in
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
-            The Yocto Project Reference Manual</ulink>.</para></listitem>
+            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>"
+            appendix in the Yocto Project Reference Manual.</para></listitem>
         <listitem><para><emphasis>Layer:</emphasis> A collection of recipes representing the core, 
             a BSP, or an application stack.</para></listitem>
         <listitem><para><emphasis>Metadata:</emphasis> The files that BitBake parses when building an image. 
@@ -216,14 +215,14 @@
             system in order to do any development using the Yocto Project.</para>
             <para>The name of the top-level directory of the Yocto Project file structure  
             is derived from the Yocto Project release tarball.
-            For example, downloading and unpacking <filename>poky-edison-6.0.1.tar.bz2</filename>
+            For example, downloading and unpacking <filename>&YOCTO_POKY_TARBALL;</filename>
             results in a Yocto Project file structure whose Yocto Project source directory is named 
-            <filename>poky-edison-6.0.1</filename>.
+            <filename>&YOCTO_POKY;</filename>.
             If you create a Git repository, then you can name the repository anything you like.</para>
             <para>You can find instruction on how to set up the Yocto Project files on your 
             host development system by reading 
             the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-setup'>Getting
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting
             Setup</ulink>" section.</para></listitem>
         <listitem><para><emphasis>Yocto Project Build Directory:</emphasis>
             This term refers to the area used by the Yocto Project for builds.  
@@ -233,9 +232,9 @@
             You can create the Yocto Project build directory anywhere you want on your 
             development system.
             Here is an example that creates the directory in <filename>mybuilds</filename> 
-            and names the Yocto Project build directory <filename>YP-6.0.1</filename>:
+            and names the Yocto Project build directory <filename>YP-&POKYVERSION;</filename>:
             <literallayout class='monospaced'> 
-     $ source poky-edison-6.0.1/oe-init-build-env $HOME/mybuilds/YP-6.0.1
+     $ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION;
             </literallayout>
             If you don't specifically name the directory, BitBake creates it 
             in the current directory and uses the name <filename>build</filename>.
@@ -305,7 +304,7 @@
 
     <para>
         You can find a list of the combined SPDX and OSI licenses that the Yocto Project uses 
-        <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
+        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
         This wiki page discusses the license infrastructure used by the Yocto Project.
     </para>
 </section>
@@ -316,7 +315,10 @@
     <para>
         The Yocto Project uses Git, which is a free, open source distributed version control system.  
         Git supports distributed development, non-linear development, and can handle large projects.  
-        It is best that you know how to work with Git if you are going to use Yocto Project for development.  
+        It is best that you have some fundamental understanding of how Git tracks projects and 
+        how to work with Git if you are going to use Yocto Project for development. 
+        This section provides a quick overview of how Git works and provides you with a summary
+        of some essential Git commands.
     </para>
 
     <para>
@@ -423,7 +425,7 @@
         In particular, the information covers basic practices that describe roles and actions in a 
         collaborative development environment.  
         Again, if you are familiar with this type of development environment, you might want to just 
-        skip the section. 
+        skip this section.
     </para>
 
     <para>
@@ -436,7 +438,7 @@
         The maintainer is responsible for allowing changes in from other developers and for 
         organizing the underlying branch structure to reflect release strategies and so forth.  
         <note>You can see who is the maintainer for Yocto Project files by examining the 
-        <filename>distro_tracking_fields</filename> file in the Yocto Project 
+        <filename>distro_tracking_fields.inc</filename> file in the Yocto Project
         <filename>meta/conf/distro/include</filename> directory.</note>  
     </para>
 
@@ -475,7 +477,7 @@
         "master" branch of the Git repository, which is controlled by the project’s maintainer.  
         And, we have a set of developers who independently develop, test, and submit changes 
         to "contrib" areas for the maintainer to examine.  
-        The maintainer then chooses which changes are going to become permanently a part of the project.  
+        The maintainer then chooses which changes are going to become a permanent part of the project.
     </para>
 
     <para>
@@ -489,12 +491,15 @@
         For more information about Git workflows, see the workflow topics in the 
         <ulink url='http://book.git-scm.com'>Git Community Book</ulink>. 
         <itemizedlist>
-            <listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep your changes you commit 
+            <listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep the changes you commit
                 small as compared to bundling many disparate changes into a single commit.  
                 This practice not only keeps things manageable but also allows the maintainer 
                 to more easily include or refuse changes.</para>
                 <para>It is also good practice to leave the repository in a state that allows you to 
-                still successfully build your project.</para></listitem>
+                still successfully build your project.  In other words, do not commit half of a feature,
+                then add the other half in a separate, later commit.  
+                Each commit should take you from one buildable project state to another 
+                buildable state.</para></listitem>
             <listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and 
                 delete local branches in your working Git repository.  
                 You can name these branches anything you like.  
@@ -527,7 +532,7 @@
                 <filename>send-pull-request</filename> that ship with the release to facilitate this 
                 workflow.
                 You can find these scripts in the local Yocto Project files Git repository in
-                <filename>scripts</filename>.</para></listitem>
+                the <filename>scripts</filename> directory.</para></listitem>
             <listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the 
                 maintainer through an email that you have a change (or patch) you would like considered 
                 for the "master" branch of the Git repository.  
@@ -548,7 +553,7 @@
         changes, can be used to communicate changes and problems with developers, can be used to 
         submit and review patches, and can be used to manage quality assurance. 
         The home page for the Yocto Project implementation of Bugzilla is   
-        <ulink url='http://bugzilla.yoctoproject.org'>http://bugzilla.yoctoproject.org</ulink>.
+        <ulink url='&YOCTO_BUGZILLA_URL;'>&YOCTO_BUGZILLA_URL;</ulink>.
     </para>
 
     <para>
@@ -559,7 +564,7 @@
         Bugzilla.
         You can find more information on defect management, bug tracking, and feature request
         processes all accomplished through the Yocto Project Bugzilla on the wiki page
-        <ulink url='https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking'>here</ulink>.     
+        <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>here</ulink>.     
         <orderedlist>
             <listitem><para>Always use the Yocto Project implementation of Bugzilla to submit
                 a bug.</para></listitem>
@@ -602,27 +607,28 @@
 
     <para>
         Contributions to the Yocto Project are very welcome. 
+        Because the Yocto Project is extremely configurable and flexible, we recognize that developers 
+        will want to extend, configure or optimize it for their specific uses.
         You should send patches to the appropriate Yocto Project mailing list to get them 
         in front of the Yocto Project Maintainer.
         For a list of the Yocto Project mailing lists, see the
-        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#resources-mailinglist'>Mailing lists</ulink>" section in 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'> The 
-        Yocto Project Reference Manual</ulink>.
+        "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in 
+        The Yocto Project Reference Manual.
     </para>
 
     <para>
-        Following is some guidance on which mailing list to use for what type of defect:
+        The following is some guidance on which mailing list to use for what type of defect:
         <itemizedlist>
             <listitem><para>For defects against the Yocto Project build system Poky, send 
                 your patch to the  
-                <ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> mailing list. 
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> mailing list. 
                 This mailing list corresponds to issues that are not specific to the Yocto Project but
                 are part of the OE-core.
                 For example, a defect against anything in the <filename>meta</filename> layer 
                 or the BitBake Manual could be sent to this mailing list.</para></listitem>
             <listitem><para>For defects against Yocto-specific layers, tools, and Yocto Project 
                 documentation use the 
-                <ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> mailing list.
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> mailing list.
                 This mailing list corresponds to Yocto-specific areas such as 
                 <filename>meta-yocto</filename>, <filename>meta-intel</filename>, 
                 <filename>linux-yocto</filename>, and <filename>documentation</filename>.</para></listitem>
@@ -630,7 +636,7 @@
     </para>
 
     <para>  
-        When you send a patch, be sure to include a "signed-off-by:"
+        When you send a patch, be sure to include a "Signed-off-by:"
         line in the same style as required by the Linux kernel. 
         Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1
         as follows:
@@ -672,11 +678,14 @@
     <para>
         In a collaborative environment, it is necessary to have some sort of standard 
         or method through which you submit changes.  
-        Otherwise, things could get quite chaotic.  
+        Otherwise, things could get quite chaotic.
+        One general practice to follow is to make small, controlled changes to the 
+        Yocto Project.
+        Keeping changes small and isolated lets you best keep pace with future Yocto Project changes.
     </para>
 
     <para>
-        When you form a commit, you must follow certain standards established by the 
+        When you create a commit, you must follow certain standards established by the
         Yocto Project development team. 
         For each commit, you must provide a single-line summary of the change and you 
         almost always provide a more detailed description of what you did (i.e. the body 
@@ -710,7 +719,7 @@
     <para>
         You can find more guidance on creating well-formed commit messages at this OpenEmbedded 
         wiki page:
-        <ulink url='http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines'></ulink>.
+        <ulink url='&OE_HOME_URL;/wiki/Commit_Patch_Message_Guidelines'></ulink>.
     </para>
 
     <para>
@@ -774,7 +783,7 @@
                     See the earlier section
                     "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" 
                     for Yocto Project commit message standards.</para></listitem>
-                <listitem><para>Format the commit into an email messsage.
+                <listitem><para>Format the commit into an email message.
                     To format commits, use the <filename>git format-patch</filename> command.
                     When you provide the command, you must include a revision list or a number of patches
                     as part of the command.
@@ -789,6 +798,11 @@
                     <para>If you provide several commits as part of the command, 
                     the <filename>git format-patch</filename> command produces a numbered 
                     series of files in the current directory – one for each commit.
+                    If you have more than one patch, you should also use the 
+                    <filename>--cover</filename> option with the command, which generates a 
+                    cover letter as the first "patch" in the series.  
+                    You can then edit the cover letter to provide a description for 
+                    the series of patches.
                     For information on the <filename>git format-patch</filename> command, 
                     see <filename>GIT_FORMAT_PATCH(1)</filename> displayed using the  
                     <filename>man git-format-patch</filename> command.</para></listitem>
@@ -801,7 +815,15 @@
                     or remote Mail Transport Agent (MTA) such as 
                     <filename>msmtp</filename>, <filename>sendmail</filename>, or through a direct
                     <filename>smtp</filename> configuration in your Git <filename>config</filename>
-                    file.</para>
+                    file.
+                    If you are submitting patches through email only, it is very important
+                    that you submit them without any whitespace or HTML formatting that 
+                    either you or your mailer introduces.
+                    The maintainer that receives your patches needs to be able to save and 
+                    apply them directly from your emails.
+                    A good way to verify that what you are sending will be applicable by the 
+                    maintainer is to do a dry run and send them to yourself and then 
+                    save and apply them as the maintainer would.</para>
                     <para>The <filename>git send-email</filename> command is the preferred method
                     for sending your patches since there is no risk of compromising whitespace
                     in the body of the message, which can occur when you use your own mail client.

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='dev-manual-start'>
 
@@ -9,7 +10,7 @@
     This chapter introduces the Yocto Project and gives you an idea of what you need to get started.  
     You can find enough information to set up your development host and build or use images for 
     hardware supported by the Yocto Project by reading  
-    <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
+    <ulink url='&YOCTO_DOCS_QS_URL;'>
     The Yocto Project Quick Start</ulink>.
 </para>
 
@@ -30,20 +31,21 @@
     </para>
 
     <para>
-        You can use the Yocto Project, which uses the BitBake build tool, to develop complete Linux 
+        You can use the Yocto Project build system, which uses 
+        <ulink url='http://bitbake.berlios.de/manual/'>BitBake</ulink>, to develop complete Linux 
         images and associated user-space applications for architectures based on ARM, MIPS, PowerPC, 
         x86 and x86-64.  
         While the Yocto Project does not provide a strict testing framework,
         it does provide or generate for you artifacts that let you perform target-level and 
         emulated testing and debugging.  
-        And, if you are an <trademark class='trade'>Eclipse</trademark>
+        Additionally, if you are an <trademark class='trade'>Eclipse</trademark>
         IDE user, you can install an Eclipse Yocto Plug-in to allow you to 
         develop within that familiar environment.
     </para>
 </section>
 
 <section id='getting-setup'>
-    <title>Getting Setup</title>
+    <title>Getting Set Up</title>
 
     <para>
         Here is what you need to get set up to use the Yocto Project:
@@ -57,7 +59,7 @@
                 </para></listitem>
             <listitem><para><emphasis>Packages:</emphasis>  The Yocto Project requires certain packages
                 exist on your development system (e.g. Python 2.6 or 2.7).  
-                See "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" 
+                See "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" 
                 section in the Yocto Project Quick start for the exact package 
                 requirements and the installation commands to install them 
                 for the supported distributions.</para></listitem>
@@ -73,29 +75,37 @@
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>  If you are not going to contribute 
                         back into the Yocto Project, you can simply download the Yocto Project release you want 
-                        from the website’s <ulink url='http://yoctoproject.org/download'>download page</ulink>.
+                        from the website’s <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink>.
                         Once you have the tarball, just extract it into a directory of your choice.</para>
-                        <para>For example, the following command extracts the Yocto Project 1.1.1 release tarball 
+                        <para>For example, the following command extracts the Yocto Project &DISTRO; 
+                        release tarball 
                         into the current working directory and sets up the Yocto Project file structure
-                        with a top-level directory named <filename>poky-edison-6.0.1</filename>:
+                        with a top-level directory named <filename>&YOCTO_POKY;</filename>:
                         <literallayout class='monospaced'>
-     $ tar xfj poky-edison-6.0.1.tar.bz2
+     $ tar xfj &YOCTO_POKY_TARBALL;
                         </literallayout></para>
                         <para>This method does not produce a Git repository. 
                         Instead, you simply end up with a local snapshot of the 
                         Yocto Project files that are based on the particular release in the 
                         tarball.</para></listitem>
                     <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are going to be contributing
-                        back into the Yocto Project, you should use Git commands to set up a local 
-                        Git repository of the Yocto Project files.  
+                        back into the Yocto Project or you simply want to keep up
+                        with the latest developments, you should use Git commands to set up a local
+                        Git repository of the Yocto Project files.
                         Doing so creates a Git repository with a complete history of changes and allows 
-                        you to easily submit your changes upstream to the project.</para>
-                       <para>The following transcript shows how to clone the Yocto Project files'  
-                       Git repository into the current working directory.  
-                       The command creates the repository in a directory named <filename>poky</filename>.
-                       For information on the Yocto Project and Git, see the
-                       "<link linkend='git'>Git</link>" section.
-                       <literallayout class='monospaced'>
+                        you to easily submit your changes upstream to the project.
+                        Because you cloned the repository, you have access to all the Yocto Project development
+                        branches and tag names used in the upstream repository.</para>
+                        <para>The following transcript shows how to clone the Yocto Project Files'  
+                        Git repository into the current working directory.
+                        <note>The name of the Yocto Project Files Git repository in the Yocto Project Files
+                        Source Repositories is <filename>poky</filename>.
+                        You can view the Yocto Project Source Repositories at
+                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink></note>  
+                        The command creates the local repository in a directory named <filename>poky</filename>.
+                        For information on Git used within the Yocto Project, see the
+                        "<link linkend='git'>Git</link>" section.
+                        <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Initialized empty Git repository in /home/scottrif/poky/.git/
      remote: Counting objects: 116882, done.
@@ -104,15 +114,18 @@
      Receiving objects: 100% (116882/116882), 72.13 MiB | 2.68 MiB/s, done.
      Resolving deltas: 100% (80651/80651), done.                       </literallayout></para>
                        <para>For another example of how to set up your own local Git repositories, see this
-                        <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
                         wiki page</ulink>, which describes how to create both <filename>poky</filename>
                         and <filename>meta-intel</filename> Git repositories.</para></listitem>
                 </itemizedlist></para></listitem>
             <listitem id='local-kernel-files'><para><emphasis>Linux Yocto Kernel:</emphasis>  
                 If you are going to be making modifications to a supported Linux Yocto kernel, you 
                 need to establish local copies of the source.
-                This setup involves creating a bare clone of the Linux Yocto kernel and then cloning 
-                that repository.
+                You can find Git repositories of supported Linux Yocto Kernels organized under
+                "Yocto Linux Kernel" in the Yocto Project Source Repositories at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
+                <para>This setup involves creating a bare clone of the Linux Yocto kernel and then 
+                copying that cloned repository.
                 You can create the bare clone and the copy of the bare clone anywhere you like.
                 For simplicity, it is recommended that you create these structures outside of the 
                 Yocto Project files' Git repository.</para>
@@ -122,8 +135,8 @@
                 <note>When you have a local Linux Yocto kernel Git repository, you can 
                 reference that repository rather than the upstream Git repository as 
                 part of the <filename>clone</filename> command.
-                Doing so can speed up the process.</note>
-                In the following example, the bare clone is named 
+                Doing so can speed up the process.</note></para>
+                <para>In the following example, the bare clone is named 
                 <filename>linux-yocto-3.0-1.1.x.git</filename>, while the 
                 copy is named <filename>my-linux-yocto-3.0-1.1.x-work</filename>: 
                 <literallayout class='monospaced'>
@@ -143,20 +156,23 @@
                 </literallayout></para></listitem>
             <listitem id='poky-extras-repo'><para><emphasis>
                 The <filename>poky-extras</filename> Git Repository</emphasis>:
-                The <filename>poky-extras</filename> Git repository contains metadata needed to 
-                build the kernel image.
-                In particular, it contains the kernel <filename>.bbappend</filename> files that you 
+                The <filename>poky-extras</filename> Git repository contains metadata needed 
+                only if you are modifying and building the kernel image.
+                In particular, it contains the kernel BitBake append (<filename>.bbappend</filename>)
+                files that you 
                 edit to point to your locally modified kernel source files and to build the kernel
                 image. 
                 Pointing to these local files is much more efficient than requiring a download of the 
                 source files from upstream each time you make changes to the kernel.</para>
-                <para>It is good practice to create this Git repository inside the Yocto Project
-                files Git repository.
-                Following is an example that creates the <filename>poky-extras</filename> Git 
+                <para>You can find the <filename>poky-extras</filename> Git Repository in the 
+                "Yocto Metadata Layers" area of the Yocto Project Source Repositories at 
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
+                It is good practice to create this Git repository inside the Yocto Project
+                files Git repository.</para>
+                <para>Following is an example that creates the <filename>poky-extras</filename> Git 
                 repository inside the Yocto Project files Git repository, which is named 
                 <filename>poky</filename> in this case:
                 <literallayout class='monospaced'>
-     $ cd ~/poky
      $ git clone git://git.yoctoproject.org/poky-extras poky-extras
      Initialized empty Git repository in /home/scottrif/poky/poky-extras/.git/
      remote: Counting objects: 561, done.
@@ -169,6 +185,7 @@
                 Similar considerations exist for BSPs.  
                 You can get set up for BSP development one of two ways: tarball extraction or
                 with a local Git repository.
+                It is a good idea to use the same method used to set up the Yocto Project Files.
                 Regardless of the method you use, the Yocto Project uses the following BSP layer 
                 naming scheme:
                 <literallayout class='monospaced'> 
@@ -184,21 +201,23 @@
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>  You can download any released 
                         BSP tarball from the same 
-                        <ulink url='http://yoctoproject.org/download'>download site</ulink> used 
+                        <ulink url='&YOCTO_HOME_URL;/download'>download site</ulink> used 
                         to get the Yocto Project release.  
                         Once you have the tarball, just extract it into a directory of your choice.
                         Again, this method just produces a snapshot of the BSP layer in the form
                         of a hierarchical directory structure.</para></listitem>
                     <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are working 
-                        with a Yocto Project files Git repository, you should also set up a 
-                        <filename>meta-intel</filename> Git repository.  
-                        Typically, you set up the <filename>meta-intel</filename> Git repository inside
-                        the Yocto Project files Git repository.</para>
-                        <para>For example, the following transcript shows the steps to clone the 
+                        with a Yocto Project Files Git repository, you should also use this method 
+                        to set up the <filename>meta-intel</filename> Git repository.
+                        You can locate the <filename>meta-intel</filename> Git repository in the 
+                        "Yocto Metadata Layers" area of the Yocto Project Source Repositories at
+                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
+                        <para>Typically, you set up the <filename>meta-intel</filename> Git repository inside
+                        the Yocto Project Files Git repository.
+                        For example, the following transcript shows the steps to clone the 
                         <filename>meta-intel</filename>
                         Git repository inside the <filename>poky</filename> Git repository.
                         <literallayout class='monospaced'>
-     $cd poky
      $ git clone git://git.yoctoproject.org/meta-intel.git
      Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/
      remote: Counting objects: 3279, done.
@@ -208,7 +227,7 @@
      Resolving deltas: 100% (1761/1761), done.
                         </literallayout></para>
                         <para>The same  
-                        <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
                         wiki page</ulink> referenced earlier covers how to 
                         set up the <filename>meta-intel</filename> Git repository.</para></listitem>
                 </itemizedlist></para></listitem>
@@ -216,7 +235,7 @@
                 applications using the Eclipse Integrated Development Environment (IDE),
                 you will need this plug-in.  
                 See the 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
                 section in the Yocto Application Development Toolkit (ADT) 
                 User’s Guide for more information.</para></listitem>
         </itemizedlist>
@@ -229,7 +248,7 @@
     <para>
         The build process creates an entire Linux distribution, including the toolchain, from source.  
         For more information on this topic, see the 
-        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>"
+        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
         section in the Yocto Project Quick Start.
     </para>
 
@@ -240,12 +259,20 @@
                 previous section.</para></listitem>
             <listitem><para>Initialize the build environment by sourcing a build environment 
                 script.</para></listitem>
-            <listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file is set 
-                up how you want it.  
-                This file defines the target machine architecture and other build options.</para></listitem>
-            <listitem><para>Build the image using the BitBake command.  
-                If you want information on Bitbake, see the user manual at 
-                <ulink url='http://docs.openembedded.org/bitbake/html'></ulink>.</para></listitem>
+            <listitem><para>Optionally ensure the <filename>/conf/local.conf</filename> configuration file, 
+                which is found in the Yocto Project build directory, 
+                is set up how you want it.  
+                This file defines many aspects of the build environment including 
+                the target machine architecture through the 
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'>MACHINE</ulink></filename> variable, 
+                the development machine's processor use through the 
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</ulink></filename> and 
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'>PARALLEL_MAKE</ulink></filename> variables, and
+                a centralized tarball download directory through the  
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'>DL_DIR</ulink></filename> variable.</para></listitem>
+            <listitem><para>Build the image using the <filename>bitbake</filename> command.
+                If you want information on BitBake, see the user manual at
+                <ulink url='&OE_DOCS_URL;/bitbake/html'></ulink>.</para></listitem>
             <listitem><para>Run the image either on the actual hardware or using the QEMU 
                 emulator.</para></listitem>
         </orderedlist>
@@ -256,18 +283,37 @@
     <title>Using Pre-Built Binaries and QEMU</title>
 
     <para>
-        Another option you have to get started is to use pre-built binaries.  
-        This scenario is ideal for developing software applications to run on your target hardware.  
-        To do this, you need to install the stand-alone Yocto Project cross-toolchain tarball and 
-        then download the pre-built kernel that you will boot in the QEMU emulator.  
-        Next, you must download and extract the target root filesystem for your target 
-        machine’s architecture.  
-        Finally, you set up the environment to emulate the hardware and then start the QEMU emulator.
+        Another option you have to get started is to use pre-built binaries. 
+        The Yocto Project provides many types of binaries with each release. 
+        See the <ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>
+        section for descriptions of the types of binaries that ship with a Yocto Project
+        release.
     </para>
 
     <para>
+        Using a pre-built binary is ideal for developing software applications to run on your 
+        target hardware.  
+        To do this, you need to be able to access the appropriate cross-toolchain tarball for 
+        the architecture on which you are developing.  
+        If you are using an SDK type image, the image ships with the complete toolchain native to 
+        the architecture. 
+        If you are not using an SDK type image, you need to separately download and 
+        install the stand-alone Yocto Project cross-toolchain tarball.
+    </para>
+
+    <para>
+        Regardless of the type of image you are using, you need to download the pre-built kernel 
+        that you will boot in the QEMU emulator and then download and extract the target root 
+        filesystem for your target machine’s architecture.
+        You can get architecture-specific binaries and filesystem from
+        <ulink url='&YOCTO_MACHINES_DL_URL;'>machines</ulink>.
+        You can get stand-alone toolchains from
+        <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchains</ulink>.
+        Once you have all your files, you set up the environment to emulate the hardware 
+        by sourcing an environment setup script. 
+        Finally, you start the QEMU emulator.
         You can find details on all these steps in the 
-        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
         section of the Yocto Project Quick Start. 
     </para>
 </section>

documentation/dev-manual/dev-manual.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='dev-manual' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -38,10 +39,15 @@
                 <date>15 March 2012</date>
                 <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-     <year>2010-2012</year>
+     <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -56,9 +62,9 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and  
-          <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
+          <ulink url='&YOCTO_DOCS_DEV_URL;'>
           The Yocto Project Development Manual</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>

documentation/dev-manual/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -946,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -958,11 +958,26 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

documentation/kernel-manual/kernel-concepts.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='kernel-concepts'>
 
@@ -44,13 +45,13 @@
             management techniques.</para></listitem>
             <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that 
             the baseline kernel is the most stable official release.</para></listitem>
-            <listitem><para>Include major technological features as part of Yocto Project's up-rev 
-            strategy.</para></listitem>
+            <listitem><para>Include major technological features as part of Yocto Project's 
+            upward revision strategy.</para></listitem>
             <listitem><para>Present a kernel Git repository that, similar to the upstream 
             <filename>kernel.org</filename> tree, 
             has a clear and continuous history.</para></listitem>
             <listitem><para>Deliver a key set of supported kernel types, where each type is tailored 
-            to a specific use case (e.g. networking, consumer, devices, and so forth).</para></listitem>
+            to meet a specific use (e.g. networking, consumer, devices, and so forth).</para></listitem>
             <listitem><para>Employ a Git branching strategy that, from a developer's point of view,
             results in a linear path from the baseline <filename>kernel.org</filename>, 
             through a select group of features and
@@ -78,7 +79,7 @@
         </para>
         <para>
             This balance allows the team to deliver the most up-to-date kernel
-            as possible, while still ensuring that the team has a stable official release as
+            as possible, while still ensuring that the team has a stable official release for
             the baseline kernel version.
         </para>
         <para>
@@ -94,8 +95,8 @@
         </para>
         <para>
             Once a Yocto Project kernel is officially released, the Yocto Project team goes into 
-            their next development cycle, or "uprev" cycle, while still continuing maintenance on the 
-            released kernel.
+            their next development cycle, or upward revision (uprev) cycle, while still 
+            continuing maintenance on the released kernel.
             It is important to note that the most sustainable and stable way
             to include feature development upstream is through a kernel uprev process.
             Back-porting hundreds of individual fixes and minor features from various
@@ -148,7 +149,8 @@
         <section id='architecture-overview'>
             <title>Overview</title>
             <para>
-                As mentioned earlier, a key goal of Yocto Project is to present the developer with 
+                As mentioned earlier, a key goal of the Yocto Project is to present the 
+                developer with 
                 a kernel that has a clear and continuous history that is visible to the user. 
                 The architecture and mechanisms used achieve that goal in a manner similar to the 
                 upstream <filename>kernel.org</filename>.
@@ -159,9 +161,8 @@
                 The features are tagged and organized by way of a branching strategy implemented by the 
                 source code manager (SCM) Git.
                 For information on Git as applied to the Yocto Project, see the
-                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
-                section in <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
-                Yocto Project Development Manual</ulink>.
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" section in the 
+                Yocto Project Development Manual.
             </para>
             <para>
                 The result is that the user has the ability to see the added features and 
@@ -176,7 +177,7 @@
                 <imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" />
             </para>
             <para>
-                In the illustration, the "<filename>kernel.org</filename> Branch Point" 
+                In the illustration, the "Kernel.org Branch Point" 
                 marks the specific spot (or release) from 
                 which the Yocto Project kernel is created.  
                 From this point "up" in the tree, features and differences are organized and tagged.
@@ -288,11 +289,10 @@
             <para>
                 You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>.
                 You can also get an introduction to Git as it applies to the Yocto Project in the
-                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
-                section in <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
-                Yocto Project Development Manual</ulink>. 
-                This section overviews Git and describes a minimal set of commands that allow you to be 
-                functional using Git.
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
+                section in the Yocto Project Development Manual. 
+                These referenced sections overview Git and describe a minimal set of 
+                commands that allow you to be functional using Git.
                 <note>
                     You can use as much, or as little, of what Git has to offer to accomplish what
                     you need for your project.
@@ -336,11 +336,6 @@ kernel toolkit:
 </itemizedlist>
 </para> -->
     </section> 
-
-
-
-
-
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/kernel-manual/kernel-doc-intro.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='kernel-doc-intro'>
 
@@ -11,7 +12,7 @@
         The Yocto Project presents the kernel as a fully patched, history-clean Git
         repository. 
         The Git tree represents the selected features, board support,
-        and configurations extensively tested by Yocto Project. 
+        and configurations extensively tested by the Yocto Project. 
         The Yocto Project kernel allows the end user to leverage community
         best practices to seamlessly manage the development, build and debug cycles.
     </para>
@@ -28,32 +29,39 @@
             <listitem><para><emphasis>Using the Kernel:</emphasis> Describes best practices 
                 and "how-to" information
                 that lets you put the kernel to practical use.  
-                Some examples are "How to Build a 
-                Project Specific Tree", "How to Examine Changes in a Branch", and "How to 
-                Save Kernel Modifications."</para></listitem>
+                Some examples are how to examine changes in a branch and how to 
+                save kernel modifications.</para></listitem>
         </itemizedlist>
     </para>
 
     <para>
-        For more information on the kernel, see the following links:
+        For more information on the Linux kernel, see the following links:
         <itemizedlist>
-            <listitem><para><ulink url='http://ldn.linuxfoundation.org/book/1-a-guide-kernel-development-process'></ulink></para></listitem>
-            <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem>
-            <listitem><para><ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem> 
+            <listitem><para>The Linux Foundation's guide for kernel development
+                process - <ulink url='http://ldn.linuxfoundation.org/book/1-a-guide-kernel-development-process'></ulink></para></listitem>
+<!--            <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem> -->
+            <listitem><para>A fairly emcompassing guide on Linux kernel development - 
+                <ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem> 
         </itemizedlist>
     </para>
 
     <para>
-        For more discussion on the Yocto Project kernel, you can also see the
-        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#kernel-overview'>Kernel Overview</ulink>",
-        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#kernel-modification-workflow'>Kernel Modification Workflow</ulink>", and 
-        "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-kernel-appendix'>Kernel Modification Example</ulink>" sections all in
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>.
+        For more discussion on the Yocto Project kernel, you can see these sections
+        in <ulink url='&YOCTO_DOCS_DEV_URL;'>The Yocto Project Development Manual</ulink>:
+        <itemizedlist>
+            <listitem><para>
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-overview'>Kernel Overview</ulink>"</para></listitem>
+            <listitem><para>
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-modification-workflow'>Kernel Modification Workflow</ulink>"
+                </para></listitem>
+            <listitem><para> 
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-kernel-appendix'>Kernel Modification Example</ulink>"</para></listitem>
+        </itemizedlist>
     </para>
 
     <para> 
         For general information on the Yocto Project, visit the website at
-        <ulink url='http://www.yoctoproject.org'></ulink>.
+        <ulink url='&YOCTO_HOME_URL;'></ulink>.
     </para>
 </section>
 

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='kernel-how-to'>
 
@@ -10,8 +11,8 @@
     <title>Introduction</title>
     <para>
         This chapter describes how to accomplish tasks involving the kernel's tree structure. 
-        This information is designed to help the developer that wants to modify the Yocto Project kernel
-        and contribute changes upstream to the Yocto Project.
+        The information is designed to help the developer that wants to modify the Yocto 
+        Project kernel and contribute changes upstream to the Yocto Project.
         The information covers the following:
         <itemizedlist> 
             <listitem><para>Tree construction</para></listitem>
@@ -24,10 +25,11 @@
     <section id='tree-construction'>
         <title>Tree Construction</title>
         <para>
-            This section describes construction of the Yocto Project kernel repositories as accomplished
-            by the Yocto Project team to create kernel repositories, which are found at
-            <ulink url='http://git.yoctoproject.org/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>,
-            that can be shipped as part of a Yocto Project release. 
+            This section describes construction of the Yocto Project kernel repositories 
+            as accomplished by the Yocto Project team to create kernel repositories.
+            These kernel repositories are found at
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
+            and can be shipped as part of a Yocto Project release. 
             The team creates these repositories by
             compiling and executing the set of feature descriptions for every BSP/feature
             in the product. 
@@ -50,19 +52,25 @@
             </literallayout>
             For another example of how to set up a local Git repository of the Linux Yocto 
             kernel files, see the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted item in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>.
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted item in The Yocto Project Development Manual.
         </para>
         <para>  
-            Once the Git repository is set up on your local machine, you can switch to the 
-            <filename>meta</filename> branch within the repository.
-            Here, you can see a snapshot of all the kernel configuration and feature descriptions that are 
-            used to build the kernel repository.
+            Once you have cloned the kernel Git repository on your local machine, you can 
+            switch to the <filename>meta</filename> branch within the repository.
+            Here is an example that assumes the local Git repository for the kernel is in 
+            a top-level directory named <filename>linux-yocto-3.0</filename>:
+            <literallayout class='monospaced'>
+     $ cd ~/linux-yocto-3.0
+     $ git checkout -b meta origin/meta
+            </literallayout>
+            Once you have checked out and switched to the <filename>meta</filename> branch,
+            you can see a snapshot of all the kernel configuration and feature descriptions that are 
+            used to build that particular kernel repository.
             These descriptions are in the form of <filename>.scc</filename> files. 
         </para>
         <para>
-            You should realize, however, that browsing your local snapshot of feature
-            descriptions and patches is not an effective way to determine what is in a
+            You should realize, however, that browsing your local kernel repository
+            for feature descriptions and patches is not an effective way to determine what is in a
             particular kernel branch. 
             Instead, you should use Git directly to discover the changes in a branch.
             Using Git is an efficient and flexible way to inspect changes to the kernel.  
@@ -76,10 +84,12 @@
             </note>
         </para>
         <para>
-            The following steps describe what happens when the Yocto kernel team constructs
-            the kernel tree given the introduction of a new top-level kernel feature or BSP. 
-            These are the actions that effectively create the tree that includes the new feature, patch, 
-            or BSP:
+            The following steps describe what happens when the Yocto Project Team constructs
+            the Yocto Linux kernel source Git repository (or tree) found at 
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> given the 
+            introduction of a new top-level kernel feature or BSP. 
+            These are the actions that effectively create the tree 
+            that includes the new feature, patch or BSP:
             <orderedlist>
                 <listitem><para>A top-level kernel feature is passed to the kernel build subsystem.
                     Normally, this feature is a BSP for a particular kernel type.</para></listitem>
@@ -126,10 +136,11 @@
                 Any add-ons and configuration data are applied to the end of an existing branch. 
                 The full repository generation that is found in the 
                 official Yocto Project kernel repositories at
-                <ulink url='http://git.yoctoproject.org/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>
                 is the combination of all supported boards and configurations.</para>
                 <para>The technique the Yocto Project team uses is flexible and allows for seamless 
-                blending of an immutable history with additional deployment specific patches. 
+                blending of an immutable history with additional patches specific to a 
+                deployment. 
                 Any additions to the kernel become an integrated part of the branches.</para>
             </note>
         </para>
@@ -226,10 +237,8 @@
             You can find Git documentation at 
             <ulink url='http://git-scm.com/documentation'></ulink>.
             You can find a simple overview of using Git with the Yocto Project in the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
-            section of  
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto 
-            Project Development Manual</ulink>.
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
+            section of The Yocto Project Development Manual.
         </para>
 
         <section id='change-inspection-kernel-changes-commits'>
@@ -244,8 +253,8 @@
                 In projects that have a collection of directories that
                 contain patches to the kernel, it is possible to inspect or "grep" the contents 
                 of the directories to get a general feel for the changes. 
-                This sort of patch inspection is not an efficient way to determine what has been done to the
-                kernel.
+                This sort of patch inspection is not an efficient way to determine what has been 
+                done to the kernel.
                 The reason it is inefficient is because there are many optional patches that are 
                 selected based on the kernel type and the feature description.
                 Additionally, patches could exist in directories that are not included in the search.
@@ -299,9 +308,11 @@
                 <title>Show a Particular Feature or Branch Change</title>
 
                 <para>
-                    Significant features or branches are tagged in the Yocto Project tree to divide
-                    changes. 
-                    Remember to first determine (or add) the tag of interest.  
+                    Developers use tags in the Yocto Project tree to divide changes for significant 
+                    features or branches. 
+                    Once you know a particular tag, you can use Git commands 
+                    to show changes associated with the tag and find the branches that contain
+                    the feature.  
                     <note>
                         Because BSP branch, <filename>kernel.org</filename>, and feature tags are all 
                         present, there could be many tags.
@@ -354,10 +365,10 @@
                 The Yocto Project provides scripts that help you work in a collaborative development 
                 environment.  
                 For information on these scripts, see the
-                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#pushing-a-change-upstream'>Pushing a Change Upstream and Requesting a Pull</ulink>" and   
-                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#submitting-a-patch'>Submitting a Patch Through Email</ulink>" sections in    
-                <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
-                Yocto Project Development Manual</ulink>".
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream'>Pushing a Change 
+                Upstream and Requesting a Pull</ulink>" and   
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-patch'>Submitting a Patch Through 
+                Email</ulink>" sections in The Yocto Project Development Manual.
             </para>
 
             <para>
@@ -623,8 +634,6 @@
                         community standards for submitting and documenting changes and follow their best practices.  
                         For example, kernel patches should follow standards such as:
                         <itemizedlist>
-                            <listitem><para>
-                                <ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem>
                             <listitem><para>
                                 <ulink url='http://linux.yyz.us/patch-format.html'></ulink></para></listitem>
                             <listitem><para>Documentation/SubmittingPatches (in any linux 
@@ -637,9 +646,8 @@
                     The messages used to commit changes are a large part of these standards.
                     Consequently, be sure that the headers for each commit have the required information.
                     For information on how to follow the Yocto Project commit message standards, see the
-                    "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#how-to-submit-a-change'>How to Submit a Change</ulink>" section in  
-                    <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
-                    Yocto Project Development Manual</ulink>".
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a 
+                    Change</ulink>" section in The Yocto Project Development Manual.
                 </para>
 
                 <para>
@@ -741,7 +749,8 @@
                 </para>
 
                 <para>
-                    The following commands illustrate how you can condense and merge two BSPs into a second SCM:
+                    The following commands illustrate how you can condense and merge two BSPs into a 
+                    second SCM:
                     <literallayout class='monospaced'>
      &gt; git checkout yocto/standard/common-pc/base
      &gt; git merge yocto/standard/common-pc-64/base
@@ -772,10 +781,9 @@
                 existing similar BSP.
                 The information is introductory in nature and does not provide step-by-step examples. 
                 For detailed information on how to create a BSP given an existing similar BSP, see
-                the "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>BSP Development Example</ulink>" appendix in  
-                <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
-                Yocto Project Development Manual</ulink>, or see the 
-                <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>Transcript:_creating_one_generic_Atom_BSP_from_another</ulink>
+                the "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>BSP Development 
+                Example</ulink>" appendix in the Yocto Project Development Manual, or see the 
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>Transcript:_creating_one_generic_Atom_BSP_from_another</ulink>
                 wiki page.
             </para>
 
@@ -792,7 +800,7 @@
                         your BSP easier.  
                         You can find all the BSPs that are supported and ship with the Yocto Project 
                         on the Yocto Project's Download page at 
-                        <ulink url='http://www.yoctoproject.org/download'></ulink>.</para></listitem>
+                        <ulink url='&YOCTO_HOME_URL;/download'></ulink>.</para></listitem>
                     <listitem><para><emphasis>Be sure you have the Base BSP:</emphasis>
                         You need to either have the Yocto Project Git repository set up or download
                         the tarball of the base BSP.

documentation/kernel-manual/kernel-manual.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='kernel-manual' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -53,10 +54,15 @@
                 <date>15 March 2012</date>
                 <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2010-2012</year>
+      <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -68,9 +74,9 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and 
-          <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
+          <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
           The Yocto Project Kernel Architecture and Use Manual</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>

documentation/kernel-manual/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -946,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -958,11 +958,26 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

documentation/poky-ref-manual/development.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id="platdev">
 <title>Platform Development with the Yocto Project</title>
@@ -82,7 +83,7 @@
             The current release of the Yocto Project no longer supports the Anjuta plug-in.
             However, the Poky Anjuta Plug-in is available to download directly from the Poky 
             Git repository located through the web interface at
-            <ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins.
+            <ulink url="&YOCTO_GIT_URL;"></ulink> under IDE Plugins.
             The community is free to continue supporting it beyond the Yocto Project 0.9
             Release.            
         </note>
@@ -91,10 +92,8 @@
             with other plug-ins installed into the Eclipse IDE.
             Once you have your environment setup you need to configure the Eclipse plug-in.
             For information on how to install and configure the Eclipse plug-in, see the
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#adt-eclipse'>
-            "Working Within Eclipse"</ulink> chapter in the 
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
-            "Application Development Toolkit (ADT) User's Guide."</ulink>
+            "<ulink url='&YOCTO_DOCS_ADT_URL;#adt-eclipse'>Working Within Eclipse</ulink>" chapter in the 
+            Yocto Project Application Development Toolkit (ADT) User's Guide.
          </para>
          </section>
 
@@ -102,8 +101,8 @@
         <title>External Development Using the QEMU Emulator</title>
         <para>
             Running Poky QEMU images is covered in the 
-            <ulink url="http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html">
-            Yocto Project Quick Start</ulink> in the "A Quick Test Run" section.
+            "<ulink url='&YOCTO_DOCS_ADT_URL;#test-run'>A Quick Test Run</ulink>" section of
+            the Yocto Project Quick Start.
         </para>
         <para>
             The QEMU images shipped with the Yocto Project contain complete toolchains
@@ -162,8 +161,8 @@
         <para>
             Working directly with the Yocto Project is a fast and effective development technique.
             The idea is that you can directly edit files in a working directory
-            (<glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>) 
-            or the source directory (<glossterm><link linkend='var-S'>S</link></glossterm>) 
+            (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>) 
+            or the source directory (<filename><link linkend='var-S'>S</link></filename>) 
             and then force specific tasks to rerun in order to test the changes. 
             An example session working on the matchbox-desktop package might 
             look like this:
@@ -203,16 +202,16 @@
         <para>
             It is useful when making changes directly to the work directory files to do
             so using the Quilt tool as detailed in the 
-            <link linkend='usingpoky-modifying-packages-quilt'> 
-            Modifying Package Source Code with Quilt</link> section. 
+            "<link linkend='usingpoky-modifying-packages-quilt'>Modifying Package Source Code with Quilt</link>"
+             section. 
             Using Quilt, you can copy patches into the recipe directory and use the patches directly 
-            through use of the <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable.
+            through use of the <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> variable.
         </para>
 
         <para>
             For a review of the skills used in this section, see the 
-            <link linkend="usingpoky-components-bitbake">BitBake</link> and 
-            <link linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> sections
+            "<link linkend="usingpoky-components-bitbake">BitBake</link>" and 
+            "<link linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link>" sections
             in this manual.
         </para>
         </section>
@@ -231,7 +230,7 @@
             still defined so you can use commands such as <filename>configure</filename> and 
             <filename>make</filename>. 
             The commands execute just as if the Yocto Project build system were executing them. 
-            Consequently, workng this way can be helpful when debugging a build or preparing 
+            Consequently, working this way can be helpful when debugging a build or preparing 
             software to be used with the Yocto Project build system.
         </para>
 
@@ -262,7 +261,7 @@
             or <filename>compile</filename> commands as if they were being run by 
             the Yocto Project build system itself.
             As noted earlier, the working directory also automatically changes to the 
-            source directory (<glossterm><link linkend='var-S'>S</link></glossterm>).
+            source directory (<filename><link linkend='var-S'>S</link></filename>).
         </para>
 
         <para> 
@@ -272,8 +271,8 @@
         <para>
             The default shell used by <filename>devshell</filename> is xterm. 
             You can use other terminal forms by setting the 
-            <glossterm><link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and 
-            <glossterm><link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables 
+            <filename><link linkend='var-TERMCMD'>TERMCMD</link></filename> and 
+            <filename><link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></filename> variables 
             in the Yocto Project's <filename>local.conf</filename> file found in the build
             directory. 
             For examples of the other options available, see the "UI/Interaction Configuration"
@@ -284,7 +283,7 @@
 
         <para>
             Because an external shell is launched rather than opening directly into the 
-            original terminal window, it allows easier interaction with Bitbake's multiple 
+            original terminal window, it allows easier interaction with BitBake's multiple
             threads as well as accomodates a future client/server split.
         </para>
 
@@ -294,7 +293,7 @@
             instead of just using <filename>gcc</filename>.
             The same applies to other applications such as <filename>binutils</filename>, 
             <filename>libtool</filename> and so forth.
-            The Yocto Project has setup environment variables such as <filename>CC</filename>
+            BitBake sets up environment variables such as <filename>CC</filename>
             to assist applications, such as <filename>make</filename> to find the correct tools.</para>
             <para>It is also worth noting that <filename>devshell</filename> still works over
             X11 forwarding and similar situations</para>
@@ -333,7 +332,7 @@
         It also allows you to perform post-mortem style analysis of program crashes. 
         GDB is available as a package within the Yocto Project and by default is 
         installed in sdk images.
-        See <xref linkend='ref-images'>Reference: Images</xref> for a description of these
+        See the "<link linkend='ref-images'>Reference: Images</link>" appendix for a description of these
         images. 
         You can find information on GDB at <ulink url="http://sourceware.org/gdb/"/>.
     </para>
@@ -671,7 +670,7 @@
         <para>
             A graphical user interface for OProfile is also available. 
             You can download and build this interface from the Yocto Project at
-            <ulink url="http://git.yoctoproject.org/cgit.cgi/oprofileui/"></ulink>. 
+            <ulink url="&YOCTO_GIT_URL;/cgit.cgi/oprofileui/"></ulink>. 
             If the "tools-profile" image feature is selected, all necessary binaries
             are installed onto the target device for OProfileUI interaction.
         </para>
@@ -679,7 +678,7 @@
         <para>
             Even though the Yocto Project usually includes all needed patches on the target device, you 
             might find you need other OProfile patches for recent OProfileUI features.
-            If so, see the <ulink url='http://git.yoctoproject.org/cgit.cgi/oprofileui/tree/README'>
+            If so, see the <ulink url='&YOCTO_GIT_URL;/cgit.cgi/oprofileui/tree/README'>
             OProfileUI README</ulink> for the most recent information.
         </para>
 
@@ -765,8 +764,8 @@
                 is not always necessary to actually have them on the device for OProfile use. 
                 All that is needed is a copy of the filesystem with the debug symbols present 
                 on the viewer system. 
-                The <link linkend='platdev-gdb-remotedebug-launch-gdb'>Launching GDB
-                on the Host Computer</link> section covers how to create such a directory with 
+                The "<link linkend='platdev-gdb-remotedebug-launch-gdb'>Launching GDB on the Host Computer</link>"
+                section covers how to create such a directory with 
                 the Yocto Project and how to use the OProfileUI Settings dialog to specify the location.
                 If you specify the directory, it will be used when the file checksums 
                 match those on the system you are profiling.

documentation/poky-ref-manual/extendpoky.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='extendpoky'>
 
@@ -24,7 +25,7 @@
             variables.
             For information on variables that are useful for recipes and for information about recipe naming
             issues, see the 
-            <link linkend='ref-varlocality-recipe-required'>Required</link> section for recipe variables.
+            "<link linkend='ref-varlocality-recipe-required'>Required</link>" section for recipe variables.
         </para>
 
         <para>
@@ -114,7 +115,7 @@
             <para>
                 The variable <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link>
                 </filename> is used to track source license changes as described in the
-                <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</link>
+                "<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</link>"
                 section. 
                 You can quickly create Autotool-based recipes in a manner similar to the previous example.
             </para>
@@ -532,10 +533,9 @@
         <para>
             For a complete example that shows how to add a new machine to the Yocto Project, 
             see the 
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
+            <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>
             BSP Development Example</ulink> in Appendix A of  
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
-            The Yocto Project Development Manual</ulink>.
+            The Yocto Project Development Manual.
         </para>
 
         <section id="platdev-newmachine-conffile">
@@ -786,7 +786,7 @@
         <para>
             This section overviews the Multilib process only. 
             For more details on how to implement Multilib, see the 
-            <ulink url='https://wiki.yoctoproject.org/wiki/Multilib'>Multilib</ulink> wiki 
+            <ulink url='&YOCTO_WIKI_URL;/wiki/Multilib'>Multilib</ulink> wiki 
             page.
         </para>
 
@@ -1076,7 +1076,7 @@
         </para>
 
         <para>
-            The Yocto Project supports a <link linkend='usingpoky-changes-layers'>"layers"</link> concept.
+            The Yocto Project supports a "<link linkend='usingpoky-changes-layers'>layers</link>" concept.
             If you use layers properly, you can ease future upgrades and allow segregation
             between the Yocto Project core and a given developer's changes. 
             The following section provides more advice on managing changes to the Yocto Project.
@@ -1321,7 +1321,7 @@
                 Experience shows that buildbot is a good fit for this role. 
                 What works well is to configure buildbot to make two types of builds:
                 incremental and full (from scratch).  
-                See <ulink url='http://www.yoctoproject.org:8010'>the buildbot for the 
+                See <ulink url='&YOCTO_AB_URL;:8010'>the buildbot for the 
                 Yocto Project</ulink> for an example implementation that uses buildbot.
             </para>
 

documentation/poky-ref-manual/faq.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='faq'>
 <title>FAQ</title>
@@ -7,13 +8,13 @@
     <qandaentry>
         <question>
             <para>
-                How does Poky differ from <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>?
+                How does Poky differ from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>?
             </para>
         </question>
         <answer>
             <para>
                 Poky is the Yocto Project build system that was derived from <ulink 
-                url='http://www.openembedded.org/'>OpenEmbedded</ulink>.
+                url='&OE_HOME_URL;'>OpenEmbedded</ulink>.
                 Poky is a stable, smaller subset focused on the mobile environment. 
                 Development in the Yocto Project using Poky is closely tied to OpenEmbedded with 
                 features being merged regularly between the two for mutual benefit.
@@ -33,8 +34,8 @@
                 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:
                 <itemizedlist>
-                    <listitem><para><ulink url='http://downloads.yoctoproject.org/releases/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-i686.tar.bz2'>32-bit tarball</ulink></para></listitem>
-                    <listitem><para><ulink url='http://downloads.yoctoproject.org/releases/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-x86_64.tar.bz2'>64-bit tarball</ulink></para></listitem>
+                    <listitem><para><ulink url='&YOCTO_PYTHON-i686_DL_URL;'>32-bit tarball</ulink></para></listitem>
+                    <listitem><para><ulink url='&YOCTO_PYTHON-x86_64_DL_URL;'>64-bit tarball</ulink></para></listitem>
                 </itemizedlist>
             </para>
             <para>
@@ -139,7 +140,7 @@
             <para>
                 To add a package, you need to create a BitBake recipe.
                 For information on how to add a package, see the 
-                <link linkend='usingpoky-extend-addpkg'>Adding a Package</link> section
+                "<link linkend='usingpoky-extend-addpkg'>Adding a Package</link>" section
                 earlier in this manual.
             </para>
         </answer>
@@ -171,7 +172,7 @@
         </question>
         <answer>
             <para>
-                <ulink url='http://www.gnome.org/mobile/'>GNOME Mobile</ulink> is a subset of the GNOME 
+                GNOME Mobile is a subset of the <ulink url='http://www.gnome.org'>GNOME</ulink> 
                 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, 
@@ -385,9 +386,9 @@
         </question>
         <answer>
             <para>
-                You need to create a form factor file as described in 
-                <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref>
-                and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one as follows:
+                You need to create a form factor file as described in the
+                "<link linkend='bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</link>"
+                section and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one as follows:
                 <literallayout class='monospaced'>
      HAVE_TOUCHSCREEN=1
                 </literallayout>
@@ -407,8 +408,8 @@
                 automatically bring up network interfaces. 
                 Therefore, you will need to add a BSP-specific netbase that includes an interfaces 
                 file.
-                See <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref>
-                for information on creating these types of miscellaneous recipe files.
+                See the "<link linkend='bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</link>"
+                section for information on creating these types of miscellaneous recipe files.
             </para>
             <para>
                 For example, add the following files to your layer:
@@ -493,8 +494,8 @@
 
     <qandaentry>
         <question>
-            <para>
-                How does the Yocto Project obtain source code and will it work behind my 
+            <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
+                How does the Yocto Project build system obtain source code and will it work behind my 
                 firewall or proxy server?
             </para>
         </question>
@@ -573,7 +574,7 @@
                  any network accesses to anything other than the PREMIRROR would fail.
              </para>
              <para>
-                 Poky also honors the standard environment variables 
+                 Poky also honors the standard shell environment variables 
                  <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, 
                  <filename>https_proxy</filename>, and <filename>all_proxy</filename>
                  to redirect requests through proxy servers.

documentation/poky-ref-manual/introduction.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='intro'>
 <title>Introduction</title>
@@ -15,13 +16,13 @@
         construct complete Linux images.
         You can find complete introductory and getting started information on the Yocto Project
         by reading the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>   
+        <ulink url='&YOCTO_DOCS_QS_URL;'>   
         Yocto Project Quick Start</ulink>.
         For task-based information using the Yocto Project, see 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html'>
+        <ulink url='&YOCTO_DOCS_DEV_URL;'>
         The Yocto Project Development Manual</ulink>.
         You can also find lots of information on the Yocto Project on the 
-        <ulink url="http://www.yoctoproject.org">Yocto Project website</ulink>.
+        <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>.
     </para>
 </section>
 
@@ -97,11 +98,9 @@
 <section id='intro-requirements'>
 <title>System Requirements</title>
     <para>
-        For system Yocto Project system requirements, see the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#resources'>
-        What You Need and How You Get It</ulink> section in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
-        Yocto Project Quick Start</ulink>.
+        For Yocto Project system requirements, see the
+        <ulink url='&YOCTO_DOCS_QS_URL;#resources'>
+        What You Need and How You Get It</ulink> section in the Yocto Project Quick Start.
     </para>
 </section>
 
@@ -112,14 +111,14 @@
         of methods:
         <itemizedlist>
             <listitem><para><emphasis>Releases:</emphasis> Stable, tested releases are available through 
-                <ulink url='http://downloads.yoctoproject.org/releases/yocto/'/>.</para></listitem>
+                <ulink url='&YOCTO_DL_URL;/releases/yocto/'/>.</para></listitem>
             <listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
                 <ulink url='http://autobuilder.yoctoproject.org/nightly'/>.  
                 These builds include Yocto Project releases, meta-toolchain tarballs, and 
                 experimental builds.</para></listitem>
             <listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases
                 of the Yocto Project and supported BSPs at the
-                <ulink url='http://www.yoctoproject.org'>Yocto Project website</ulink>.
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
                 Along with these downloads, you can find lots of other information at this site.  
                 </para></listitem>
         </itemizedlist>
@@ -132,11 +131,9 @@
         Development using the Yocto Project requires a local copy of the Yocto Project files. 
         You can get these files by downloading a Yocto Project release tarball and unpacking it,  
         or by establishing a Git repository of the files.
-        For information on both these methods, see
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-setup'>
-        Getting Setup</ulink> section in  
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
-        The Yocto Project Development Manual</ulink>.
+        For information on both these methods, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Setup</ulink>" 
+        section in The Yocto Project Development Manual.
     </para>
 </section>
 

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

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='poky-ref-manual' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -67,10 +68,15 @@
                 <date>15 March 2012</date>
                 <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2007-2012</year>
+      <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -82,9 +88,9 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and 
-          <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
+          <ulink url='&YOCTO_DOCS_REF_URL;'>
           The Yocto Project Reference Manual</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-bitbake'>
 
@@ -35,7 +36,7 @@
             The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
             The Yocto Project keeps this file in the Yocto Project file's <filename>meta/conf/</filename>
             directory.
-            BitBake finds it by examining the <filename>BBPATH</filename> environment 
+            BitBake finds it by examining its <filename>BBPATH</filename> environment 
             variable and looking for the <filename>meta/conf/</filename> 
             directory.
         </para>
@@ -53,7 +54,7 @@
             and the machine configuration file 
             (set by the 
             <filename><link linkend='var-MACHINE'>MACHINE</link></filename> variable).  
-            The <filename>DISTRO</filename> and <filename>MACHINE</filename> environment 
+            The <filename>DISTRO</filename> and <filename>MACHINE</filename> BitBake environment 
             variables are both usually set in 
             the <filename>local.conf</filename> file. 
             Valid distribution 
@@ -86,7 +87,7 @@
             <filename>meta/recipes-*/</filename> directory within Poky. 
             Adding extra content to <filename>BBFILES</filename> is best achieved through the use of 
             BitBake layers as described in the 
-            <link linkend='usingpoky-changes-layers'>BitBake Layers</link> section.
+            "<link linkend='usingpoky-changes-layers'>BitBake Layers</link>" section.
         </para>
 
         <para>
@@ -207,17 +208,16 @@
             It is worth noting that you can greatly speed up the build time by properly setting 
             the <filename>BB_NUMBER_THREADS</filename> variable.  
             See the
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
-            Building an Image</ulink> section in the 
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
-            Yocto Project Quick Start</ulink> for more information.
+            "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+            section in the Yocto Project Quick Start for more information.
         </para>
 
         <para>
             As each task completes, a timestamp is written to the directory specified by the 
             <filename><link linkend='var-STAMPS'>STAMPS</link></filename> variable (usually 
             <filename>build/tmp/stamps/*/</filename>). 
-            On subsequent runs, BitBake looks at the <filename>STAMPS</filename> directory and does not rerun 
+            On subsequent runs, BitBake looks at the <filename>/build/tmp/stamps</filename>
+            directory and does not rerun
             tasks that are already completed unless a timestamp is found to be invalid. 
             Currently, invalid timestamps are only considered on a per 
             <filename>.bb</filename> file basis.
@@ -301,7 +301,7 @@
             variable so that the shared state code ignores the dependency when it creates
             checksums.
             For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename>
-            example in <xref linkend='checksums'>Checksums (Signatures)</xref>.
+            example in the "<link linkend='checksums'>Checksums (Signatures)</link>" section.
         </note>
     </section>
 
@@ -401,8 +401,8 @@ Options:
             This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename> 
             variable. 
             See the 
-            <link linkend='platdev-appdev-srcrev'>Development Within Yocto Project for a Package that Uses 
-            an External SCM</link> section for more information.
+            "<link linkend='platdev-appdev-srcrev'>Development Within Yocto Project for a Package that Uses 
+            an External SCM</link>" section for more information.
         </para>
 
     </section>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-classes'>
 <title>Reference: Classes</title>
@@ -49,7 +50,7 @@
         This class defines a set of tasks (configure, compile etc.) that 
         work for all Autotooled packages.  
         It should usually be enough to define a few standard variables as documented in the 
-        <link linkend='usingpoky-extend-addpkg-autotools'>Autotooled Package</link> section 
+        "<link linkend='usingpoky-extend-addpkg-autotools'>Autotooled Package</link>" section 
         and then simply <filename>inherit autotools</filename>. 
         This class can also work with software that emulates Autotools.
     </para>
@@ -139,7 +140,7 @@
     </para>
 
     <para>
-        During staging, Bitbake installs such scripts into the 
+        During staging, BitBake installs such scripts into the
         <filename>sysroots/</filename> directory. 
         BitBake also changes all paths to point into the <filename>sysroots/</filename>
         directory so all builds that use the script will use the correct 
@@ -166,7 +167,7 @@
     </para>
 
     <para>
-        During staging, Bitbake installs <filename>pkg-config</filename> data into the 
+        During staging, BitBake installs <filename>pkg-config</filename> data into the
         <filename>sysroots/</filename> directory. 
         By making use of sysroot functionality within <filename>pkg-config</filename>,
         this class no longer has to manipulate the files.
@@ -252,8 +253,8 @@
     <para>
         This class adds the <filename>devshell</filename> task. 
         Distribution policy dictates whether to include this class as the Yocto Project does.
-        See the <link 
-        linkend='platdev-appdev-devshell'>Development Within a Development Shell</link> section 
+        See the 
+        "<link linkend='platdev-appdev-devshell'>Development Within a Development Shell</link>" section 
         for more information about using devshell.
     </para>
 </section>
@@ -313,9 +314,9 @@
         You can find additional information on the effects of the package class at these 
         two Yocto Project mailing list links:
         <itemizedlist>
-            <listitem><para><ulink url='https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html'>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006362.html'>
                 https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html</ulink></para></listitem>
-            <listitem><para><ulink url='https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html'>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006363.html'>
                 https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html</ulink></para></listitem>
         </itemizedlist>
     </para>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-features'>
     <title>Reference: Features</title>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-images'>
     <title>Reference: Images</title>
@@ -45,7 +46,10 @@
         <listitem><para><emphasis><filename>core-image-minimal</filename>:</emphasis>
             A small image just capable of allowing a device to boot.</para></listitem>
         <listitem><para><emphasis><filename>core-image-minimal-dev</filename>:</emphasis>
-            A <filename>core-image-minimal</filename> image suitable for development work.
+            A <filename>core-image-minimal</filename> image suitable for development work
+            using the host.
+            The image includes headers and libraries you can use in a host development 
+            environment.
             </para></listitem>
         <listitem><para><emphasis><filename>core-image-minimal-initramfs</filename>:</emphasis>
             A <filename>core-image-minimal</filename> image that has the Minimal RAM-based 
@@ -64,13 +68,17 @@
             A <filename>core-image-basic</filename> image suitable for implementations 
             that conform to Linux Standard Base (LSB).</para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb-dev</filename>:</emphasis>
-            A <filename>core-image-lsb</filename> image that is suitable for development work.
+            A <filename>core-image-lsb</filename> image that is suitable for development work
+            using the host.
+            The image includes headers and libraries you can use in a host development 
+            environment.
             </para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb-sdk</filename>:</emphasis>
             A <filename>core-image-lsb</filename> that includes everything in meta-toolchain 
-            but also includes development headers and libraries to form a complete standalone SDK. 
-            See the <link linkend='platdev-appdev-external-sdk'> 
-            External Development Using the Poky SDK</link> section for more information.
+            but also includes development headers and libraries to form a complete standalone SDK.
+            This image is suitable for development using the target. 
+            See the "<link linkend='platdev-appdev-external-sdk'> 
+            External Development Using the Poky SDK</link>" section for more information.
             </para></listitem>
         <listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis>
             An image with support for the Open GL-based toolkit Clutter, which enables development of 
@@ -81,16 +89,17 @@
             The image supports X11 with a Sato theme and Pimlico applications and also  
             contains terminal, editor, and file manager.</para></listitem>
         <listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
-            A <filename>core-image-sato</filename> image suitable for development
-            that also includes a native toolchain and libraries needed to build applications on 
-            the device itself. 
-            The image also includes testing and profiling tools as well as debug symbols.  
+            A <filename>core-image-sato</filename> 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 <filename>core-image-sdk</filename>.</para></listitem>
         <listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis>
             A <filename>core-image-sato</filename> image that includes everything in meta-toolchain. 
-            The image also includes development headers and libraries to form a complete standalone SDK. 
-            See the <link linkend='platdev-appdev-external-sdk'> 
-            External Development Using the Poky SDK</link> section for more information.
+            The image also includes development headers and libraries to form a complete standalone SDK
+            and is suitable for development using the target. 
+            See the "<link linkend='platdev-appdev-external-sdk'> 
+            External Development Using the Poky SDK</link>" section for more information.
             </para></listitem>
     </itemizedlist>
 

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-structure'>
 
@@ -14,10 +15,8 @@
 
 <para>
     For information on how to establish the Yocto Project files on your local development system, see the
-    <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-started'> 
-    Getting Setup</ulink> section in the 
-    <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
-    The Yocto Project Development Manual</ulink>.
+    "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
+    section in the Yocto Project Development Manual.
 </para>
 
 <section id='structure-core'>
@@ -35,7 +34,7 @@
             from BitBake itself.
             Consequently, most users do not need to worry about BitBake.
             The <filename>bitbake/bin/</filename> directory is placed 
-            into the <filename>PATH</filename> environment variable by the 
+            into the shell's <filename>PATH</filename> environment variable by the 
             <link linkend="structure-core-script">oe-init-build-env</link> script.
         </para>
 
@@ -121,7 +120,7 @@
             This directory contains various integration scripts that implement 
             extra functionality in the Yocto Project environment (e.g. QEMU scripts).
             The <link linkend="structure-core-script">oe-init-build-env</link> script appends this
-            directory to the <filename>PATH</filename> environment variable.
+            directory to the shell's <filename>PATH</filename> environment variable.
         </para>
 
         <para>
@@ -363,7 +362,7 @@
 
         <para>
             This directory contains intermediate packaging data that is used later in the packaging process. 
-            For more information, see <link linkend='ref-classes-package'>package.bbclass</link>.
+            For more information, see the "<link linkend='ref-classes-package'>Packaging - package*.bbclass</link>" section.
         </para>
     </section>
 
@@ -388,8 +387,8 @@
             referred to as <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, is created.  
             Within this directory, the source is unpacked to 
             <filename>linux-qemux86-standard-build</filename> and then patched by Quilt 
-            (see the <link linkend="usingpoky-modifying-packages-quilt">Modifying Package Source Code
-            With Quilt</link> section).   
+            (see the "<link linkend="usingpoky-modifying-packages-quilt">Modifying Package Source Code
+            With Quilt</link>" section).   
             Within the <filename>linux-qemux86-standard-build</filename> directory, 
             standard Quilt directories <filename>linux-3.0/patches</filename>
             and <filename>linux-3.0/.pc</filename> are created,
@@ -480,8 +479,8 @@
         <title><filename>meta/recipes-bsp/</filename></title>
 
         <para>
-            This directory contains anything linking to specific hardware or hardware configuration information
-            such as "u-boot" and "grub".
+            This directory contains anything linking to specific hardware or hardware 
+            configuration information such as "u-boot" and "grub".
         </para>
     </section>
 

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <!-- Dummy chapter -->
 <appendix id='ref-variables-glos'>
@@ -75,7 +76,7 @@
         <glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
             <glossdef>
                 <para>The maximum number of tasks BitBake should run in parallel at any one time.
-                    If your host development system supports mulitiple cores a good rule of thumb
+                    If your host development system supports multiple cores, a good rule of thumb
                     is to set this variable to twice the number of cores.</para>
             </glossdef>
         </glossentry>
@@ -306,8 +307,8 @@
         <glossentry id='var-DISTRO_PN_ALIAS'><glossterm>DISTRO_PN_ALIAS</glossterm>
             <glossdef>
                 <para>Alias names used for the recipe in various Linux distributions.</para>
-                <para>See <link linkend='usingpoky-configuring-DISTRO_PN_ALIAS'>
-                    Handling a Package Name Alias</link> section for more information.</para>
+                <para>See "<link linkend='usingpoky-configuring-DISTRO_PN_ALIAS'>
+                    Handling a Package Name Alias</link>" section for more information.</para>
             </glossdef>
         </glossentry>
 
@@ -446,7 +447,7 @@
                     The options to pass in 
                     <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>
                     and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename>
-                    when compiling an optimised system.
+                    when compiling an optimized system.
                     This variable defaults to 
                     "-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2".
                 </para>
@@ -476,7 +477,7 @@
                 Typically, you configure this variable in image recipes.
                 Note that you can add extra features to the image by using the
                 <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable.
-                See the <link linkend="ref-features-image">Reference: Images</link> section for the 
+                See the "<link linkend="ref-features-image">Reference: Images</link>" section for the 
                 list of features present in images built by the Yocto Project.</para>
             </glossdef>
         </glossentry>
@@ -678,8 +679,8 @@
                     This variable must be defined for all recipes (unless <filename>LICENSE</filename>
                     is set to "CLOSED")</para>
                 <para>For more information, see the
-                    <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
-                    Track License Change</link> section</para>
+                    "<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</link>" 
+                    section</para>
             </glossdef>
         </glossentry>
 
@@ -707,7 +708,7 @@
                 </para>
                 <para>
                     This variable is similar to the 
-                    <link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link>
+                    <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename>
                     variable with the exception that the package 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.
@@ -737,7 +738,7 @@
                 </para>
                 <para>
                     This variable is similar to the 
-                    <link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link>
+                    <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link></filename>
                     variable with the exception that the package 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.
@@ -785,7 +786,7 @@
                 </para>
                 <para>
                     This variable is similar to the 
-                    <link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link>
+                    <filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link></filename>
                     variable with the exception that the package 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.
@@ -822,7 +823,7 @@
                 </para>
                 <para>
                     This variable is similar to the 
-                    <link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link>
+                    <filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link></filename>
                     variable with the exception that the package 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.
@@ -848,7 +849,7 @@
          <glossentry id='var-MACHINE_FEATURES'><glossterm>MACHINE_FEATURES</glossterm>
             <glossdef>
                 <para>Specifies the list of device features.
-                    See the <link linkend='ref-features-machine'>Machine</link> section for 
+                    See the "<link linkend='ref-features-machine'>Machine</link>" section for 
                     more information.</para>
             </glossdef>
          </glossentry>
@@ -886,7 +887,7 @@
                     </literallayout>
                     For information on build performance effects as a result of the 
                     package manager use, see
-                    <link linkend='ref-classes-package'>Packaging - <filename>package*.bbclass</filename></link>
+                    "<link linkend='ref-classes-package'>Packaging - <filename>package*.bbclass</filename></link>"
                     in this manual.
                 </para>
             </glossdef>
@@ -932,7 +933,7 @@
                     This variable is usually in the form <filename>-j 4</filename>, 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 one and a half times the number of cores on the host.</para>
+                    this variable to twice the number of cores on the host.</para>
             </glossdef>
         </glossentry>
 
@@ -1117,7 +1118,7 @@
                     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 
-                    <link linkend='var-RDEPENDS'>RDEPENDS</link> variable.
+                    <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variable.
                 </para>
                 <para>
                     The Yocto Project build process automatically installs the list of packages
@@ -1160,7 +1161,7 @@
                 <para>
                     The path to unpacked sources.
                     By default, this path is 
-                    "${<link linkend='var-WORKDIR'>WORKDIR</link>}/${<link linkend='var-PN'>PN</link>}-${<link linkend='var-PV'>PV</link>}".
+                    "<filename>${<link linkend='var-WORKDIR'>WORKDIR</link>}/${<link linkend='var-PN'>PN</link>}-${<link linkend='var-PV'>PV</link>}</filename>".
                 </para>
             </glossdef>
         </glossentry>
@@ -1242,7 +1243,7 @@
                     contains files that are machine-specific.
                     If so, the Yocto Project automatically changes 
                     <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>. 
-                    Setting this variable to "0" disables this behaviour.
+                    Setting this variable to "0" disables this behavior.
                 </para>
             </glossdef>
         </glossentry>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-varlocality'>
     <title>Reference: Variable Context</title>

documentation/poky-ref-manual/resources.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='resources'>
 <title>Contributing to the Yocto Project</title>
@@ -10,10 +11,8 @@
         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 <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-yp-release'>
-        Yocto Project Release</ulink> list item in
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto 
-        Project Development Manual</ulink>.
+        see the "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto Project Release</ulink>"
+        list item in the Yocto Project Development Manual.
     </para>
 </section>
 
@@ -22,7 +21,7 @@
 
     <para>
         If you find problems with the Yocto Project, you should report them using the 
-        Bugzilla application at <ulink url='http://bugzilla.yoctoproject.org/'></ulink>.
+        Bugzilla application at <ulink url='&YOCTO_BUGZILLA_URL;'></ulink>.
     </para>
 </section>
 
@@ -33,13 +32,13 @@
         To subscribe to the Yocto Project mailing lists, click on the following URLs and follow the instructions:
         <itemizedlist>
             <listitem><para><emphasis>
-                <ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink></emphasis>:
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink></emphasis>:
                 Use this list to receive offical Yocto Project announcements for developments and 
                 to learn about Yocto Project milestones.</para></listitem>
-            <listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink></emphasis>:
+            <listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink></emphasis>:
                 Use this list to monitor Yocto Project development discussions, ask questions, and 
                 get help.</para></listitem>
-            <listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink></emphasis>:
+            <listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink></emphasis>:
                 Use this list to monitor discussions about the Yocto Project build system Poky, 
                 ask questions, and get help.</para></listitem>
         </itemizedlist>
@@ -50,7 +49,7 @@
     <title>Internet Relay Chat (IRC)</title>
 
     <para>
-        Two IRC channels on freenode are available for Yocto Project and Poky discussions:
+        Two IRC channels on freenode are available for the Yocto Project and Poky discussions:
         <itemizedlist>
             <listitem><para><filename>#yocto</filename></para></listitem>
             <listitem><para><filename>#poky</filename></para></listitem>
@@ -64,19 +63,19 @@
     <para>
         Following is a list of resources you will find helpful:
         <itemizedlist>
-            <listitem><para><emphasis><ulink url='http://yoctoproject.org'>The Yocto Project website</ulink>:
+            <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
                 </emphasis> The home site for the Yocto Project.</para></listitem>
-            <listitem><para><emphasis><ulink url='http://www.openedhand.com/'>OpenedHand</ulink>:</emphasis>
+            <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
                 The company where the Yocto Project build system Poky was first developed.
                 OpenedHand has since been acquired by Intel Corporation.</para></listitem>
             <listitem><para><emphasis><ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
                 The company who acquired OpenedHand in 2008 and continues development on the 
                 Yocto Project.</para></listitem>
-            <listitem><para><emphasis><ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>:</emphasis>
+            <listitem><para><emphasis><ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
                 The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
                 from and to which it contributes.</para></listitem>
             <listitem><para><emphasis><ulink url='http://developer.berlios.de/projects/bitbake/'>
-                Bitbake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
+                BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
             <listitem><para><emphasis><ulink url='http://bitbake.berlios.de/manual/'>
                 BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.
                 </para></listitem>
@@ -96,11 +95,9 @@
         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
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#how-to-submit-a-change'>
-        How to Submit a Change</ulink> in
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
-        The Yocto Project Development Manual</ulink>.
+        For information on how to do both, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
+        section in the Yocto Project Development Manual.
     </para>
 </section>
 

documentation/poky-ref-manual/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -946,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -958,11 +958,26 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

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

@@ -1,5 +1,7 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
 <chapter id='technical-details'>
 <title>Technical Details</title>
 
@@ -31,10 +33,8 @@
             Configuration data acts as the glue to bind everything together.</para></listitem>
     </itemizedlist>
         For more information on data, see the
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html#yocto-project-terms'>
-        Yocto Project Terms</ulink> section in 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html'>
-        The Yocto Project Development Manual</ulink>.
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-terms'>Yocto Project Terms</ulink>"
+        section in the Yocto Project Development Manual.
     </para>
 
     <para> 
@@ -45,8 +45,7 @@
     <para>
         Following are some brief details on these core components.
         For more detailed information on these components see the 
-        <link linkend='ref-structure'>'Reference: Directory Structure'</link>
-        appendix.
+        "<link linkend='ref-structure'>Reference: Directory Structure</link>" appendix.
     </para>
 
     <section id='usingpoky-components-bitbake'>
@@ -76,7 +75,7 @@
             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 
-            <link linkend='ref-bitbake-providers'>Preferences and Providers</link> section.
+            "<link linkend='ref-bitbake-providers'>Preferences and Providers</link>" section.
         </para>
 
         <para>
@@ -115,7 +114,7 @@
             The term "package" can also be used to describe recipes.
             However, since the same word is used for the packaged output from the Yocto 
             Project (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files), 
-            this document avoids using the term "package" when refering to recipes.
+            this document avoids using the term "package" when referring to recipes.
         </para>
     </section>
 
@@ -127,7 +126,7 @@
             between metadata files. 
             An example is the Autotools class, which contains
             common settings for any application that Autotools uses.
-            The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details
+            The "<link linkend='ref-classes'>Reference: Classes</link>" appendix provides details
             about common classes and how to use them.
         </para>
     </section>
@@ -163,7 +162,7 @@
         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 
-        rebuiding things that don't necessarily need rebuilt.
+        rebuilding things that don't necessarily need rebuilt.
     </para>
 
     <para>
@@ -239,7 +238,7 @@
             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 <filename>WORKDIR</filename>.
-            The simplistic approach for excluding the worknig directory is to set 
+            The simplistic approach for excluding the working directory is to set 
             <filename>WORKDIR</filename> to some fixed value and create the checksum
             for the "run" script. 
         </para>
@@ -299,77 +298,73 @@
 
         <para>
             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.
+            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.
         </para>
 
         <para>
-            While figuring out the dependencies and creating these checksums is good,
-            what does the Yocto Project build system do with the checksum information? 
-            The build system uses a signature handler that is responsible for 
-            processing the checksum information.
-            By default, there is a dummy "noop" signature handler enabled in BitBake.
-            This means that behaviour is unchanged from previous versions. 
-            OECore uses the "basic" signature handler through this setting in the
-            <filename>bitbake.conf</filename> file:
+            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:
             <literallayout class='monospaced'>
-     BB_SIGNATURE_HANDLER ?= "basic"
+  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"
             </literallayout>
-            Also within the BitBake configuration file, we can give BitBake
-            some extra information to help it handle this information.
-            The following statements effectively result in a list of global
-            variable dependency excludes - variables never included in 
-            any checksum:
-            <literallayout class='monospaced'>
-     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"
-     BB_HASHTASK_WHITELIST += "(.*-cross$|.*-native$|.*-cross-initial$| \
-         .*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"
-            </literallayout>
-            This example is actually where <filename>WORKDIR</filename>
-            is excluded since <filename>WORKDIR</filename> is constructed as a
-            path within <filename>TMPDIR</filename>, which is on the whitelist.
+            The previous example actually excludes 
+            <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+            since it is actually constructed as a path within 
+            <filename>TMPDIR</filename>, which is on 
+            the whitelist. 
         </para>
 
         <para>
-            The <filename>BB_HASHTASK_WHITELIST</filename> covers dependent tasks and 
-            excludes certain kinds of tasks from the dependency chains. 
-            The effect of the previous example is to isolate the native, target,
-            and cross-components.
-            So, for example, toolchain changes do not force a rebuild of the whole system.
+            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 <filename>meta/lib/oe/sstatesig.py</filename> 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 <filename>OE-Core</filename>
+            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. 
+            <filename>OE-Core</filename> uses the "OEBasic" signature handler by default
+            through this setting in the <filename>bitbake.conf</filename> file:
+            <literallayout class='monospaced'>
+  BB_SIGNATURE_HANDLER ?= "OEBasic"
+            </literallayout>
+            The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> 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 <link linkend='var-PR'><filename>PR</filename></link>
+            values and changes to metadata automatically ripple across the build. 
+            Currently, this behavior is not the default behavior for <filename>OE-Core</filename>
+            but is the default in <filename>poky</filename>.
         </para>
 
         <para>
-            The end result of the "basic" handler is to make some dependency and
-            hash information available to the build. 
-            This includes:
+            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:
             <literallayout class='monospaced'>
-     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
+  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
             </literallayout>
-            There is also a "basichash" <filename>BB_SIGNATURE_HANDLER</filename>,
-            which is the same as the basic 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 <filename>PR</filename>
-            values and changes to metadata automatically ripple across the build.
-            Currently, this behavior is not the default behavior.
-            However, it is likely that the Yocto Project team will go forward with this 
-            behavior in the future since all the functionality exists. 
-            The reason for the delay is the potential impact to the distribution feed 
-            creation as they need increasing <filename>PR</filename> fields
-            and the Yocto Project currently lacks a mechanism to automate incrementing 
-            this field.
         </para>
     </section>
 
@@ -431,7 +426,7 @@
             <literallayout class='monospaced'>
      do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
             </literallayout>
-            This method, as well as the following example, also works for mutliple directories.
+            This method, as well as the following example, also works for multiple directories.
             <literallayout class='monospaced'>
      do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
      do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
@@ -553,7 +548,7 @@
                 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 statments
+                For example, to invalidate package shared state files, change the comment statements
                 of <filename>do_package</filename> 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.
@@ -562,7 +557,7 @@
             <note>
                 For an example of a commit that makes a cosmetic change to invalidate 
                 a shared state, see this
-                <ulink url='http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
             </note>
         </section>                
     </section>

documentation/poky-ref-manual/usingpoky.xml

@@ -1,5 +1,7 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
 <chapter id='usingpoky'>
 <title>Using the Yocto Project</title>
 
@@ -15,10 +17,8 @@
     <para>
         You can find general information on how to build an image using the 
         Yocto Project in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
-        Building an Image</ulink> section of the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
-        Yocto Project Quick Start</ulink>.
+        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+        section of The Yocto Project Quick Start.
         This section provides a summary of the build process and provides information
         for less obvious aspects of the build process.
     </para>
@@ -60,14 +60,14 @@
             files.
             Or, the target can be the name of a recipe for a specific piece of software such as 
             <application>busybox</application>. 
-            For more details about the images Yocto Project supports, see the 
-            <link linkend="ref-images">'Reference: Images'</link> appendix.
+            For more details about the images the Yocto Project supports, see the 
+            "<link linkend="ref-images">Reference: Images</link>" appendix.
         </para>
 
         <note>
             Building an image without GNU Public License Version 3 (GPLv3) components is 
             only supported for minimal and base images.
-            See <link linkend='ref-images'>'Reference: Images'</link> for more information.
+            See the "<link linkend='ref-images'>Reference: Images</link>" appendix for more information.
         </note>
     </section>
 
@@ -93,10 +93,8 @@
         <filename class="directory">tmp/deploy/images</filename>. 
         For information on how to run pre-built images such as <filename>qemux86</filename> 
         and <filename>qemuarm</filename>, see the
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>
-        Using Pre-Built Binaries and QEMU</ulink> section in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
-        Yocto Project Quick Start</ulink>.
+        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+        section in the Yocto Project Quick Start.
         For information about how to install these images, see the documentation for your
         particular board/machine.
     </para>
@@ -181,7 +179,7 @@
             You can view a list of tasks in a given package by running the
             <filename>listtasks</filename> task as follows:
             <literallayout class='monospaced'>
-     $ bitbake matchbox-desktop -c
+     $ bitbake matchbox-desktop -c listtasks
             </literallayout>
             The results are in the file <filename>${WORKDIR}/temp/log.do_listtasks</filename>.
         </para>
@@ -297,7 +295,7 @@
          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 figureing out the tasklist")
+         bb.debug(2, "Finished figuring out the tasklist")
      }
                 </literallayout>
             </para>

documentation/poky.ent

@@ -0,0 +1,48 @@
+<!ENTITY DISTRO "1.1.2">
+<!ENTITY DISTRO_NAME "edison">
+<!ENTITY YOCTO_DOC_VERSION "1.1.2">
+<!ENTITY POKYVERSION "6.0.2">
+<!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
+<!ENTITY COPYRIGHT_YEAR "2010-2012">
+<!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
+<!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
+<!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
+<!ENTITY YOCTO_BUGZILLA_URL "http://bugzilla.yoctoproject.org">
+<!ENTITY YOCTO_WIKI_URL "https://wiki.yoctoproject.org">
+<!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
+<!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
+<!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
+<!ENTITY OE_HOME_URL "http://www.openembedded.org">
+<!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
+<!ENTITY OH_HOME_URL "http://o-hand.com">
+<!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
+<!ENTITY BITBAKE_DOCS_URL "http://bitbake.berlios.de/manual/">
+<!ENTITY ECLIPSE_MAIN_URL "http://www.eclipse.org/downloads">
+<!ENTITY ECLIPSE_DL_URL "http://download.eclipse.org">
+<!ENTITY ECLIPSE_DL_PLUGIN_URL "&YOCTO_DL_URL;/releases/eclipse-plugin/&DISTRO;">
+<!ENTITY ECLIPSE_UPDATES_URL "&ECLIPSE_DL_URL;/tm/updates/3.3">
+<!ENTITY ECLIPSE_INDIGO_URL "&ECLIPSE_DL_URL;/releases/indigo">
+<!ENTITY ECLIPSE_INDIGO_CDT_URL "&ECLIPSE_DL_URL;tools/cdt/releases/indigo">
+<!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs">
+<!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/">
+<!ENTITY YOCTO_AB_PORT_URL "&YOCTO_AB_URL;:8010">
+<!ENTITY YOCTO_AB_NIGHTLY_URL "&YOCTO_AB_URL;/nightly/">
+<!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/">
+<!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;">
+<!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/">
+<!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/indigo;">
+<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer">
+<!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2">
+<!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines">
+<!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu">
+<!ENTITY YOCTO_PYTHON-i686_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2">
+<!ENTITY YOCTO_PYTHON-x86_64_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2">
+<!ENTITY YOCTO_DOCS_QS_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html">
+<!ENTITY YOCTO_DOCS_ADT_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html">
+<!ENTITY YOCTO_DOCS_REF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/poky-ref-manual/poky-ref-manual.html">
+<!ENTITY YOCTO_DOCS_BSP_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html">
+<!ENTITY YOCTO_DOCS_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html">
+<!ENTITY YOCTO_DOCS_KERNEL_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-manual/kernel-manual.html">
+<!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;">
+<!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
+<!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">

documentation/yocto-project-qs/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -946,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -958,11 +958,26 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

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

@@ -1,12 +1,13 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" 
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <article id='intro'>
    <imagedata fileref="figures/yocto-project-transp.png" width="6in" depth="1in" align="right" scale="25" />
 
 <section id='fake-title'>
-    <title>Yocto Project Quick Start</title>
-    <para>Copyright &copy; 2010-2012 Linux Foundation</para>
+    <title>The Yocto Project Quick Start</title>
+    <para>Copyright &copy; &COPYRIGHT_YEAR; Linux Foundation</para>
 </section>
 
 <section id='welcome'>
@@ -18,6 +19,7 @@
         Amongst other things, the Yocto Project uses the Poky build system to 
         construct complete Linux images.
     </para>
+
     <para>
         This short document will give you some basic information about the environment as well 
         as let you experience it in its simplest form.  
@@ -26,26 +28,28 @@
         This document steps you through a simple example showing you how to build a small image 
         and run it using the QEMU emulator.
     </para>
+
     <para>
-        For complete information on the Yocto Project, you should check out the 
-        <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>.
-        Through the website, you can find the latest builds, breaking news, full development 
-        documentation, and a 
-        rich Yocto Project Development Community into which you can tap.
-    </para>
-    <para>
-        Finally, you might find the Frequently Asked Questions (FAQ) for the Yocto Project
-        at <ulink url='https://wiki.yoctoproject.org/wiki/FAQ'>Yocto Project FAQ</ulink> and 
-        the FAQ appendix located in  
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
-        The Yocto Project Reference Manual</ulink> helpful.
+        For more detailed information on the Yocto Project, you should check out these resources:
+        <itemizedlist>
+            <listitem><para><emphasis>Website:</emphasis> The <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
+                provides the latest builds, breaking news, full development documentation, and a rich Yocto 
+                Project Development Community into which you can tap.
+                </para></listitem>
+            <listitem><para><emphasis>FAQs:</emphasis> Lists commonly asked Yocto Project questions and answers.
+                You can find two FAQs: <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>Yocto Project FAQ</ulink> on 
+                a wiki, and the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#faq'>FAQ</ulink> appendix in the 
+                The Yocto Project Reference Manual.
+                </para></listitem>
+        </itemizedlist>
     </para>
     <note>
         Due to production processes, there could be differences between the Yocto Project
         documentation bundled in the release tarball and the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
+        <ulink url='&YOCTO_DOCS_QS_URL;'>
         Yocto Project Quick Start</ulink> on
-        the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+        the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
         For the latest version of this manual, see the manual on the website.
     </note>
 </section>
@@ -156,11 +160,11 @@
                 <listitem><para>openSUSE</para></listitem>
             </itemizedlist>
             For a list of the distributions under validation and their status, see the
-            <ulink url='https://wiki.yoctoproject.org/wiki/Distribution_Support'>Distribution
+            <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution
             Support</ulink> wiki page.
             <note>
                 For notes about using the Yocto Project on a RHEL 4-based host, see the
-                <ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink>
+                <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink>
                 wiki page.
             </note>
             </para>
@@ -174,12 +178,12 @@
             If you attempt to use a distribution not in the above list, you may or may not have success - you 
             are venturing into untested territory.
             Refer to  
-            <ulink url='http://openembedded.net/index.php?title=OEandYourDistro&amp;action=historysubmit&amp;diff=4309&amp;okdid=4225'>OE and Your Distro</ulink> and 
-            <ulink url='http://openembedded.net/index.php?title=Required_software&amp;action=historysubmit&amp;diff=4311&amp;oldid=4251'>Required Software</ulink> 
+            <ulink url='&OE_HOME_URL;/index.php?title=OEandYourDistro&amp;action=historysubmit&amp;diff=4309&amp;okdid=4225'>OE and Your Distro</ulink> and 
+            <ulink url='&OE_HOME_URL;/index.php?title=Required_software&amp;action=historysubmit&amp;diff=4311&amp;oldid=4251'>Required Software</ulink> 
             for information for other distributions used with the OpenEmbedded project, which might be
             a starting point for exploration.
             If you go down this path, you should expect problems.
-            When you do, please go to <ulink url='http://bugzilla.yoctoproject.org'>Yocto Project Bugzilla</ulink>
+            When you do, please go to <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
             and submit a bug.
             We are interested in hearing about your experience.
         </para></note>
@@ -213,8 +217,8 @@
 
                 <literallayout class='monospaced'>
      $ sudo apt-get install sed wget cvs subversion git-core coreutils \
-     unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
-     python-pysqlite2 diffstat help2man make gcc build-essential \
+     unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk fop \
+     python-pysqlite2 diffstat help2man make gcc build-essential xsltproc \
      g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
      mercurial autoconf automake groff libtool xterm
                 </literallayout>
@@ -232,7 +236,7 @@
      $ sudo yum groupinstall "development tools"
      $ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
      unzip python-psyco perl texinfo texi2html diffstat openjade \
-     docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
+     docbook-style-dsssl sed docbook-style-xsl docbook-dtds fop xsltproc \
      docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
      groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
      perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
@@ -258,8 +262,8 @@
             </para>
 
                 <literallayout class='monospaced'>
-     $ sudo zypper install python gcc gcc-c++ libtool \
-     subversion git chrpath automake make wget help2man \
+     $ sudo zypper install python gcc gcc-c++ libtool fop \
+     subversion git chrpath automake make wget help2man xsltproc \
      diffstat texinfo mercurial freeglut-devel libSDL-devel
                 </literallayout>
         </section>
@@ -270,13 +274,13 @@
             
         <para>
             You can download the latest Yocto Project release by going to the 
-            <ulink url="http://yoctoproject.org/download">Yocto Project Download page</ulink>.
+            <ulink url="&YOCTO_HOME_URL;/download">Yocto Project Download page</ulink>.
             Just go to the page and click the "Yocto Downloads" link found in the "Download"
             navigation pane to the right to view all available Yocto Project releases. 
             Then, click the "Yocto Release" link for the release you want from the list to 
             begin the download. 
             Nightly and developmental builds are also maintained at
-            <ulink url="http://autobuilder.yoctoproject.org/nightly/"></ulink>.  
+            <ulink url="&YOCTO_AB_NIGHTLY_URL;"></ulink>.  
             However, for this document a released version of Yocto Project is used.
         </para>
 
@@ -285,10 +289,8 @@
             development system. 
             Doing so allows you to contribute back to the project.
             For information on how to get set up using this method, see the 
-            "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-yp-release'>Yocto 
-            Project Release</ulink>" item in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project
-            Development Manual</ulink>.
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto 
+            Project Release</ulink>" item in The Yocto Project Development Manual.
         </para>
     </section>
 </section>
@@ -297,7 +299,7 @@
     <title>A Quick Test Run</title>
 
     <para>
-        Now that you have your system requirements in order, you can give Yocto Project a try.  
+        Now that you have your system requirements in order, you can give the Yocto Project a try.  
         This section presents some steps that let you do the following:
     </para>
 
@@ -343,28 +345,28 @@
              By default, the Yocto Project searches for source code using a pre-determined order
              through a set of locations.
              If you encounter problems with the Yocto Project finding and downloading source code, see
-             the FAQ entry "How does Poky obtain source code and will it work behind my
+             the FAQ entry "How does the Yocto Project build system obtain source code and will it work behind my
              firewall or proxy server?" in  
-             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
+             <ulink url='&YOCTO_DOCS_REF_URL;#faq'>
              The Yocto Project Reference Manual</ulink>.
          </para></note>
 
          <para>
              <literallayout class='monospaced'>
-     $ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/poky-edison-6.0.1.tar.bz2
-     $ tar xjf poky-edison-6.0.1.tar.bz2
-     $ source poky-edison-6.0.1/oe-init-build-env edison-6.0.1-build
+     $ wget &YOCTO_POKY_DL_URL;
+     $ tar xjf &YOCTO_POKY;.tar.bz2
+     $ source &OE_INIT_PATH; &YOCTO_POKY;-build
              </literallayout>
          </para>
 
          <tip><para>
              To help conserve disk space during builds, you can add the following statement
              to your project's configuration file, which for this example
-             is <filename>edison-6.0.1-build/conf/local.conf</filename>.
+             is <filename>&YOCTO_POKY;-build/conf/local.conf</filename>.
              Adding this statement deletes the work directory used for building a package
              once the package is built.
              <literallayout class='monospaced'>
-     INHERIT += rm_work
+     INHERIT += "rm_work"
              </literallayout>
          </para></tip>
 
@@ -373,16 +375,16 @@
                  release tarball from the source repositories using the
                  <filename>wget</filename> command.
                  Alternatively, you can go to the 
-                 <ulink url='http://www.yoctoproject.org/download'>Yocto Project website</ulink>
-                 Downloads page to retrieve the tarball.</para></listitem>
+                 <ulink url='&YOCTO_HOME_URL;/download'>Yocto Project website's Downloads page</ulink>
+                 to retrieve the tarball.</para></listitem>
              <listitem><para>The second command extracts the files from the tarball and places 
-                 them into a directory named <filename>poky-edison-6.0.1</filename> in the current 
+                 them into a directory named <filename>&YOCTO_POKY;</filename> in the current 
                  directory.</para></listitem>
              <listitem><para>The third command runs the Yocto Project environment setup script.
                  Running this script defines Yocto Project build environment settings needed to 
                  complete the build.
                  The script also creates the Yocto Project
-                 build directory, which is <filename>edison-6.0.1-build</filename> in this case.
+                 build directory, which is <filename>&YOCTO_POKY;-build</filename> in this case.
                  After the script runs, your current working directory is set 
                  to the build directory.
                  Later, when the build completes, the build directory contains all the files 
@@ -406,15 +408,12 @@
 
          <para>
              Another couple of variables of interest are the 
-             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the 
-             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> variables.
+             <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the 
+             <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> variables.
              By default, these variables are commented out. 
              However, if you have a multi-core CPU you might want to uncomment
-             the lines and set the variable
-             <filename>BB_NUMBER_THREADS</filename> equal to twice the number of your 
+             the lines and set both variables equal to twice the number of your 
              host's processor cores.
-             Also, you could set the variable <filename>PARALLEL_MAKE</filename> equal to 
-             1.5 times the number of processor cores.
              Setting these variables can significantly shorten your build time.
          </para>
 
@@ -423,11 +422,10 @@
             the image. 
             By default, the Yocto Project build system uses the RPM package manager.
             You can control this configuration by using the 
-            <filename><ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.  
+            <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.  
              For additional package manager selection information, see 
-             "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" in 
-             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
-             The Yocto Project Reference Manual</ulink>.
+             "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" 
+             in The Yocto Project Reference Manual.
         </para>
 
          <para>
@@ -435,16 +433,16 @@
              <filename>core-image-sato</filename> in this example.
              For information on the <filename>-k</filename> option use the 
              <filename>bitbake --help</filename> command or see the
-             "<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>BitBake</ulink>" section in 
-             <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>The Yocto Project Reference Manual</ulink>.
+             "<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>" section in 
+             The Yocto Project Reference Manual.
              <literallayout class='monospaced'>
      $ bitbake -k core-image-sato
              </literallayout>
              <note><para>
                  BitBake requires Python 2.6 or 2.7.  For more information on this requirement, 
-                 see the FAQ appendix in  
-                 <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
-                 The Yocto Project Reference Manual</ulink>.
+                 see the 
+                 <ulink url='&YOCTO_DOCS_REF_URL;#faq'>FAQ</ulink> in The Yocto Project Reference 
+                 Manual.
              </para></note>
              The final command runs the image:
              <literallayout class='monospaced'>
@@ -482,7 +480,7 @@
         </para>
 
         <itemizedlist>
-            <listitem><para>Install the stand-alone Yocto toolchain tarball.</para></listitem>
+            <listitem><para>Install the appropriate stand-alone Yocto toolchain tarball.</para></listitem>
             <listitem><para>Download the pre-built image that will boot with QEMU.  
                 You need to be sure to get the QEMU image that matches your target machine’s 
                 architecture (e.g. x86, ARM, etc.).</para></listitem>
@@ -497,9 +495,9 @@
             <para>
                 You can download the pre-built toolchain, which includes the <filename>runqemu</filename> 
                 script and support files, from the appropriate directory under
-                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain/'></ulink>.  
+                <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.  
                 Toolchains are available for 32-bit and 64-bit development systems from the 
-                <filename>i686</filename> and <filename>x86_64</filename> directories, respectively. 
+                <filename>i686</filename> and <filename>x86-64</filename> directories, respectively. 
                 Each type of development system supports five target architectures.
                 The tarball files are named such that a string representing the host system appears 
                 first in the filename and then is immediately followed by a string representing
@@ -507,7 +505,7 @@
             </para>
 
             <literallayout class='monospaced'>
-     poky-eglibc&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
+     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
 
      Where:
          &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system: 
@@ -525,7 +523,7 @@
             </para>
 
             <literallayout class='monospaced'>
-     poky-eglibc-x86_64-i586-toolchain-gmae-1.1.1.tar.bz2
+     poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2
             </literallayout>
 
             <para>
@@ -538,16 +536,15 @@
             <para>
                 <literallayout class='monospaced'>
      $ cd /
-     $ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.1.tar.bz2
+     $ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2
                 </literallayout>
             </para>
 
             <para>
                 For more information on how to install tarballs, see the 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Yocto Project Build Tree</ulink>" sections in  
-                <ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project 
-                Application Development Toolkit (ADT) User's Guide</ulink>.
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and 
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Yocto Project Build Tree</ulink>" sections in The Yocto Project Application Development Toolkit (ADT) 
+                User's Guide.
             </para>
         </section>
 
@@ -556,11 +553,11 @@
       
             <para>
                 You can download the pre-built Linux kernel suitable for running in the QEMU emulator from 
-                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu'></ulink>.
+                <ulink url='&YOCTO_QEMU_DL_URL;'></ulink>.
                 Be sure to use the kernel that matches the architecture you want to simulate.
                 Download areas exist for the five supported machine architectures:
                 <filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
-                <filename>qemux86</filename>, and <filename>qemux86_64</filename>.
+                <filename>qemux86</filename>, and <filename>qemux86-64</filename>.
             </para>
          
             <para>  
@@ -577,9 +574,8 @@
 
             <para>
                 You can learn more about downloading a Yocto Project kernel in the 
-                "<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" section of  
-                <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The 
-                Yocto Project Development Manual</ulink>.
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" section of  
+                The Yocto Project Development Manual.
             </para>
         </section>
 
@@ -588,7 +584,7 @@
 
             <para>
                 You can also download the filesystem image suitable for your target architecture from
-                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu'></ulink>.
+                <ulink url='&YOCTO_QEMU_DL_URL;'></ulink>.
                 Again, be sure to use the filesystem that matches the architecture you want 
                 to simulate.
             </para>
@@ -599,7 +595,7 @@
                 You must use the <filename>ext3</filename> form when booting an image using the 
                 QEMU emulator.
                 The <filename>tar</filename> form can be flattened out in your host development system
-                and used for Yocto Project build purposes.
+                and used for build purposes with the Yocto Project.
                 <literallayout class='monospaced'>
      core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.ext3
      core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.tar.bz2
@@ -608,7 +604,7 @@
          &lt;<emphasis>profile</emphasis>&gt; is the filesystem image's profile:
                    lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
                    For information on these types of image profiles, see
-                   <ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
+                   <ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
 
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
                 x86, x86-64, ppc, mips, or arm.
@@ -623,7 +619,7 @@
                 Before you start the QEMU emulator, you need to set up the emulation environment.
                 The following command form sets up the emulation environment.
                 <literallayout class='monospaced'>
-     $ source /opt/poky/1.1.1/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt; 
+     $ source &YOCTO_ADTPATH_DIR;/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt; 
 
      Where:
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
@@ -653,12 +649,13 @@
             <para>
                 Continuing with the example, the following two commands setup the emulation 
                 environment and launch QEMU.
-                This example assumes the toolchain tarball has been downloaded and expanded
-                into <filename>/opt/poky</filename> and  
-                that the kernel and filesystem are for a 32-bit target architecture.
+                This example assumes the root filesystem (<filename>.ext3</filename> file) and 
+                the pre-built kernel image file both reside in your home directory. 
+                The kernel and filesystem are for a 32-bit target architecture.
                 <literallayout class='monospaced'>
-     $ source /opt/poky/1.1.1/environment-setup-i586-poky-linux 
-     $ runqemu qemux86 bzImage-3.0-qemux86-1.1.1.bin \
+     $ cd $HOME
+     $ source &YOCTO_ADTPATH_DIR;/environment-setup-i586-poky-linux 
+     $ runqemu qemux86 bzImage-qemux86.bin \
      core-image-sato-qemux86.ext3
                 </literallayout>
             </para>

meta-yocto/conf/distro/poky.conf

@@ -1,6 +1,6 @@
 DISTRO = "poky"
-DISTRO_NAME = "Yocto (Built by Poky 6.0.1)"
-DISTRO_VERSION = "1.1.1"
+DISTRO_NAME = "Yocto (Built by Poky 6.0.2)"
+DISTRO_VERSION = "1.1.2"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION := "${DISTRO_VERSION}"
 

meta/classes/bootimg.bbclass

@@ -62,13 +62,52 @@ build_boot_bin() {
 
 	install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys ${HDDDIR}/ldlinux.sys
 
-	# Do a little math, bash style
-	#BLOCKS=`du -s ${HDDDIR} | cut -f 1`
-	BLOCKS=`du -bks ${HDDDIR} | cut -f 1`
-	SIZE=`expr $BLOCKS + ${BOOTIMG_EXTRA_SPACE}`	
+	# Calculate the size required for the final image including the
+	# data and filesystem overhead.
+	# Sectors: 512 bytes
+	#  Blocks: 1024 bytes
 
-	mkdosfs -n ${BOOTIMG_VOLUME_ID} -d ${HDDDIR} \
-	-C ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg $SIZE 
+	# Determine the sector count just for the data
+	SECTORS=$(expr $(du --apparent-size -ks ${HDDDIR} | cut -f 1) \* 2)
+
+	# Account for the filesystem overhead. This includes directory
+	# entries in the clusters as well as the FAT itself.
+	# Assumptions:
+	#   FAT32 (12 or 16 may be selected by mkdosfs, but the extra
+	#   padding will be minimal on those smaller images and not
+	#   worth the logic here to caclulate the smaller FAT sizes)
+	#   < 16 entries per directory
+	#   8.3 filenames only
+
+	# 32 bytes per dir entry
+	DIR_BYTES=$(expr $(find ${HDDDIR} | tail -n +2 | wc -l) \* 32)
+	# 32 bytes for every end-of-directory dir entry
+	DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${HDDDIR} -type d | tail -n +2 | wc -l) \* 32))
+	# 4 bytes per FAT entry per sector of data
+	FAT_BYTES=$(expr $SECTORS \* 4)
+	# 4 bytes per FAT entry per end-of-cluster list
+	FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${HDDDIR} -type d | tail -n +2 | wc -l) \* 4))
+
+	# Use a ceiling function to determine FS overhead in sectors
+	DIR_SECTORS=$(expr $(expr $DIR_BYTES + 511) / 512)
+	# There are two FATs on the image
+	FAT_SECTORS=$(expr $(expr $(expr $FAT_BYTES + 511) / 512) \* 2)
+	SECTORS=$(expr $SECTORS + $(expr $DIR_SECTORS + $FAT_SECTORS))
+
+	# Determine the final size in blocks accounting for some padding
+	BLOCKS=$(expr $(expr $SECTORS / 2) + ${BOOTIMG_EXTRA_SPACE})
+
+
+	# Ensure total sectors is an integral number of sectors per
+	# track or mcopy will complain. Sectors are 512 bytes, and we
+	# generate images with 32 sectors per track. This calculation is
+	# done in blocks, thus the mod by 16 instead of 32.
+	BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16)))
+
+	IMG=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
+	mkdosfs -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${IMG} ${BLOCKS}
+	# Copy HDDDIR recursively into the image file directly
+	mcopy -i ${IMG} -s ${HDDDIR}/* ::/
 
 	syslinux ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
 	chmod 644 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg

meta/classes/image.bbclass

@@ -76,6 +76,8 @@ inherit image-${IMAGE_TYPE}
 python () {
     deps = bb.data.getVarFlag('do_rootfs', 'depends', d) or ""
     for type in (bb.data.getVar('IMAGE_FSTYPES', d, True) or "").split():
+        if type == "live":
+            type = "ext3"
         for dep in ((bb.data.getVar('IMAGE_DEPENDS_%s' % type, d) or "").split() or []):
             deps += " %s:do_populate_sysroot" % dep
     for dep in (bb.data.getVar('EXTRA_IMAGEDEPENDS', d, True) or "").split():

meta/classes/package_rpm.bbclass

@@ -379,7 +379,14 @@ package_install_internal_rpm () {
 
 	fi
 
-	cat ${target_rootfs}/install/install_solution.manifest > ${target_rootfs}/install/total_solution.manifest
+	# If base-passwd or shadow are in the list of packages to install,
+	# ensure they are installed first to support later packages that
+	# may create custom users/groups (fixes Yocto bug #2127)
+	infile=${target_rootfs}/install/install_solution.manifest
+	outfile=${target_rootfs}/install/total_solution.manifest
+	cat $infile | grep /base-passwd-[0-9] > $outfile || true
+	cat $infile | grep /shadow-[0-9] >> $outfile || true
+	cat $infile | grep -v /shadow-[0-9] | grep -v /base-passwd-[0-9] >> $outfile
 	cat ${target_rootfs}/install/install_multilib_solution.manifest >> ${target_rootfs}/install/total_solution.manifest
 
 	# Construct install scriptlet wrapper

meta/classes/populate_sdk_ipk.bbclass

@@ -20,6 +20,11 @@ populate_sdk_ipk() {
 	export INSTALL_CONF_IPK="${IPKGCONF_TARGET}"
 	export INSTALL_PACKAGES_IPK="${TOOLCHAIN_TARGET_TASK}"
 
+	export D=${INSTALL_ROOTFS_IPK}
+	export OFFLINE_ROOT=${INSTALL_ROOTFS_IPK}
+	export IPKG_OFFLINE_ROOT=${INSTALL_ROOTFS_IPK}
+	export OPKG_OFFLINE_ROOT=${IPKG_OFFLINE_ROOT}
+
 	package_install_internal_ipk
 
 	#install host

meta/classes/sstate.bbclass

@@ -10,12 +10,14 @@ SSTATE_PKGSPEC    = "sstate-${PN}-${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}-$
 SSTATE_PKGNAME    = "${SSTATE_PKGSPEC}${BB_TASKHASH}"
 SSTATE_PKG        = "${SSTATE_DIR}/${SSTATE_PKGNAME}"
 
-SSTATE_SCAN_CMD ?= "find ${SSTATE_BUILDDIR} \( -name "*.la" -o -name "*-config" \) -type f"
+SSTATE_SCAN_FILES ?= "*.la *-config"
+SSTATE_SCAN_CMD ?= 'find ${SSTATE_BUILDDIR} \( -name "${@"\" -o -name \"".join(d.getVar("SSTATE_SCAN_FILES", True).split())}" \) -type f'
 
 BB_HASHFILENAME = "${SSTATE_PKGNAME}"
 
 SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"
 
+SSTATEPREINSTFUNCS ?= ""
 SSTATEPOSTINSTFUNCS ?= ""
 
 python () {
@@ -169,6 +171,10 @@ def sstate_installpkg(ss, d):
 
     bb.data.setVar('SSTATE_INSTDIR', sstateinst, d)
     bb.data.setVar('SSTATE_PKG', sstatepkg, d)
+
+    for preinst in (d.getVar('SSTATEPREINSTFUNCS', True) or '').split():
+        bb.build.exec_func(preinst, d)
+
     bb.build.exec_func('sstate_unpack_package', d)
 
     # Fixup hardcoded paths
@@ -447,12 +453,14 @@ python sstate_task_postfunc () {
 #
 sstate_create_package () {
 	cd ${SSTATE_BUILDDIR}
+	TFILE=`mktemp ${SSTATE_PKG}.XXXXXXXX`
 	# Need to handle empty directories
 	if [ "$(ls -A)" ]; then
-		tar -czf ${SSTATE_PKG} *
+		tar -czf $TFILE *
 	else
-		tar -cz --file=${SSTATE_PKG} --files-from=/dev/null
+		tar -cz --file=$TFILE --files-from=/dev/null
 	fi
+	mv $TFILE ${SSTATE_PKG}
 
 	cd ${WORKDIR}
 	rm -rf ${SSTATE_BUILDDIR}

meta/classes/useradd.bbclass

@@ -3,11 +3,17 @@
 # and support files needed to add and modify user and group accounts
 DEPENDS_append = "${USERADDDEPENDS}"
 USERADDDEPENDS = " base-passwd shadow-native shadow-sysroot shadow"
+USERADDDEPENDS_virtclass-cross = ""
+USERADDDEPENDS_virtclass-native = ""
 USERADDDEPENDS_virtclass-nativesdk = ""
 
-# This preinstall function will be run in two contexts: once for the
-# native sysroot (as invoked by the useradd_sysroot() wrapper), and
-# also as the preinst script in the target package.
+# This preinstall function can be run in four different contexts:
+#
+# a) Before do_install
+# b) At do_populate_sysroot_setscene when installing from sstate packages
+# c) As the preinst script in the target package at do_rootfs time
+# d) As the preinst script in the target package on device as a package upgrade
+#
 useradd_preinst () {
 OPT=""
 SYSROOT=""
@@ -39,7 +45,23 @@ if test "x$GROUPADD_PARAM" != "x"; then
 		groupname=`echo "$opts" | awk '{ print $NF }'`
 		group_exists=`grep "^$groupname:" $SYSROOT/etc/group || true`
 		if test "x$group_exists" = "x"; then
-			eval $PSEUDO groupadd  $OPT $opts
+			count=1
+			while true; do
+				eval $PSEUDO groupadd $OPT $opts || true
+				group_exists=`grep "^$groupname:" $SYSROOT/etc/group || true`
+				if test "x$group_exists" = "x"; then
+					# File locking issues can require us to retry the command
+					echo "WARNING: groupadd command did not succeed. Retrying..."
+					sleep 1
+				else
+					break
+				fi
+				count=`expr $count + 1`
+				if test $count = 11; then
+					echo "ERROR: tried running groupadd command 10 times without success, giving up"
+					exit 1
+				fi
+			done		
 		else
 			echo "Note: group $groupname already exists, not re-creating it"
 		fi
@@ -64,7 +86,23 @@ if test "x$USERADD_PARAM" != "x"; then
 		username=`echo "$opts" | awk '{ print $NF }'`
 		user_exists=`grep "^$username:" $SYSROOT/etc/passwd || true`
 		if test "x$user_exists" = "x"; then
-			eval $PSEUDO useradd $OPT $opts
+			count=1
+			while true; do
+				eval $PSEUDO useradd $OPT $opts || true
+				user_exists=`grep "^$username:" $SYSROOT/etc/passwd || true`
+				if test "x$user_exists" = "x"; then
+					# File locking issues can require us to retry the command
+					echo "WARNING: useradd command did not succeed. Retrying..."
+					sleep 1
+				else
+					break
+				fi
+				count=`expr $count + 1`
+				if test $count = 11; then
+					echo "ERROR: tried running useradd command 10 times without success, giving up"
+					exit 1
+				fi
+			done
 		else
 			echo "Note: username $username already exists, not re-creating it"
 		fi
@@ -79,8 +117,10 @@ fi
 }
 
 useradd_sysroot () {
-	export PSEUDO="${STAGING_DIR_NATIVE}${bindir}/pseudo"
-	export PSEUDO_LOCALSTATEDIR="${STAGING_DIR_TARGET}${localstatedir}/pseudo"
+	# Pseudo may (do_install) or may not (do_populate_sysroot_setscene) be running 
+	# at this point so we're explicit about the environment so pseudo can load if 
+	# not already present.
+	export PSEUDO="${FAKEROOTENV} PSEUDO_LOCALSTATEDIR=${STAGING_DIR_TARGET}${localstatedir}/pseudo ${STAGING_DIR_NATIVE}${bindir}/pseudo"
 
 	# Explicitly set $D since it isn't set to anything
 	# before do_install
@@ -89,7 +129,7 @@ useradd_sysroot () {
 }
 
 useradd_sysroot_sstate () {
-	if [ "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
+	if [ "${BB_CURRENTTASK}" = "package_setscene" ]
 	then
 		useradd_sysroot
 	fi
@@ -97,11 +137,21 @@ useradd_sysroot_sstate () {
 
 do_install[prefuncs] += "${SYSROOTFUNC}"
 SYSROOTFUNC = "useradd_sysroot"
+SYSROOTFUNC_virtclass-cross = ""
+SYSROOTFUNC_virtclass-native = ""
 SYSROOTFUNC_virtclass-nativesdk = ""
-SSTATEPOSTINSTFUNCS += "${SYSROOTPOSTFUNC}"
+SSTATEPREINSTFUNCS += "${SYSROOTPOSTFUNC}"
 SYSROOTPOSTFUNC = "useradd_sysroot_sstate"
+SYSROOTPOSTFUNC_virtclass-cross = ""
+SYSROOTPOSTFUNC_virtclass-native = ""
 SYSROOTPOSTFUNC_virtclass-nativesdk = ""
 
+USERADDSETSCENEDEPS = "base-passwd:do_populate_sysroot_setscene shadow-native:do_populate_sysroot_setscene ${MLPREFIX}shadow-sysroot:do_populate_sysroot_setscene"
+USERADDSETSCENEDEPS_virtclass-cross = ""
+USERADDSETSCENEDEPS_virtclass-native = ""
+USERADDSETSCENEDEPS_virtclass-nativesdk = ""
+do_package_setscene[depends] = "${USERADDSETSCENEDEPS}"
+
 # Recipe parse-time sanity checks
 def update_useradd_after_parse(d):
 	useradd_packages = d.getVar('USERADD_PACKAGES', True)

meta/files/common-licenses/Adobe

@@ -0,0 +1,14 @@
+Copyright 1990-1998 Adobe Systems Incorporated.
+All Rights Reserved.
+  
+Patents Pending
+
+NOTICE: All information contained herein is the property of Adobe
+Systems Incorporated.
+
+Permission is granted for redistribution of this file provided
+this copyright notice is maintained intact and that the contents
+of this file are not altered in any way from its original form.
+
+PostScript and Display PostScript are trademarks of Adobe Systems
+Incorporated which may be registered in certain jurisdictions.

meta/files/common-licenses/BitstreamVera

@@ -0,0 +1,160 @@
+Bitstream Vera Fonts Copyright
+
+The fonts have a generous copyright, allowing derivative works (as
+long as "Bitstream" or "Vera" are not in the names), and full
+redistribution (so long as they are not *sold* by themselves). They
+can be be bundled, redistributed and sold with any software.
+
+The fonts are distributed under the following copyright:
+
+Copyright
+=========
+
+Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream
+Vera is a trademark of Bitstream, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of the fonts accompanying this license ("Fonts") and associated
+documentation files (the "Font Software"), to reproduce and distribute
+the Font Software, including without limitation the rights to use,
+copy, merge, publish, distribute, and/or sell copies of the Font
+Software, and to permit persons to whom the Font Software is furnished
+to do so, subject to the following conditions:
+
+The above copyright and trademark notices and this permission notice
+shall be included in all copies of one or more of the Font Software
+typefaces.
+
+The Font Software may be modified, altered, or added to, and in
+particular the designs of glyphs or characters in the Fonts may be
+modified and additional glyphs or characters may be added to the
+Fonts, only if the fonts are renamed to names not containing either
+the words "Bitstream" or the word "Vera".
+
+This License becomes null and void to the extent applicable to Fonts
+or Font Software that has been modified and is distributed under the
+"Bitstream Vera" names.
+
+The Font Software may be sold as part of a larger software package but
+no copy of one or more of the Font Software typefaces may be sold by
+itself.
+
+THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
+OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL
+BITSTREAM OR THE GNOME FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR
+OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL,
+OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT
+SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.
+
+Except as contained in this notice, the names of Gnome, the Gnome
+Foundation, and Bitstream Inc., shall not be used in advertising or
+otherwise to promote the sale, use or other dealings in this Font
+Software without prior written authorization from the Gnome Foundation
+or Bitstream Inc., respectively. For further information, contact:
+fonts at gnome dot org.
+
+Copyright FAQ
+=============
+
+1. I don't understand the resale restriction... What gives?
+
+Bitstream is giving away these fonts, but wishes to ensure its
+competitors can't just drop the fonts as is into a font sale system
+and sell them as is. It seems fair that if Bitstream can't make money
+from the Bitstream Vera fonts, their competitors should not be able to
+do so either. You can sell the fonts as part of any software package,
+however.
+
+2. I want to package these fonts separately for distribution and
+sale as part of a larger software package or system. Can I do so?
+
+Yes. A RPM or Debian package is a "larger software package" to begin
+with, and you aren't selling them independently by themselves.
+See 1. above.
+
+3. Are derivative works allowed?
+Yes!
+
+4. Can I change or add to the font(s)?
+Yes, but you must change the name(s) of the font(s).
+
+5. Under what terms are derivative works allowed?
+
+You must change the name(s) of the fonts. This is to ensure the
+quality of the fonts, both to protect Bitstream and Gnome. We want to
+ensure that if an application has opened a font specifically of these
+names, it gets what it expects (though of course, using fontconfig,
+substitutions could still could have occurred during font
+opening). You must include the Bitstream copyright. Additional
+copyrights can be added, as per copyright law. Happy Font Hacking!
+
+6. If I have improvements for Bitstream Vera, is it possible they might get
+adopted in future versions?
+
+Yes. The contract between the Gnome Foundation and Bitstream has
+provisions for working with Bitstream to ensure quality additions to
+the Bitstream Vera font family. Please contact us if you have such
+additions. Note, that in general, we will want such additions for the
+entire family, not just a single font, and that you'll have to keep
+both Gnome and Jim Lyles, Vera's designer, happy! To make sense to add
+glyphs to the font, they must be stylistically in keeping with Vera's
+design. Vera cannot become a "ransom note" font. Jim Lyles will be
+providing a document describing the design elements used in Vera, as a
+guide and aid for people interested in contributing to Vera.
+
+7. I want to sell a software package that uses these fonts: Can I do so?
+
+Sure. Bundle the fonts with your software and sell your software
+with the fonts. That is the intent of the copyright.
+
+8. If applications have built the names "Bitstream Vera" into them,
+can I override this somehow to use fonts of my choosing?
+
+This depends on exact details of the software. Most open source
+systems and software (e.g., Gnome, KDE, etc.) are now converting to
+use fontconfig (see www.fontconfig.org) to handle font configuration,
+selection and substitution; it has provisions for overriding font
+names and subsituting alternatives. An example is provided by the
+supplied local.conf file, which chooses the family Bitstream Vera for
+"sans", "serif" and "monospace". Other software (e.g., the XFree86
+core server) has other mechanisms for font substitution.
+
+Show details Hide details
+
+Change log
+r2011 by mark.nickel on Mar 3, 2011   Diff
+
+Majority of Multi-Line text editing is in
+the commit.  Also added some specific free
+fonts to replace the existing set as we
+need some additional font metrics that we
+use in the Text Editing rendering
+pipeline.
+
+You can see the font licenses in the
+editor/fonts folder under each font.
+
+Still have some cleanup to do to add the
+text formatting (left,right,center) as
+...
+
+Go to: 	
+Hide comments
+Show comments
+
+Older revisions
+All revisions of this file
+
+File info
+Size: 5953 bytes, 123 lines
+View raw file
+
+File properties
+
+svn:executable
+    *
+
+

meta/files/common-licenses/DSSSL

@@ -0,0 +1,49 @@
+Copyright
+---------
+
+Copyright (C) 1997-2001 Norman Walsh
+
+The original inspiration for these stylesheets came from the
+work of Jon Bosak, Anders Berglund, Tony Graham, Terry Allen,
+James Clark, and many others.  I am indebted to them and to the
+community of users on dssslist@mulberrytech.com for making
+substantial contributions to this work and for answering my many
+questions.
+
+This software may be distributed under the same terms as Jade:
+
+Permission is hereby granted, free of charge, to any person
+obtaining a copy of this software and associated documentation
+files (the ``Software''), to deal in the Software without
+restriction, including without limitation the rights to use,
+copy, modify, merge, publish, distribute, sublicense, and/or
+sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following
+conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+Except as contained in this notice, the names of individuals
+credited with contribution to this software shall not be used in
+advertising or otherwise to promote the sale, use or other
+dealings in this Software without prior written authorization
+from the individuals in question.
+
+Any stylesheet derived from this Software that is publically
+distributed will be identified with a different name and the
+version strings in any derived Software will be changed so that
+no possibility of confusion between the derived package and this
+Software will exist.
+
+Warranty
+--------
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT.  IN NO EVENT SHALL NORMAN WALSH OR ANY OTHER
+CONTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+OTHER DEALINGS IN THE SOFTWARE.

meta/files/common-licenses/EDL-1.0

@@ -0,0 +1,13 @@
+Eclipse Distribution License - v 1.0
+
+Copyright (c) 2007, Eclipse Foundation, Inc. and its licensors.
+
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
+    * Neither the name of the Eclipse Foundation, Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. 
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

meta/files/common-licenses/Elfutils-Exception

@@ -0,0 +1,12 @@
+   This file describes the limits of the Exception under which you are allowed
+   to distribute Non-GPL Code in linked combination with Red Hat elfutils.
+   For the full text of the license, please see one of the header files
+   included with the source distribution or the file COPYING found in the
+   top level directory of the source.
+
+   The Approved Interfaces are the functions declared in the files:
+
+   libelf.h
+   libdw.h
+   libdwfl.h
+

meta/files/common-licenses/FSF-Unlimited

@@ -0,0 +1,4 @@
+Copyright (C) 1997-2010 Free Software Foundation, Inc.
+This file is free software; the Free Software Foundation
+gives unlimited permission to copy and/or distribute it,
+with or without modifications, as long as this notice is preserved.

meta/files/common-licenses/FreeType

@@ -0,0 +1,170 @@
+                    The FreeType Project LICENSE
+                    ----------------------------
+
+                            2006-Jan-27
+
+                    Copyright 1996-2002, 2006 by
+          David Turner, Robert Wilhelm, and Werner Lemberg
+
+
+
+Introduction
+============
+
+  The FreeType  Project is distributed in  several archive packages;
+  some of them may contain, in addition to the FreeType font engine,
+  various tools and  contributions which rely on, or  relate to, the
+  FreeType Project.
+
+  This  license applies  to all  files found  in such  packages, and
+  which do not  fall under their own explicit  license.  The license
+  affects  thus  the  FreeType   font  engine,  the  test  programs,
+  documentation and makefiles, at the very least.
+
+  This  license   was  inspired  by  the  BSD,   Artistic,  and  IJG
+  (Independent JPEG  Group) licenses, which  all encourage inclusion
+  and  use of  free  software in  commercial  and freeware  products
+  alike.  As a consequence, its main points are that:
+
+    o We don't promise that this software works. However, we will be
+      interested in any kind of bug reports. (`as is' distribution)
+
+    o You can  use this software for whatever you  want, in parts or
+      full form, without having to pay us. (`royalty-free' usage)
+
+    o You may not pretend that  you wrote this software.  If you use
+      it, or  only parts of it,  in a program,  you must acknowledge
+      somewhere  in  your  documentation  that  you  have  used  the
+      FreeType code. (`credits')
+
+  We  specifically  permit  and  encourage  the  inclusion  of  this
+  software, with  or without modifications,  in commercial products.
+  We  disclaim  all warranties  covering  The  FreeType Project  and
+  assume no liability related to The FreeType Project.
+
+
+  Finally,  many  people  asked  us  for  a  preferred  form  for  a
+  credit/disclaimer to use in compliance with this license.  We thus
+  encourage you to use the following text:
+
+   """  
+    Portions of this software are copyright <20> <year> The FreeType
+    Project (www.freetype.org).  All rights reserved.
+   """
+
+  Please replace <year> with the value from the FreeType version you
+  actually use.
+
+
+Legal Terms
+===========
+
+0. Definitions
+--------------
+
+  Throughout this license,  the terms `package', `FreeType Project',
+  and  `FreeType  archive' refer  to  the  set  of files  originally
+  distributed  by the  authors  (David Turner,  Robert Wilhelm,  and
+  Werner Lemberg) as the `FreeType Project', be they named as alpha,
+  beta or final release.
+
+  `You' refers to  the licensee, or person using  the project, where
+  `using' is a generic term including compiling the project's source
+  code as  well as linking it  to form a  `program' or `executable'.
+  This  program is  referred to  as  `a program  using the  FreeType
+  engine'.
+
+  This  license applies  to all  files distributed  in  the original
+  FreeType  Project,   including  all  source   code,  binaries  and
+  documentation,  unless  otherwise  stated   in  the  file  in  its
+  original, unmodified form as  distributed in the original archive.
+  If you are  unsure whether or not a particular  file is covered by
+  this license, you must contact us to verify this.
+
+  The FreeType  Project is copyright (C) 1996-2000  by David Turner,
+  Robert Wilhelm, and Werner Lemberg.  All rights reserved except as
+  specified below.
+
+1. No Warranty
+--------------
+
+  THE FREETYPE PROJECT  IS PROVIDED `AS IS' WITHOUT  WARRANTY OF ANY
+  KIND, EITHER  EXPRESS OR IMPLIED,  INCLUDING, BUT NOT  LIMITED TO,
+  WARRANTIES  OF  MERCHANTABILITY   AND  FITNESS  FOR  A  PARTICULAR
+  PURPOSE.  IN NO EVENT WILL ANY OF THE AUTHORS OR COPYRIGHT HOLDERS
+  BE LIABLE  FOR ANY DAMAGES CAUSED  BY THE USE OR  THE INABILITY TO
+  USE, OF THE FREETYPE PROJECT.
+
+2. Redistribution
+-----------------
+
+  This  license  grants  a  worldwide, royalty-free,  perpetual  and
+  irrevocable right  and license to use,  execute, perform, compile,
+  display,  copy,   create  derivative  works   of,  distribute  and
+  sublicense the  FreeType Project (in  both source and  object code
+  forms)  and  derivative works  thereof  for  any  purpose; and  to
+  authorize others  to exercise  some or all  of the  rights granted
+  herein, subject to the following conditions:
+
+    o Redistribution of  source code  must retain this  license file
+      (`FTL.TXT') unaltered; any  additions, deletions or changes to
+      the original  files must be clearly  indicated in accompanying
+      documentation.   The  copyright   notices  of  the  unaltered,
+      original  files must  be  preserved in  all  copies of  source
+      files.
+
+    o Redistribution in binary form must provide a  disclaimer  that
+      states  that  the software is based in part of the work of the
+      FreeType Team,  in  the  distribution  documentation.  We also
+      encourage you to put an URL to the FreeType web page  in  your
+      documentation, though this isn't mandatory.
+
+  These conditions  apply to any  software derived from or  based on
+  the FreeType Project,  not just the unmodified files.   If you use
+  our work, you  must acknowledge us.  However, no  fee need be paid
+  to us.
+
+3. Advertising
+--------------
+
+  Neither the  FreeType authors and  contributors nor you  shall use
+  the name of the  other for commercial, advertising, or promotional
+  purposes without specific prior written permission.
+
+  We suggest,  but do not require, that  you use one or  more of the
+  following phrases to refer  to this software in your documentation
+  or advertising  materials: `FreeType Project',  `FreeType Engine',
+  `FreeType library', or `FreeType Distribution'.
+
+  As  you have  not signed  this license,  you are  not  required to
+  accept  it.   However,  as  the FreeType  Project  is  copyrighted
+  material, only  this license, or  another one contracted  with the
+  authors, grants you  the right to use, distribute,  and modify it.
+  Therefore,  by  using,  distributing,  or modifying  the  FreeType
+  Project, you indicate that you understand and accept all the terms
+  of this license.
+
+4. Contacts
+-----------
+
+  There are two mailing lists related to FreeType:
+
+    o freetype@nongnu.org
+
+      Discusses general use and applications of FreeType, as well as
+      future and  wanted additions to the  library and distribution.
+      If  you are looking  for support,  start in  this list  if you
+      haven't found anything to help you in the documentation.
+
+    o freetype-devel@nongnu.org
+
+      Discusses bugs,  as well  as engine internals,  design issues,
+      specific licenses, porting, etc.
+
+  Our home page can be found at
+
+    http://www.freetype.org
+
+
+--- end of FTL.TXT ---
+

meta/files/common-licenses/GPL-2.0-with-GCC-exception

@@ -2,5 +2,16 @@
 insert GPL v2 text here
 
 GCC Linking Exception
-In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable.)
+In addition to the permissions in the GNU General Public License, the Free
+Software Foundation gives you unlimited permission to link the compiled version
+of this file into combinations with other programs, and to distribute those
+combinations without any restriction coming from the use of this file. (The
+General Public License restrictions do apply in other respects; for example,
+they cover modification of the file, and distribution when not linked into a
+combine executable.)
+
+
+
+
+
 

meta/files/common-licenses/GPL-2.0-with-OpenSSL-exception

@@ -0,0 +1,285 @@
+
+GNU GENERAL PUBLIC LICENSE
+
+Version 2, June 1991
+
+Copyright (C) 1989, 1991 Free Software Foundation, Inc.  
+51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
+
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed.
+Preamble
+
+The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation`s software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.
+
+When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
+
+To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
+
+For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
+
+We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
+
+Also, for each author`s protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors` reputations.
+
+Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone`s free use or not licensed at all.
+
+The precise terms and conditions for copying, distribution and modification follow.
+
+TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
+
+1. You may copy and distribute verbatim copies of the Program`s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
+
+2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
+
+a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
+b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
+c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
+These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
+
+3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
+
+a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
+b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
+c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
+The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
+
+If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
+
+4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
+
+5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
+
+6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients` exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
+
+7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
+
+It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
+
+This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
+
+8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
+
+9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
+
+10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
+
+NO WARRANTY
+
+11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+END OF TERMS AND CONDITIONS
+
+How to Apply These Terms to Your New Programs
+
+If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
+
+To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
+
+one line to give the program`s name and an idea of what it does.
+Copyright (C) yyyy  name of author
+
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+as published by the Free Software Foundation; either version 2
+of the License, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
+
+Gnomovision version 69, Copyright (C) year name of author
+Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
+type `show w`.  This is free software, and you are welcome
+to redistribute it under certain conditions; type `show c` 
+for details.
+The hypothetical commands `show w` and `show c` should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w` and `show c`; they could even be mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:
+
+Yoyodyne, Inc., hereby disclaims all copyright
+interest in the program `Gnomovision`
+(which makes passes at compilers) written 
+by James Hacker.
+
+signature of Ty Coon, 1 April 1989
+Ty Coon, President of Vice
+This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.
+
+
+In addition, as a special exception, the copyright holder
+gives permission to link the code of this program with
+any version of the OpenSSL library which is distributed
+under a license identical to that listed in the included
+COPYING.OpenSSL file, and distribute linked combinations
+including the two. You must obey the GNU General Public
+License in all respects for all of the code used other
+than OpenSSL. If you modify this file, you may extend this
+exception to your version of the file, but you are not
+obligated to do so. If you do not wish to do so, delete
+this exception statement from your version.
+
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation, version 2 of the License
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+
+  LICENSE ISSUES
+  ==============
+
+  The OpenSSL toolkit stays under a dual license, i.e. both the conditions of
+  the OpenSSL License and the original SSLeay license apply to the toolkit.
+  See below for the actual license texts. Actually both licenses are BSD-style
+  Open Source licenses. In case of any license issues related to OpenSSL
+  please contact openssl-core@openssl.org.
+
+  OpenSSL License
+  ---------------
+
+/* ====================================================================
+ * Copyright (c) 1998-2002 The OpenSSL Project.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer. 
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in
+ *    the documentation and/or other materials provided with the
+ *    distribution.
+ *
+ * 3. All advertising materials mentioning features or use of this
+ *    software must display the following acknowledgment:
+ *    "This product includes software developed by the OpenSSL Project
+ *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
+ *
+ * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
+ *    endorse or promote products derived from this software without
+ *    prior written permission. For written permission, please contact
+ *    openssl-core@openssl.org.
+ *
+ * 5. Products derived from this software may not be called "OpenSSL"
+ *    nor may "OpenSSL" appear in their names without prior written
+ *    permission of the OpenSSL Project.
+ *
+ * 6. Redistributions of any form whatsoever must retain the following
+ *    acknowledgment:
+ *    "This product includes software developed by the OpenSSL Project
+ *    for use in the OpenSSL Toolkit (http://www.openssl.org/)"
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
+ * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
+ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+ * ====================================================================
+ *
+ * This product includes cryptographic software written by Eric Young
+ * (eay@cryptsoft.com).  This product includes software written by Tim
+ * Hudson (tjh@cryptsoft.com).
+ *
+ */
+
+ Original SSLeay License
+ -----------------------
+
+/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
+ * All rights reserved.
+ *
+ * This package is an SSL implementation written
+ * by Eric Young (eay@cryptsoft.com).
+ * The implementation was written so as to conform with Netscapes SSL.
+ * 
+ * This library is free for commercial and non-commercial use as long as
+ * the following conditions are aheared to.  The following conditions
+ * apply to all code found in this distribution, be it the RC4, RSA,
+ * lhash, DES, etc., code; not just the SSL code.  The SSL documentation
+ * included with this distribution is covered by the same copyright terms
+ * except that the holder is Tim Hudson (tjh@cryptsoft.com).
+ * 
+ * Copyright remains Eric Young's, and as such any Copyright notices in
+ * the code are not to be removed.
+ * If this package is used in a product, Eric Young should be given attribution
+ * as the author of the parts of the library used.
+ * This can be in the form of a textual message at program startup or
+ * in documentation (online or textual) provided with the package.
+ * 
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ *    "This product includes cryptographic software written by
+ *     Eric Young (eay@cryptsoft.com)"
+ *    The word 'cryptographic' can be left out if the rouines from the library
+ *    being used are not cryptographic related :-).
+ * 4. If you include any Windows specific code (or a derivative thereof) from 
+ *    the apps directory (application code) you must include an acknowledgement:
+ *    "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
+ * 
+ * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ * 
+ * The licence and distribution terms for any publically available version or
+ * derivative of this code cannot be changed.  i.e. this code cannot simply be
+ * copied and put under another distribution licence
+ * [including the GNU Public Licence.]
+ */

meta/files/common-licenses/GPL-2.0-with-font-exception

@@ -2,5 +2,17 @@
 insert GPL v2 text here
 
 Font Exception
-As a special exception, if you create a document which uses this font, and embed this font or unaltered portions of this font into the document, this font does not by itself cause the resulting document to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the document might be covered by the GNU General Public License. If you modify this font, you may extend this exception to your version of the font, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
+As a special exception, if you create a document which uses this font, and
+embed this font or unaltered portions of this font into the document, this font
+does not by itself cause the resulting document to be covered by the GNU
+General Public License. This exception does not however invalidate any other
+reasons why the document might be covered by the GNU General Public License. If
+you modify this font, you may extend this exception to your version of the
+font, but you are not obligated to do so. If you do not wish to do so, delete
+this exception statement from your version.
+
+
+
+
+
 

meta/files/common-licenses/GPL-3.0

@@ -1,3 +1,225 @@
+GNU GENERAL PUBLIC LICENSE
 
-license exceeds allowable cell character limit
+Version 3, 29 June 2007
 
+Copyright © 2007 Free Software Foundation, Inc. <http://fsf.org/>
+
+Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
+Preamble
+
+The GNU General Public License is a free, copyleft license for software and other kinds of works.
+
+The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.
+
+When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
+
+To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.
+
+For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
+
+Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.
+
+For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.
+
+Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.
+
+Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.
+
+The precise terms and conditions for copying, distribution and modification follow.
+TERMS AND CONDITIONS
+0. Definitions.
+
+“This License” refers to version 3 of the GNU General Public License.
+
+“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.
+
+“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.
+
+To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
+
+A “covered work” means either the unmodified Program or a work based on the Program.
+
+To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
+
+To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
+
+An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
+1. Source Code.
+
+The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.
+
+A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.
+
+The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
+
+The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
+
+The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
+
+The Corresponding Source for a work in source code form is that same work.
+2. Basic Permissions.
+
+All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.
+
+You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
+
+Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
+3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.
+
+When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.
+4. Conveying Verbatim Copies.
+
+You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.
+
+You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
+5. Conveying Modified Source Versions.
+
+You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
+
+    * a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
+    * b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.
+    * c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
+    * d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
+
+A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
+6. Conveying Non-Source Forms.
+
+You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
+
+    * a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
+    * b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
+    * c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
+    * d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
+    * e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
+
+A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.
+
+A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.
+
+“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
+
+If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
+
+The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.
+
+Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
+7. Additional Terms.
+
+“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.
+
+When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.
+
+Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:
+
+    * a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
+    * b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
+    * c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
+    * d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
+    * e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
+    * f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
+
+All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.
+
+If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.
+
+Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
+8. Termination.
+
+You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).
+
+However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
+
+Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
+
+Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.
+9. Acceptance Not Required for Having Copies.
+
+You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
+10. Automatic Licensing of Downstream Recipients.
+
+Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
+
+An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.
+
+You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
+11. Patents.
+
+A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's “contributor version”.
+
+A contributor's “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.
+
+Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
+
+In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.
+
+If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.
+
+If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.
+
+A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
+
+Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
+12. No Surrender of Others' Freedom.
+
+If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
+13. Use with the GNU Affero General Public License.
+
+Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.
+14. Revised Versions of this License.
+
+The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.
+
+If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.
+
+Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
+15. Disclaimer of Warranty.
+
+THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+16. Limitation of Liability.
+
+IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+17. Interpretation of Sections 15 and 16.
+
+If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.
+
+END OF TERMS AND CONDITIONS
+How to Apply These Terms to Your New Programs
+
+If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
+
+To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation, either version 3 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:
+
+    <program>  Copyright (C) <year>  <name of author>
+    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”.
+
+You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see <http://www.gnu.org/licenses/>.
+
+The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read <http://www.gnu.org/philosophy/why-not-lgpl.html>.

meta/files/common-licenses/ICU

@@ -0,0 +1,13 @@
+COPYRIGHT AND PERMISSION NOTICE
+
+Copyright (c) 1995-2012 International Business Machines Corporation and others
+
+All rights reserved.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+
+Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder.
+
+All trademarks and registered trademarks mentioned herein are the property of their respective owners. 

meta/files/common-licenses/LGPL-2.0

@@ -1,173 +1,342 @@
-
 GNU LIBRARY GENERAL PUBLIC LICENSE
 
+
+
 Version 2, June 1991
 
+
+
 Copyright (C) 1991 Free Software Foundation, Inc.
+
 51 Franklin St, Fifth Floor, Boston, MA  02110-1301, USA
+
 Everyone is permitted to copy and distribute verbatim copies
+
 of this license document, but changing it is not allowed.
 
+
+
 [This is the first released version of the library GPL.  It is
+
  numbered 2 because it goes with version 2 of the ordinary GPL.]
+
 Preamble
 
+
+
 The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.
 
+
+
 This license, the Library General Public License, applies to some specially designated Free Software Foundation software, and to any other libraries whose authors decide to use it. You can use it for your libraries, too.
 
+
+
 When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
 
+
+
 To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library, or if you modify it.
 
+
+
 For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights.
 
+
+
 Our method of protecting your rights has two steps: (1) copyright the library, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the library.
 
-Also, for each distributor`s protection, we want to make certain that everyone understands that there is no warranty for this free library. If the library is modified by someone else and passed on, we want its recipients to know that what they have is not the original version, so that any problems introduced by others will not reflect on the original authors` reputations.
 
-Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that companies distributing free software will individually obtain patent licenses, thus in effect transforming the program into proprietary software. To prevent this, we have made it clear that any patent must be licensed for everyone`s free use or not licensed at all.
 
-Most GNU software, including some libraries, is covered by the ordinary GNU General Public License, which was designed for utility programs. This license, the GNU Library General Public License, applies to certain designated libraries. This license is quite different from the ordinary one; be sure to read it in full, and don`t assume that anything in it is the same as in the ordinary license.
+Also, for each distributor's protection, we want to make certain that everyone understands that there is no warranty for this free library. If the library is modified by someone else and passed on, we want its recipients to know that what they have is not the original version, so that any problems introduced by others will not reflect on the original authors' reputations.
+
+
+
+Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that companies distributing free software will individually obtain patent licenses, thus in effect transforming the program into proprietary software. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
+
+
+
+Most GNU software, including some libraries, is covered by the ordinary GNU General Public License, which was designed for utility programs. This license, the GNU Library General Public License, applies to certain designated libraries. This license is quite different from the ordinary one; be sure to read it in full, and don't assume that anything in it is the same as in the ordinary license.
+
+
 
 The reason we have a separate public license for some libraries is that they blur the distinction we usually make between modifying or adding to a program and simply using it. Linking a program with a library, without changing the library, is in some sense simply using the library, and is analogous to running a utility program or application program. However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such.
 
+
+
 Because of this blurred distinction, using the ordinary General Public License for libraries did not effectively promote software sharing, because most developers did not use the libraries. We concluded that weaker conditions might promote sharing better.
 
+
+
 However, unrestricted linking of non-free programs would deprive the users of those programs of all benefit from the free status of the libraries themselves. This Library General Public License is intended to permit developers of non-free programs to use free libraries, while preserving your freedom as a user of such programs to change the free libraries that are incorporated in them. (We have not seen how to achieve this as regards changes in header files, but we have achieved it as regards changes in the actual functions of the Library.) The hope is that this will lead to faster development of free libraries.
 
+
+
 The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, while the latter only works together with the library.
 
+
+
 Note that it is possible for a library to be covered by the ordinary General Public License rather than by this special one.
 
+
+
 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
 
+
+
 0. This License Agreement applies to any software library which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Library General Public License (also called "this License"). Each licensee is addressed as "you".
 
+
+
 A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.
 
+
+
 The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".)
 
+
+
 "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.
 
+
+
 Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does.
 
-1. You may copy and distribute verbatim copies of the Library`s complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
+
+
+1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
+
+
 
 You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
 
+
+
 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
 
+
+
 a) The modified work must itself be a software library.
+
 b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
+
 c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
+
 d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.
+
 (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)
 
+
+
 These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
 
+
+
 Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.
 
+
+
 In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
 
+
+
 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
 
+
+
 Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.
 
+
+
 This option is useful when you wish to copy part of the code of the Library into a program that is not a library.
 
+
+
 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.
 
+
+
 If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.
 
+
+
 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
 
+
+
 However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
 
+
+
 When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.
 
+
+
 If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)
 
+
+
 Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.
 
-6. As an exception to the Sections above, you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer`s own use and reverse engineering for debugging such modifications.
+
+
+6. As an exception to the Sections above, you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
+
+
 
 You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
 
+
+
 a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
+
 b) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
+
 c) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
+
 d) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.
+
 For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
 
+
+
 It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.
 
+
+
 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:
 
+
+
 a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above.
+
 b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
+
 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
 
+
+
 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it.
 
-10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients` exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
+
+
+10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
+
+
 
 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.
 
+
+
 If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances.
 
+
+
 It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
 
+
+
 This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
 
+
+
 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
 
+
+
 13. The Free Software Foundation may publish revised and/or new versions of the Library General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
 
+
+
 Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.
 
+
+
 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
 
+
+
 NO WARRANTY
 
+
+
 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
 
+
+
 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
 
+
+
 END OF TERMS AND CONDITIONS
 
+
+
 How to Apply These Terms to Your New Libraries
 
+
+
 If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License).
 
+
+
 To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
 
-one line to give the library`s name and an idea of what it does.
+
+
+one line to give the library's name and an idea of what it does.
+
 Copyright (C) year  name of author
 
+
+
 This library is free software; you can redistribute it and/or
+
 modify it under the terms of the GNU Library General Public
+
 License as published by the Free Software Foundation; either
+
 version 2 of the License, or (at your option) any later version.
 
+
+
 This library is distributed in the hope that it will be useful,
+
 but WITHOUT ANY WARRANTY; without even the implied warranty of
+
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+
 Library General Public License for more details.
 
+
+
 You should have received a copy of the GNU Library General Public
+
 License along with this library; if not, write to the
+
 Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
+
 Boston, MA  02110-1301, USA.
+
 Also add information on how to contact you by electronic and paper mail.
 
+
+
 You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names:
 
+
+
 Yoyodyne, Inc., hereby disclaims all copyright interest in
-the library `Frob` (a library for tweaking knobs) written
+
+the library `Frob' (a library for tweaking knobs) written
+
 by James Random Hacker.
 
-signature of Ty Coon, 1 April 1990
-Ty Coon, President of Vice
-That`s all there is to it!
+
+
+signature of Ty Coon, 1 April 1990
+
+Ty Coon, President of Vice
+
+That's all there is to it!
 

meta/files/common-licenses/LGPL-3.0

@@ -1,66 +1,65 @@
-
 GNU LESSER GENERAL PUBLIC LICENSE
 
 Version 3, 29 June 2007
 
-Copyright &#169; 2007 Free Software Foundation, Inc. <http://fsf.org/>
+Copyright © 2007 Free Software Foundation, Inc. <http://fsf.org/>
 
 Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
 
 This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.
-
 0. Additional Definitions.
 
-As used herein, &#8220;this License&#8221; refers to version 3 of the GNU Lesser General Public License, and the &#8220;GNU GPL&#8221; refers to version 3 of the GNU General Public License.
+As used herein, “this License” refers to version 3 of the GNU Lesser General Public License, and the “GNU GPL” refers to version 3 of the GNU General Public License.
 
-&#8220;The Library&#8221; refers to a covered work governed by this License, other than an Application or a Combined Work as defined below.
+“The Library” refers to a covered work governed by this License, other than an Application or a Combined Work as defined below.
 
-An &#8220;Application&#8221; is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.
+An “Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.
 
-A &#8220;Combined Work&#8221; is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the &#8220;Linked Version&#8221;.
+A “Combined Work” is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the “Linked Version”.
 
-The &#8220;Minimal Corresponding Source&#8221; for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.
-
-The &#8220;Corresponding Application Code&#8221; for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.
+The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.
 
+The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.
 1. Exception to Section 3 of the GNU GPL.
 
 You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.
-
 2. Conveying Modified Versions.
 
 If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:
 
-a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or
-b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy.
+    * a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or
+    * b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy.
+
 3. Object Code Incorporating Material from Library Header Files.
 
 The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:
 
-a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
-b) Accompany the object code with a copy of the GNU GPL and this license document.
+    * a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
+    * b) Accompany the object code with a copy of the GNU GPL and this license document.
+
 4. Combined Works.
 
 You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:
 
-a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.
-b) Accompany the Combined Work with a copy of the GNU GPL and this license document.
-c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.
-d) Do one of the following:
-0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
-1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user`s computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
-e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)
+    * a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.
+    * b) Accompany the Combined Work with a copy of the GNU GPL and this license document.
+    * c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.
+    * d) Do one of the following:
+          o 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
+          o 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
+    * e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)
+
 5. Combined Libraries.
 
 You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following:
 
-a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License.
-b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
+    * a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License.
+    * b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
+
 6. Revised Versions of the GNU Lesser General Public License.
 
 The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
 
-Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License &#8220;or any later version&#8221; applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation.
-
-If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy`s public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.
+Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation.
 
+If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy's public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.

meta/files/common-licenses/OASIS

@@ -0,0 +1,13 @@
+  Permission to use, copy, modify and distribute the DocBook DTD and
+  its accompanying documentation for any purpose and without fee is
+  hereby granted in perpetuity, provided that the above copyright
+  notice and this paragraph appear in all copies.  The copyright
+  holders make no representation about the suitability of the DTD for
+  any purpose.  It is provided "as is" without expressed or implied
+  warranty.
+
+  If you modify the DocBook DTD in any way, except for declaring and
+  referencing additional sets of general entities and declaring
+  additional notations, label your DTD as a variant of DocBook.  See
+  the maintenance documentation for more information.
+

meta/files/common-licenses/OSL-1.0

@@ -1,5 +1,5 @@
 
-he Open Software License
+The Open Software License
 v. 1.0
 
 This Open Software License (the "License") applies to any original

meta/files/common-licenses/Proprietary

@@ -0,0 +1 @@
+Proprietary license.

meta/files/common-licenses/UCB

@@ -0,0 +1,26 @@
+   Copyright (c) 1987, 1989, 1990, 1991, 1992, 1993, 1994
+        The Regents of the University of California.  All rights reserved.
+
+   Redistribution and use in source and binary forms, with or without
+   modification, are permitted provided that the following conditions
+   are met:
+   1. Redistributions of source code must retain the above copyright
+      notice, this list of conditions and the following disclaimer.
+   2. Redistributions in binary form must reproduce the above copyright
+      notice, this list of conditions and the following disclaimer in the
+      documentation and/or other materials provided with the distribution.
+   3. Neither the name of the University nor the names of its contributors
+      may be used to endorse or promote products derived from this software
+      without specific prior written permission.
+
+   THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+   ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+   ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+   FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+   DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+   OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+   HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+   LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+   OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+   SUCH DAMAGE.

meta/recipes-bsp/grub/grub_1.99.bb

@@ -19,6 +19,9 @@ SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
           file://grub-install.in.patch;apply=yes \
           file://40_custom"
 
+SRC_URI[md5sum] = "ca9f2a2d571b57fc5c53212d1d22e2b5"
+SRC_URI[sha256sum] = "b91f420f2c51f6155e088e34ff99bea09cc1fb89585cf7c0179644e57abd28ff"
+
 inherit autotools
 inherit gettext
 

meta/recipes-core/zlib/files/Makefile.am

@@ -7,3 +7,6 @@ libz_la_SOURCES = adler32.c compress.c crc32.c gzlib.c gzclose.c gzread.c \
 libz_la_LDFLAGS = -version-number 1:2:5 --version-script zlib.map
 
 include_HEADERS = zconf.h zlib.h zlibdefs.h
+
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = zlib.pc

meta/recipes-core/zlib/files/configure.ac

@@ -43,6 +43,11 @@ cat > zlibdefs.h << EOF
 #endif
 EOF
 
-AC_CONFIG_FILES([Makefile])
+AC_SUBST(sharedlibdir,$libdir)
+
+AC_CONFIG_FILES([
+Makefile
+zlib.pc
+])
 
 AC_OUTPUT

meta/recipes-core/zlib/zlib_1.2.5.bb

@@ -7,12 +7,12 @@ LICENSE = "Zlib"
 LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d"
 
 DEPENDS = "libtool-cross"
-PR = "r1"
+PR = "r2"
 
 SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
            file://configure.ac \
            file://Makefile.am \
-	   file://fix.inverted.LFS.logic.patch"
+           file://fix.inverted.LFS.logic.patch"
 
 SRC_URI[md5sum] = "be1e89810e66150f5b0327984d8625a0"
 SRC_URI[sha256sum] = "239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307"

meta/recipes-devtools/apt/apt-0.7.14/localefixes.patch

@@ -0,0 +1,91 @@
+Add in missing header includes to resolve compile failures with recent 
+compiler/glibc combinations.
+
+Upstream-Status: Inappropriate [Resolved upstream]
+
+RP 2011/11/23
+
+Index: apt-0.7.14/apt-pkg/init.cc
+===================================================================
+--- apt-0.7.14.orig/apt-pkg/init.cc	2011-11-23 22:48:53.544637868 +0000
++++ apt-0.7.14/apt-pkg/init.cc	2011-11-23 22:48:59.456638260 +0000
+@@ -16,6 +16,7 @@
+ #include <config.h>
+ #include <cstdlib>
+ #include <sys/stat.h>
++#include <locale>
+ 									/*}}}*/
+ 
+ #define Stringfy_(x) # x
+Index: apt-0.7.14/cmdline/apt-cache.cc
+===================================================================
+--- apt-0.7.14.orig/cmdline/apt-cache.cc	2011-11-23 22:53:29.048631067 +0000
++++ apt-0.7.14/cmdline/apt-cache.cc	2011-11-23 22:54:15.784616212 +0000
+@@ -32,6 +32,7 @@
+ #include <apti18n.h>
+ 
+ #include <locale.h>
++#include <locale>
+ #include <iostream>
+ #include <unistd.h>
+ #include <errno.h>
+Index: apt-0.7.14/cmdline/apt-cdrom.cc
+===================================================================
+--- apt-0.7.14.orig/cmdline/apt-cdrom.cc	2011-11-23 22:53:29.064631096 +0000
++++ apt-0.7.14/cmdline/apt-cdrom.cc	2011-11-23 22:53:57.616630261 +0000
+@@ -27,6 +27,7 @@
+ //#include "indexcopy.h"
+ 
+ #include <locale.h>
++#include <locale>
+ #include <iostream>
+ #include <fstream>
+ #include <vector>
+Index: apt-0.7.14/cmdline/apt-config.cc
+===================================================================
+--- apt-0.7.14.orig/cmdline/apt-config.cc	2011-11-23 22:50:16.796635352 +0000
++++ apt-0.7.14/cmdline/apt-config.cc	2011-11-23 22:50:25.640633906 +0000
+@@ -27,6 +27,7 @@
+ #include <locale.h>
+ #include <iostream>
+ #include <string>
++#include <locale>
+ 									/*}}}*/
+ using namespace std;
+ 
+Index: apt-0.7.14/cmdline/apt-extracttemplates.cc
+===================================================================
+--- apt-0.7.14.orig/cmdline/apt-extracttemplates.cc	2011-11-23 22:53:29.080631084 +0000
++++ apt-0.7.14/cmdline/apt-extracttemplates.cc	2011-11-23 22:53:38.304630439 +0000
+@@ -39,6 +39,7 @@
+ #include <config.h>
+ #include <apti18n.h>
+ #include "apt-extracttemplates.h"
++#include <locale>
+ 									/*}}}*/
+ 
+ using namespace std;
+Index: apt-0.7.14/cmdline/apt-get.cc
+===================================================================
+--- apt-0.7.14.orig/cmdline/apt-get.cc	2011-11-23 22:53:29.096631090 +0000
++++ apt-0.7.14/cmdline/apt-get.cc	2011-11-23 22:53:49.368629452 +0000
+@@ -48,6 +48,7 @@
+ 
+ #include <set>
+ #include <locale.h>
++#include <locale>
+ #include <langinfo.h>
+ #include <fstream>
+ #include <termios.h>
+Index: apt-0.7.14/cmdline/apt-sortpkgs.cc
+===================================================================
+--- apt-0.7.14.orig/cmdline/apt-sortpkgs.cc	2011-11-23 22:52:03.872640247 +0000
++++ apt-0.7.14/cmdline/apt-sortpkgs.cc	2011-11-23 22:52:10.880638611 +0000
+@@ -27,6 +27,7 @@
+ 
+ #include <locale.h>
+ #include <unistd.h>
++#include <locale>
+ 									/*}}}*/
+ 
+ using namespace std;

meta/recipes-devtools/apt/apt-0.7.14/makerace.patch

@@ -0,0 +1,23 @@
+I was seeing various issues with parallel make, mainly due to to what was likely 
+partially installed headers. If you change into the source directory and
+"NOISY=1 make  ../obj/apt-pkg/sourcelist.opic" in apt-pkg, you'll see it 
+doesn't have any dependencies on the headers being installed. This patch
+fixes that so things build correctly.
+
+RP 2012/3/19
+
+Upstream-Status: Pending
+
+Index: apt-0.7.14/buildlib/library.mak
+===================================================================
+--- apt-0.7.14.orig/buildlib/library.mak
++++ apt-0.7.14/buildlib/library.mak
+@@ -61,7 +61,7 @@ $(LIB)/lib$(LIBRARY)$(LIBEXT).so.$(MAJOR
+ 
+ # Compilation rules
+ vpath %.cc $(SUBDIRS)
+-$(OBJ)/%.opic: %.cc
++$(OBJ)/%.opic: %.cc $($(LOCAL)-HEADERS)
+ 	echo Compiling $< to $@
+ 	$(CXX) -c $(INLINEDEPFLAG) $(CPPFLAGS) $(CXXFLAGS) $(PICFLAGS) -o $@ $<
+ 	$(DoDep)

meta/recipes-devtools/apt/apt-0.7.14/remove-redeclaration.patch

@@ -0,0 +1,63 @@
+Fix build errors on gcc 4.7:
+
+deb/deblistparser.cc: In member function 'virtual short unsigned int debListParser::VersionHash()':
+deb/deblistparser.cc:212:13: error: redeclaration of 'char* I'
+deb/deblistparser.cc:202:22: error: 'const char** I' previously declared here
+
+Upstream-Status: Backport
+Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
+---
+ apt-pkg/deb/deblistparser.cc |   10 +++++-----
+ cmdline/apt-get.cc           |    8 ++++----
+ 2 files changed, 9 insertions(+), 9 deletions(-)
+
+diff --git a/apt-pkg/deb/deblistparser.cc b/apt-pkg/deb/deblistparser.cc
+--- a/apt-pkg/deb/deblistparser.cc
++++ b/apt-pkg/deb/deblistparser.cc
+@@ -209,18 +209,18 @@ unsigned short debListParser::VersionHash()
+       /* Strip out any spaces from the text, this undoes dpkgs reformatting
+          of certain fields. dpkg also has the rather interesting notion of
+          reformatting depends operators < -> <= */
+-      char *I = S;
++      char *J = S;
+       for (; Start != End; Start++)
+       {
+ 	 if (isspace(*Start) == 0)
+-	    *I++ = tolower(*Start);
++	    *J++ = tolower(*Start);
+ 	 if (*Start == '<' && Start[1] != '<' && Start[1] != '=')
+-	    *I++ = '=';
++	    *J++ = '=';
+ 	 if (*Start == '>' && Start[1] != '>' && Start[1] != '=')
+-	    *I++ = '=';
++	    *J++ = '=';
+       }
+ 
+-      Result = AddCRC16(Result,S,I - S);
++      Result = AddCRC16(Result,S,J - S);
+    }
+    
+    return Result;
+diff --git a/cmdline/apt-get.cc b/cmdline/apt-get.cc
+--- a/cmdline/apt-get.cc
++++ b/cmdline/apt-get.cc
+@@ -1752,12 +1752,12 @@ bool DoInstall(CommandLine &CmdL)
+ 	 if ((*Cache)[I].Install() == false)
+ 	    continue;
+ 
+-	 const char **J;
+-	 for (J = CmdL.FileList + 1; *J != 0; J++)
+-	    if (strcmp(*J,I.Name()) == 0)
++	 const char **K;
++	 for (K = CmdL.FileList + 1; *K != 0; K++)
++	    if (strcmp(*K,I.Name()) == 0)
+ 		break;
+ 	 
+-	 if (*J == 0) {
++	 if (*K == 0) {
+ 	    List += string(I.Name()) + " ";
+ 	    VersionsList += string(Cache[I].CandVersion) + "\n";
+ 	 }
+-- 
+1.7.1
+

meta/recipes-devtools/apt/apt-native.inc

@@ -40,10 +40,11 @@ do_install_base () {
 	install -m 0755 bin/apt-extracttemplates ${D}${bindir}/
 
 	eval `cat environment.mak | grep ^GLIBC_VER | sed -e's, = ,=,'`
-	oe_libinstall -so -C bin libapt-pkg$GLIBC_VER-6 ${D}${libdir}/
-	ln -sf libapt-pkg$GLIBC_VER-6.so ${D}${libdir}/libapt-pkg.so
-	oe_libinstall -so -C bin libapt-inst$GLIBC_VER-6 ${D}${libdir}/
-	ln -sf libapt-inst$GLIBC_VER-6.so ${D}${libdir}/libapt-inst.so
+	eval `cat environment.mak | grep ^LIBSTDCPP_VER | sed -e's, = ,=,'`
+	oe_libinstall -so -C bin libapt-pkg$GLIBC_VER$LIBSTDCPP_VER ${D}${libdir}/
+	ln -sf libapt-pkg$GLIBC_VER$LIBSTDCPP_VER.so ${D}${libdir}/libapt-pkg.so
+	oe_libinstall -so -C bin libapt-inst$GLIBC_VER$LIBSTDCPP_VER ${D}${libdir}/
+	ln -sf libapt-inst$GLIBC_VER$LIBSTDCPP_VER.so ${D}${libdir}/libapt-inst.so
 
 	install -d ${D}${libdir}/apt/methods
 	install -m 0755 bin/methods/* ${D}${libdir}/apt/methods/

meta/recipes-devtools/apt/apt-native_0.7.14.bb

@@ -1,6 +1,6 @@
 require apt-native.inc
 
-PR = "r5"
+PR = "r8"
 
 SRC_URI += "file://nodoc.patch \
             file://noconfigure.patch \

meta/recipes-devtools/apt/apt-package.inc

@@ -78,10 +78,11 @@ do_install () {
 	install -m 0755 bin/apt-extracttemplates ${D}${bindir}/
 
 	eval `cat environment.mak | grep ^GLIBC_VER | sed -e's, = ,=,'`
-	oe_libinstall -so -C bin libapt-pkg$GLIBC_VER-6 ${D}${libdir}/
-	ln -sf libapt-pkg$GLIBC_VER-6.so ${D}${libdir}/libapt-pkg.so
-	oe_libinstall -so -C bin libapt-inst$GLIBC_VER-6 ${D}${libdir}/
-	ln -sf libapt-inst$GLIBC_VER-6.so ${D}${libdir}/libapt-inst.so
+	eval `cat environment.mak | grep ^LIBSTDCPP_VER | sed -e's, = ,=,'`
+	oe_libinstall -so -C bin libapt-pkg$GLIBC_VER$LIBSTDCPP_VER ${D}${libdir}/
+	ln -sf libapt-pkg$GLIBC_VER$LIBSTDCPP_VER.so ${D}${libdir}/libapt-pkg.so
+	oe_libinstall -so -C bin libapt-inst$GLIBC_VER$LIBSTDCPP_VER ${D}${libdir}/
+	ln -sf libapt-inst$GLIBC_VER$LIBSTDCPP_VER.so ${D}${libdir}/libapt-inst.so
 
 	install -d ${D}${libdir}/apt/methods
 	install -m 0755 bin/methods/* ${D}${libdir}/apt/methods/

meta/recipes-devtools/apt/apt.inc

@@ -5,6 +5,9 @@ SECTION = "base"
 SRC_URI = "${DEBIAN_MIRROR}/main/a/apt/apt_${PV}.tar.gz \
            file://no-ko-translation.patch \
            file://use-host.patch \
+           file://localefixes.patch \
+           file://makerace.patch \
+           file://remove-redeclaration.patch \
            "
 
 inherit autotools gettext

meta/recipes-devtools/apt/apt_0.7.14.bb

@@ -3,7 +3,7 @@ RDEPENDS_${PN} = "dpkg"
 LIC_FILES_CHKSUM = "file://COPYING.GPL;md5=0636e73ff0215e8d672dc4c32c317bb3"
 require apt.inc
 
-PR = "r8"
+PR = "r11"
 
 SRC_URI += "file://nodoc.patch \
             file://includes-fix.patch "

meta/recipes-devtools/dosfstools/dosfstools-native_2.10.bb

@@ -1,19 +0,0 @@
-# dosfstools-native OE build file
-# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights Reserved
-# Released under the MIT license (see packages/COPYING)
-
-require dosfstools_${PV}.bb
-
-PR="r5"
-
-SRC_URI = "ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-${PV}.src.tar.gz \
-	file://mkdosfs-bootcode.patch \
-	file://mkdosfs-dir.patch \
-	file://alignment_hack.patch \
-	file://dosfstools-2.10-kernel-2.6.patch \
-	file://msdos_fat12_undefined.patch \
-	file://dosfstools-msdos_fs-types.patch \
-	file://include-linux-types.patch \
-	file://2.6.20-syscall.patch"
-
-inherit native

meta/recipes-devtools/dosfstools/dosfstools/2.6.20-syscall.patch

@@ -1,65 +0,0 @@
-Index: dosfstools-2.10/dosfsck/io.c
-===================================================================
---- dosfstools-2.10.orig/dosfsck/io.c	2007-06-07 16:15:52.000000000 +0200
-+++ dosfstools-2.10/dosfsck/io.c	2007-06-07 16:16:06.000000000 +0200
-@@ -42,28 +42,11 @@
- /* Use the _llseek system call directly, because there (once?) was a bug in
-  * the glibc implementation of it. */
- #include <linux/unistd.h>
--#if defined __alpha || defined __ia64__ || defined __s390x__ || defined __x86_64__ || defined __ppc64__
- /* On alpha, the syscall is simply lseek, because it's a 64 bit system. */
- static loff_t llseek( int fd, loff_t offset, int whence )
- {
-     return lseek(fd, offset, whence);
- }
--#else
--# ifndef __NR__llseek
--# error _llseek system call not present
--# endif
--static _syscall5( int, _llseek, uint, fd, ulong, hi, ulong, lo,
--		  loff_t *, res, uint, wh );
--
--static loff_t llseek( int fd, loff_t offset, int whence )
--{
--    loff_t actual;
--
--    if (_llseek(fd, offset>>32, offset&0xffffffff, &actual, whence) != 0)
--	return (loff_t)-1;
--    return actual;
--}
--#endif
- 
- 
- void fs_open(char *path,int rw)
-Index: dosfstools-2.10/mkdosfs/mkdosfs.c
-===================================================================
---- dosfstools-2.10.orig/mkdosfs/mkdosfs.c	2007-06-07 16:15:11.000000000 +0200
-+++ dosfstools-2.10/mkdosfs/mkdosfs.c	2007-06-07 16:15:30.000000000 +0200
-@@ -116,27 +116,11 @@
- /* Use the _llseek system call directly, because there (once?) was a bug in
-  * the glibc implementation of it. */
- #include <linux/unistd.h>
--#if defined __alpha || defined __ia64__ || defined __s390x__ || defined __x86_64__ || defined __ppc64__
- /* On alpha, the syscall is simply lseek, because it's a 64 bit system. */
- static loff_t llseek( int fd, loff_t offset, int whence )
- {
-     return lseek(fd, offset, whence);
- }
--#else
--# ifndef __NR__llseek
--# error _llseek system call not present
--# endif
--static _syscall5( int, _llseek, uint, fd, ulong, hi, ulong, lo,
--		  loff_t *, res, uint, wh );
--static loff_t llseek( int fd, loff_t offset, int whence )
--{
--    loff_t actual;
--
--    if (_llseek(fd, offset>>32, offset&0xffffffff, &actual, whence) != 0)
--	return (loff_t)-1;
--    return actual;
--}
--#endif
- 
- #define ROUND_UP(value, divisor) (value + (divisor - (value % divisor))) / divisor
- 

meta/recipes-devtools/dosfstools/dosfstools/alignment_hack.patch

@@ -8,6 +8,10 @@ memcpy into an 16bit aligned
 
     -zecke
 
+Upstream-Status: Inappropriate [licensing]
+We're tracking an old release of dosfstools due to licensing issues.
+
+Signed-off-by: Scott Garman <scott.a.garman@intel.com>
 
 --- dosfstools/dosfsck/boot.c.orig	2003-05-15 19:32:23.000000000 +0200
 +++ dosfstools/dosfsck/boot.c	2003-06-13 17:44:25.000000000 +0200

meta/recipes-devtools/dosfstools/dosfstools/dosfstools-2.10-kernel-2.6.patch

@@ -1,74 +0,0 @@
-Submitted By: Jim Gifford (jim at linuxfromscratch dot org)
-Date: 2004-02-09
-Initial Package Version: 2.6
-Origin: Jim Gifford
-Upstream-Status: Accepted
-Description: Fixes Compile Issues with the 2.6 Kernel
- 
---- dosfstools-2.10/dosfsck/common.h.orig	2004-02-09 18:37:59.056737458 +0000
-+++ dosfstools-2.10/dosfsck/common.h	2004-02-09 18:38:18.333392952 +0000
-@@ -2,6 +2,13 @@
- 
- /* Written 1993 by Werner Almesberger */
- 
-+#include <linux/version.h>
-+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
-+       #define __KERNEL__
-+       #include <asm/types.h>
-+       #undef __KERNEL__
-+       #define MSDOS_FAT12 4084 /* maximum number of clusters in a 12 bit FAT */
-+#endif
- 
- #ifndef _COMMON_H
- #define _COMMON_H
---- dosfstools-2.10/dosfsck/file.c.orig	2004-02-09 18:40:52.016728845 +0000
-+++ dosfstools-2.10/dosfsck/file.c	2004-02-09 18:40:03.665117865 +0000
-@@ -15,6 +15,14 @@
- #define _LINUX_STAT_H		/* hack to avoid inclusion of <linux/stat.h> */
- #define _LINUX_STRING_H_	/* hack to avoid inclusion of <linux/string.h>*/
- #define _LINUX_FS_H             /* hack to avoid inclusion of <linux/fs.h> */
-+
-+#include <linux/version.h>
-+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
-+       #define __KERNEL__
-+       #include <asm/types.h>
-+       #undef __KERNEL__
-+#endif
-+
- #include <linux/msdos_fs.h>
- 
- #include "common.h"
---- dosfstools-2.10/dosfsck/dosfsck.h.orig	2004-02-09 18:57:11.022870974 +0000
-+++ dosfstools-2.10/dosfsck/dosfsck.h	2004-02-09 18:56:20.628614393 +0000
-@@ -13,6 +13,15 @@
- #define _LINUX_STAT_H		/* hack to avoid inclusion of <linux/stat.h> */
- #define _LINUX_STRING_H_	/* hack to avoid inclusion of <linux/string.h>*/
- #define _LINUX_FS_H             /* hack to avoid inclusion of <linux/fs.h> */
-+
-+#include <linux/version.h>
-+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
-+       #define __KERNEL__
-+       #include <asm/types.h>
-+       #include <asm/byteorder.h>
-+       #undef __KERNEL__
-+#endif
-+
- #include <linux/msdos_fs.h>
- 
- /* 2.1 kernels use le16_to_cpu() type functions for CF_LE_W & Co., but don't
---- dosfstools-2.10/mkdosfs/mkdosfs.c.orig	2004-02-09 18:31:41.997157413 +0000
-+++ dosfstools-2.10/mkdosfs/mkdosfs.c	2004-02-09 18:34:07.311945252 +0000
-@@ -66,6 +66,13 @@
- #include <time.h>
- #include <errno.h>
- 
-+#include <linux/version.h>
-+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
-+       #define __KERNEL__
-+       #include <asm/types.h>
-+       #undef __KERNEL__
-+#endif
-+
- #if __BYTE_ORDER == __BIG_ENDIAN
- 
- #include <asm/byteorder.h>

meta/recipes-devtools/dosfstools/dosfstools/dosfstools-msdos_fs-types.patch

@@ -1,3 +1,10 @@
+Ensure the __s8 type is properly defined.
+
+Upstream-Status: Inappropriate [licensing]
+We're tracking an old release of dosfstools due to licensing issues.
+
+Signed-off-by: Scott Garman <scott.a.garman@intel.com>
+
 --- dosfstools-2.10/dosfsck/dosfsck.h.org	2006-02-21 08:36:14.000000000 -0700
 +++ dosfstools-2.10/dosfsck/dosfsck.h	2006-02-21 08:40:12.000000000 -0700
 @@ -22,6 +22,14 @@

meta/recipes-devtools/dosfstools/dosfstools/include-linux-types.patch

@@ -5,6 +5,11 @@ include asm/types.h. To work around this patch mkdosfs.c to explicity
 include linux/types.h which will in turn pull in asm/types.h which
 defines these variables.
 
+Upstream-Status: Inappropriate [licensing]
+We're tracking an old release of dosfstools due to licensing issues.
+
+Signed-off-by: Scott Garman <scott.a.garman@intel.com>
+
 --- dosfstools-2.10/mkdosfs/mkdosfs.c~	2006-07-12 18:46:21.000000000 +1000
 +++ dosfstools-2.10/mkdosfs/mkdosfs.c	2006-07-12 18:46:21.000000000 +1000
 @@ -60,6 +60,7 @@

meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-bootcode.patch

@@ -1,6 +1,14 @@
-diff -urN dosfstools-2.10.orig/mkdosfs/ChangeLog dosfstools-2.10/mkdosfs/ChangeLog
---- dosfstools-2.10.orig/mkdosfs/ChangeLog	1997-06-18 03:09:38.000000000 -0700
-+++ dosfstools-2.10/mkdosfs/ChangeLog	2004-08-02 20:57:57.734939816 -0700
+Add option to read in bootcode from a file.
+
+Upstream-Status: Inappropriate [licensing]
+We're tracking an old release of dosfstools due to licensing issues.
+
+Signed-off-by: Scott Garman <scott.a.garman@intel.com>
+
+Index: dosfstools-2.11/mkdosfs/ChangeLog
+===================================================================
+--- dosfstools-2.11.orig/mkdosfs/ChangeLog	1997-06-18 10:09:38.000000000 +0000
++++ dosfstools-2.11/mkdosfs/ChangeLog	2011-12-06 12:14:23.634011558 +0000
 @@ -1,3 +1,14 @@
 +19th June 2003			Sam Bingner (sam@bingner.com)
 +
@@ -16,10 +24,11 @@ diff -urN dosfstools-2.10.orig/mkdosfs/ChangeLog dosfstools-2.10/mkdosfs/ChangeL
  28th January 1995		H. Peter Anvin (hpa@yggdrasil.com)
  
  	Better algorithm to select cluster sizes on large filesystems.
-diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.8 dosfstools-2.10/mkdosfs/mkdosfs.8
---- dosfstools-2.10.orig/mkdosfs/mkdosfs.8	2003-05-15 11:28:28.000000000 -0700
-+++ dosfstools-2.10/mkdosfs/mkdosfs.8	2004-08-02 20:57:57.735939664 -0700
-@@ -40,6 +40,10 @@
+Index: dosfstools-2.11/mkdosfs/mkdosfs.8
+===================================================================
+--- dosfstools-2.11.orig/mkdosfs/mkdosfs.8	2004-02-25 19:36:07.000000000 +0000
++++ dosfstools-2.11/mkdosfs/mkdosfs.8	2011-12-06 12:19:54.777888434 +0000
+@@ -44,6 +44,10 @@
  .I message-file
  ]
  [
@@ -30,7 +39,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.8 dosfstools-2.10/mkdosfs/mkdosfs
  .B \-n
  .I volume-name
  ]
-@@ -155,6 +159,18 @@
+@@ -165,6 +169,18 @@
  carriage return-line feed combinations, and tabs have been expanded.
  If the filename is a hyphen (-), the text is taken from standard input. 
  .TP
@@ -49,21 +58,22 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.8 dosfstools-2.10/mkdosfs/mkdosfs
  .BI \-n " volume-name"
  Sets the volume name (label) of the filesystem.  The volume name can
  be up to 11 characters long.  The default is no label.
-@@ -188,8 +204,9 @@
+@@ -198,8 +214,9 @@
  simply will not support it ;)
  .SH AUTHOR
  Dave Hudson - <dave@humbug.demon.co.uk>; modified by Peter Anvin
 -<hpa@yggdrasil.com>. Fixes and additions by Roman Hodek
--<Roman.Hodek@informatik.uni-erlangen.de> for Debian/GNU Linux.
+-<roman@hodek.net> for Debian/GNU Linux.
 +<hpa@yggdrasil.com> and Sam Bingner <sam@bingner.com>. Fixes and
 +additions by Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
 +for Debian/GNU Linux.
  .SH ACKNOWLEDGEMENTS
  .B mkdosfs
  is based on code from
-diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs.c
---- dosfstools-2.10.orig/mkdosfs/mkdosfs.c	2003-06-14 13:07:08.000000000 -0700
-+++ dosfstools-2.10/mkdosfs/mkdosfs.c	2004-08-02 20:57:57.736939512 -0700
+Index: dosfstools-2.11/mkdosfs/mkdosfs.c
+===================================================================
+--- dosfstools-2.11.orig/mkdosfs/mkdosfs.c	2005-03-12 16:12:16.000000000 +0000
++++ dosfstools-2.11/mkdosfs/mkdosfs.c	2011-12-06 12:27:55.121886076 +0000
 @@ -24,6 +24,12 @@
     - New options -A, -S, -C
     - Support for filesystems > 2GB
@@ -77,7 +87,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
     
     Copying:     Copyright 1993, 1994 David Hudson (dave@humbug.demon.co.uk)
  
-@@ -167,6 +173,8 @@
+@@ -153,6 +159,8 @@
  #define FAT_BAD      0x0ffffff7
  
  #define MSDOS_EXT_SIGN 0x29	/* extended boot sector signature */
@@ -86,7 +96,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  #define MSDOS_FAT12_SIGN "FAT12   "	/* FAT12 filesystem signature */
  #define MSDOS_FAT16_SIGN "FAT16   "	/* FAT16 filesystem signature */
  #define MSDOS_FAT32_SIGN "FAT32   "	/* FAT32 filesystem signature */
-@@ -188,6 +196,8 @@
+@@ -175,6 +183,8 @@
  #define BOOTCODE_SIZE		448
  #define BOOTCODE_FAT32_SIZE	420
  
@@ -95,7 +105,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  /* __attribute__ ((packed)) is used on all structures to make gcc ignore any
   * alignments */
  
-@@ -215,7 +225,7 @@
+@@ -202,7 +212,7 @@
    __u16         fat_length;	/* sectors/FAT */
    __u16         secs_track;	/* sectors per track */
    __u16         heads;		/* number of heads */
@@ -104,7 +114,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
    __u32         total_sect;	/* number of sectors (if sectors == 0) */
    union {
      struct {
-@@ -298,6 +308,8 @@
+@@ -285,6 +295,8 @@
  
  /* Global variables - the root of all evil :-) - see these and weep! */
  
@@ -113,7 +123,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  static char *program_name = "mkdosfs";	/* Name of the program */
  static char *device_name = NULL;	/* Name of the device on which to create the filesystem */
  static int atari_format = 0;	/* Use Atari variation of MS-DOS FS format */
-@@ -842,6 +854,12 @@
+@@ -837,6 +849,12 @@
      vi->volume_id[2] = (unsigned char) ((volume_id & 0x00ff0000) >> 16);
      vi->volume_id[3] = (unsigned char) (volume_id >> 24);
    }
@@ -126,16 +136,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  
    if (!atari_format) {
      memcpy(vi->volume_label, volume_name, 11);
-@@ -886,7 +904,7 @@
-     printf( "Using %d reserved sectors\n", reserved_sectors );
-   bs.fats = (char) nr_fats;
-   if (!atari_format || size_fat == 32)
--    bs.hidden = CT_LE_L(0);
-+    bs.hidden = bs.secs_track;
-   else
-     /* In Atari format, hidden is a 16 bit field */
-     memset( &bs.hidden, 0, 2 );
-@@ -1358,6 +1376,32 @@
+@@ -1362,6 +1380,32 @@
     * dir area on FAT12/16, and the first cluster on FAT32. */
    writebuf( (char *) root_dir, size_root_dir, "root directory" );
  
@@ -149,9 +150,9 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
 +      seekto( 512*2, "third sector" );
 +      if (backup_boot != 0) {
 +        writebuf( template_boot_code+512*2, backup_boot*sector_size - 512*2, "data to backup boot" );
-+	seekto( backup_boot*sector_size, "backup boot sector" );
++        seekto( backup_boot*sector_size, "backup boot sector" );
 +        writebuf( template_boot_code, 3, "backup jmpBoot" );
-+	seekto( backup_boot*sector_size+0x5a, "backup boot sector boot area" );
++        seekto( backup_boot*sector_size+0x5a, "backup boot sector boot area" );
 +        writebuf( template_boot_code+0x5a, 420, "backup boot sector boot area" );
 +        seekto( (backup_boot+2)*sector_size, "sector following backup code" );
 +        writebuf( template_boot_code+(backup_boot+2)*sector_size, (reserved_sectors-backup_boot-2)*512, "remaining data" );
@@ -165,28 +166,28 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
 +    }
 +  }
 +
+   if (blank_sector) free( blank_sector );
    if (info_sector) free( info_sector );
    free (root_dir);   /* Free up the root directory space from setup_tables */
-   free (fat);  /* Free up the fat table space reserved during setup_tables */
-@@ -1371,7 +1415,7 @@
+@@ -1376,7 +1420,7 @@
  {
    fatal_error("\
  Usage: mkdosfs [-A] [-c] [-C] [-v] [-I] [-l bad-block-file] [-b backup-boot-sector]\n\
 -       [-m boot-msg-file] [-n volume-name] [-i volume-id]\n\
 +       [-m boot-msg-file] [-n volume-name] [-i volume-id] [-B bootcode]\n\
         [-s sectors-per-cluster] [-S logical-sector-size] [-f number-of-FATs]\n\
-        [-F fat-size] [-r root-dir-entries] [-R reserved-sectors]\n\
+        [-h hidden-sectors] [-F fat-size] [-r root-dir-entries] [-R reserved-sectors]\n\
         /dev/name [blocks]\n");
-@@ -1433,7 +1477,7 @@
+@@ -1439,7 +1483,7 @@
    printf ("%s " VERSION " (" VERSION_DATE ")\n",
  	   program_name);
  
--  while ((c = getopt (argc, argv, "AcCf:F:Ii:l:m:n:r:R:s:S:v")) != EOF)
-+  while ((c = getopt (argc, argv, "AcCf:F:Ii:l:m:n:r:R:s:S:v:B:b")) != EOF)
+-  while ((c = getopt (argc, argv, "AbcCf:F:Ii:l:m:n:r:R:s:S:h:v")) != EOF)
++  while ((c = getopt (argc, argv, "AbcCf:F:Ii:l:m:n:r:R:s:S:v:B:")) != EOF)
      /* Scan the command line for options */
      switch (c)
        {
-@@ -1494,6 +1538,51 @@
+@@ -1509,6 +1553,51 @@
  	listfile = optarg;
  	break;
  

meta/recipes-devtools/dosfstools/dosfstools/mkdosfs-dir.patch

@@ -1,6 +1,14 @@
-diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs.c
---- dosfstools-2.10.orig/mkdosfs/mkdosfs.c	2004-08-02 20:48:45.000000000 -0700
-+++ dosfstools-2.10/mkdosfs/mkdosfs.c	2004-08-02 20:49:44.296953792 -0700
+Add -d <directory> support to populate the image.
+
+Upstream-Status: Inappropriate [licensing]
+We're tracking an old release of dosfstools due to licensing issues.
+
+Signed-off-by: Scott Garman <scott.a.garman@intel.com>
+
+Index: dosfstools-2.11/mkdosfs/mkdosfs.c
+===================================================================
+--- dosfstools-2.11.orig/mkdosfs/mkdosfs.c	2011-12-06 12:27:55.000000000 +0000
++++ dosfstools-2.11/mkdosfs/mkdosfs.c	2011-12-06 12:37:13.445950703 +0000
 @@ -18,6 +18,10 @@
     as a rule), and not the block.  For example the boot block does not
     occupy a full cluster.
@@ -19,18 +27,18 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
 +#include <libgen.h>
 +#include <dirent.h>
  
- #if __BYTE_ORDER == __BIG_ENDIAN
- 
-@@ -124,6 +130,8 @@
- }
- #endif
+ #include <linux/version.h>
+ #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
+@@ -110,6 +116,8 @@
+  * sufficient (or even better :) for 64 bit offsets in the meantime */
+ #define llseek lseek
  
 +#define ROUND_UP(value, divisor) (value + (divisor - (value % divisor))) / divisor
 +
  /* Constant definitions */
  
  #define TRUE 1			/* Boolean constants */
-@@ -163,7 +171,6 @@
+@@ -149,7 +157,6 @@
  #define ATTR_VOLUME  8		/* volume label */
  #define ATTR_DIR     16		/* directory */
  #define ATTR_ARCH    32		/* archived */
@@ -38,7 +46,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  #define ATTR_NONE    0		/* no attribute bits */
  #define ATTR_UNUSED  (ATTR_VOLUME | ATTR_ARCH | ATTR_SYS | ATTR_HIDDEN)
  	/* attribute bits that are copied "as is" */
-@@ -258,6 +265,19 @@
+@@ -245,6 +252,19 @@
    __u32		reserved2[4];
  };
  
@@ -58,7 +66,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  struct msdos_dir_entry
    {
      char	name[8], ext[3];	/* name and extension */
-@@ -306,6 +326,15 @@
+@@ -293,6 +313,15 @@
  
  #define MESSAGE_OFFSET 29	/* Offset of message in above code */
  
@@ -74,7 +82,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  /* Global variables - the root of all evil :-) - see these and weep! */
  
  static char *template_boot_code;	/* Variable to store a full template boot sector in */
-@@ -339,6 +368,9 @@
+@@ -326,6 +355,9 @@
  static int size_root_dir;	/* Size of the root directory in bytes */
  static int sectors_per_cluster = 0;	/* Number of sectors per disk cluster */
  static int root_dir_entries = 0;	/* Number of root directory entries */
@@ -82,9 +90,9 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
 +static int last_cluster_written = 0;
 +
  static char *blank_sector;		/* Blank sector - all zeros */
+ static int hidden_sectors = 0;		/* Number of hidden sectors */
  
- 
-@@ -411,7 +443,6 @@
+@@ -399,7 +431,6 @@
    }
  }
  
@@ -92,7 +100,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  /* Mark a specified sector as having a particular value in it's FAT entry */
  
  static void
-@@ -1262,6 +1293,9 @@
+@@ -1266,6 +1297,9 @@
        die ("unable to allocate space for root directory in memory");
      }
  
@@ -102,7 +110,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
    memset(root_dir, 0, size_root_dir);
    if ( memcmp(volume_name, "           ", 11) )
      {
-@@ -1310,11 +1344,11 @@
+@@ -1314,11 +1348,11 @@
    }
    
    if (!(blank_sector = malloc( sector_size )))
@@ -117,7 +125,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  /* Write the new filesystem's data tables to wherever they're going to end up! */
  
  #define error(str)				\
-@@ -1336,7 +1370,7 @@
+@@ -1340,7 +1374,7 @@
    do {							\
      int __size = (size);				\
      if (write (dev, buf, __size) != __size)		\
@@ -126,7 +134,7 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
    } while(0)
  
  
-@@ -1407,6 +1441,452 @@
+@@ -1412,6 +1446,452 @@
    free (fat);  /* Free up the fat table space reserved during setup_tables */
  }
  
@@ -579,19 +587,16 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
  
  /* Report the command usage and return a failure error code */
  
-@@ -1418,9 +1898,9 @@
+@@ -1423,7 +1903,7 @@
         [-m boot-msg-file] [-n volume-name] [-i volume-id] [-B bootcode]\n\
         [-s sectors-per-cluster] [-S logical-sector-size] [-f number-of-FATs]\n\
-        [-F fat-size] [-r root-dir-entries] [-R reserved-sectors]\n\
+        [-h hidden-sectors] [-F fat-size] [-r root-dir-entries] [-R reserved-sectors]\n\
 -       /dev/name [blocks]\n");
 +       [-d directory] /dev/name [blocks]\n");
  }
--
-+	
+ 
  /*
-  * ++roman: On m68k, check if this is an Atari; if yes, turn on Atari variant
-  * of MS-DOS filesystem by default.
-@@ -1458,6 +1938,8 @@
+@@ -1463,6 +1943,8 @@
    int c;
    char *tmp;
    char *listfile = NULL;
@@ -600,27 +605,27 @@ diff -urN dosfstools-2.10.orig/mkdosfs/mkdosfs.c dosfstools-2.10/mkdosfs/mkdosfs
    FILE *msgfile;
    struct stat statbuf;
    int i = 0, pos, ch;
-@@ -1477,7 +1959,7 @@
+@@ -1483,7 +1965,7 @@
    printf ("%s " VERSION " (" VERSION_DATE ")\n",
  	   program_name);
  
--  while ((c = getopt (argc, argv, "AcCf:F:Ii:l:m:n:r:R:s:S:v:B:b")) != EOF)
-+  while ((c = getopt (argc, argv, "AcCd:f:F:Ii:l:m:n:r:R:s:S:v:B:b")) != EOF)
+-  while ((c = getopt (argc, argv, "AbcCf:F:Ii:l:m:n:r:R:s:S:v:B:")) != EOF)
++  while ((c = getopt (argc, argv, "AbcCd:f:F:Ii:l:m:n:r:R:s:S:v:B:")) != EOF)
      /* Scan the command line for options */
      switch (c)
        {
-@@ -1502,6 +1984,10 @@
+@@ -1508,6 +1990,10 @@
  	create = TRUE;
  	break;
  
-+      case 'd':
++  case 'd':
 +	dirname = optarg;
 +	break;
 +
        case 'f':		/* f : Choose number of FATs */
  	nr_fats = (int) strtol (optarg, &tmp, 0);
  	if (*tmp || nr_fats < 1 || nr_fats > 4)
-@@ -1796,8 +2282,10 @@
+@@ -1811,8 +2297,10 @@
    else if (listfile)
      get_list_blocks (listfile);
  

meta/recipes-devtools/dosfstools/dosfstools/msdos_fat12_undefined.patch

@@ -1,3 +1,10 @@
+Fix a compilation error due to undefined MSDOS_FAT12.
+
+Upstream-Status: Inappropriate [licensing]
+We're tracking an old release of dosfstools due to licensing issues.
+
+Signed-off-by: Scott Garman <scott.a.garman@intel.com>
+
 --- dosfstools-2.10/dosfsck/boot.c.orig	2004-10-15 08:51:42.394725176 -0600
 +++ dosfstools-2.10/dosfsck/boot.c	2004-10-15 08:49:16.776862456 -0600
 @@ -14,6 +14,9 @@

meta/recipes-devtools/dosfstools/dosfstools/nofat32_autoselect.patch

@@ -0,0 +1,27 @@
+FAT32 appears to be broken when used with the -d option to populate the msdos
+image. This disables the FAT32 autoselection code which means we don't get
+broken images with the -d option. It can still be enabled on the commandline
+at the users own risk. This changes us back to the 2.10 version's behaviour
+which was known to work well even with large images.
+
+Upstream Status: Inapprioriate [depends on other patches we apply]
+
+RP 2011/12/13
+
+Index: dosfstools-2.11/mkdosfs/mkdosfs.c
+===================================================================
+--- dosfstools-2.11.orig/mkdosfs/mkdosfs.c	2011-12-13 13:54:37.538509391 +0000
++++ dosfstools-2.11/mkdosfs/mkdosfs.c	2011-12-13 13:55:10.258508631 +0000
+@@ -808,10 +808,12 @@
+       bs.media = (char) 0xf8; /* Set up the media descriptor for a hard drive */
+       bs.dir_entries[0] = (char) 0;	/* Default to 512 entries */
+       bs.dir_entries[1] = (char) 2;
++/*
+       if (!size_fat && blocks*SECTORS_PER_BLOCK > 1064960) {
+ 	  if (verbose) printf("Auto-selecting FAT32 for large filesystem\n");
+ 	  size_fat = 32;
+       }
++*/
+       if (size_fat == 32) {
+ 	  /* For FAT32, try to do the same as M$'s format command:
+ 	   * fs size < 256M: 0.5k clusters

meta/recipes-devtools/dosfstools/dosfstools_2.10.bb

@@ -1,21 +0,0 @@
-# dosfstools OE build file
-# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights Reserved
-# Released under the MIT license (see packages/COPYING)
-
-DESCRIPTION = "DOS FAT Filesystem Utilities"
-
-SECTION = "base"
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://mkdosfs/COPYING;md5=cbe67f08d6883bff587f615f0cc81aa8"
-PR = "r2"
-
-SRC_URI = "ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-${PV}.src.tar.gz \
-	   file://alignment_hack.patch \
-	   file://dosfstools-2.10-kernel-2.6.patch \
-           file://msdos_fat12_undefined.patch \
-	   file://include-linux-types.patch"
-
-do_install () {
-	oe_runmake "PREFIX=${D}" "SBINDIR=${D}${sbindir}" \
-		   "MANDIR=${D}${mandir}/man8" install
-}

meta/recipes-devtools/dosfstools/dosfstools_2.11.bb

@@ -7,12 +7,16 @@ DESCRIPTION = "DOS FAT Filesystem Utilities"
 SECTION = "base"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://mkdosfs/COPYING;md5=cbe67f08d6883bff587f615f0cc81aa8"
-PR = "r0"
+PR = "r3"
 
 SRC_URI = "ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-${PV}.src.tar.gz \
-	   file://alignment_hack.patch \
+           file://mkdosfs-bootcode.patch \
+           file://mkdosfs-dir.patch \
+           file://alignment_hack.patch \
            file://msdos_fat12_undefined.patch \
-	   file://include-linux-types.patch"
+           file://dosfstools-msdos_fs-types.patch \
+           file://include-linux-types.patch \
+           file://nofat32_autoselect.patch "
 
 SRC_URI[md5sum] = "407d405ade410f7597d364ab5dc8c9f6"
 SRC_URI[sha256sum] = "0eac6d12388b3d9ed78684529c1b0d9346fa2abbe406c4d4a3eb5a023c98a484"
@@ -21,3 +25,5 @@ do_install () {
 	oe_runmake "PREFIX=${D}" "SBINDIR=${D}${sbindir}" \
 		   "MANDIR=${D}${mandir}/man8" install
 }
+
+BBCLASSEXTEND = "native"

meta/recipes-devtools/icon-naming-utils/icon-naming-utils-native_0.8.7.bb

@@ -5,6 +5,8 @@ PR = "r3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
 SRC_URI = "http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz"
+SRC_URI[md5sum] = "4abe604721ce2ccb67f451aa7ceb44d6"
+SRC_URI[sha256sum] = "1cb49ce6a04626939893a447da696f20003903d61bd80c6d74d29dd79ca340d2"
 
 S = "${WORKDIR}/icon-naming-utils-${PV}"
 

meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch

@@ -0,0 +1,975 @@
+From a1006762fa6f98750bb77d76dd992cb8ea9f9c99 Mon Sep 17 00:00:00 2001
+Message-Id: <a1006762fa6f98750bb77d76dd992cb8ea9f9c99.1333550572.git.dvhart@linux.intel.com>
+From: "H. Peter Anvin" <hpa@zytor.com>
+Date: Mon, 26 Mar 2012 22:51:09 -0700
+Subject: [PATCH] libinstaller: Avoid using <linux/ext2_fs.h>
+
+Don't use <linux/ext2_fs.h> if we can avoid it.
+
+Upstream-Status: Available in syslinux-4.06-pre3
+
+The ioctl constants have been globalized and moved to <linux/fs.h>.
+Use a private copy of ext2_fs.h from e2fsprogs with the ioctl
+constants removed for the data structures.
+
+Do at least attempt backward compatibility for old kernel headers, but
+no real hope of proper operation there...
+
+Signed-off-by: H. Peter Anvin <hpa@zytor.com>
+
+Massaged into 4.03.
+
+Integrated-by: Darren Hart <dvhart@linux.intel.com>
+---
+ libinstaller/ext2fs/ext2_fs.h |  856 +++++++++++++++++++++++++++++++++++++++++
+ libinstaller/linuxioctl.h     |   29 ++-
+ libinstaller/syslxcom.c       |   12 +-
+ 3 files changed, 886 insertions(+), 11 deletions(-)
+ create mode 100644 libinstaller/ext2fs/ext2_fs.h
+
+Index: syslinux-4.03/libinstaller/ext2fs/ext2_fs.h
+===================================================================
+--- /dev/null
++++ syslinux-4.03/libinstaller/ext2fs/ext2_fs.h
+@@ -0,0 +1,856 @@
++/*
++ *  linux/include/linux/ext2_fs.h
++ *
++ * Copyright (C) 1992, 1993, 1994, 1995
++ * Remy Card (card@masi.ibp.fr)
++ * Laboratoire MASI - Institut Blaise Pascal
++ * Universite Pierre et Marie Curie (Paris VI)
++ *
++ *  from
++ *
++ *  linux/include/linux/minix_fs.h
++ *
++ *  Copyright (C) 1991, 1992  Linus Torvalds
++ */
++
++#ifndef _EXT2FS_EXT2_FS_H
++#define _EXT2FS_EXT2_FS_H
++
++#include <linux/types.h>
++
++/*
++ * The second extended filesystem constants/structures
++ */
++
++/*
++ * Define EXT2FS_DEBUG to produce debug messages
++ */
++#undef EXT2FS_DEBUG
++
++/*
++ * Define EXT2_PREALLOCATE to preallocate data blocks for expanding files
++ */
++#define EXT2_PREALLOCATE
++#define EXT2_DEFAULT_PREALLOC_BLOCKS	8
++
++/*
++ * The second extended file system version
++ */
++#define EXT2FS_DATE		"95/08/09"
++#define EXT2FS_VERSION		"0.5b"
++
++/*
++ * Special inode numbers
++ */
++#define EXT2_BAD_INO		 1	/* Bad blocks inode */
++#define EXT2_ROOT_INO		 2	/* Root inode */
++#define EXT4_USR_QUOTA_INO	 3	/* User quota inode */
++#define EXT4_GRP_QUOTA_INO	 4	/* Group quota inode */
++#define EXT2_BOOT_LOADER_INO	 5	/* Boot loader inode */
++#define EXT2_UNDEL_DIR_INO	 6	/* Undelete directory inode */
++#define EXT2_RESIZE_INO		 7	/* Reserved group descriptors inode */
++#define EXT2_JOURNAL_INO	 8	/* Journal inode */
++#define EXT2_EXCLUDE_INO	 9	/* The "exclude" inode, for snapshots */
++#define EXT4_REPLICA_INO	10	/* Used by non-upstream feature */
++
++/* First non-reserved inode for old ext2 filesystems */
++#define EXT2_GOOD_OLD_FIRST_INO	11
++
++/*
++ * The second extended file system magic number
++ */
++#define EXT2_SUPER_MAGIC	0xEF53
++
++#ifdef __KERNEL__
++#define EXT2_SB(sb)	(&((sb)->u.ext2_sb))
++#else
++/* Assume that user mode programs are passing in an ext2fs superblock, not
++ * a kernel struct super_block.  This will allow us to call the feature-test
++ * macros from user land. */
++#define EXT2_SB(sb)	(sb)
++#endif
++
++/*
++ * Maximal count of links to a file
++ */
++#define EXT2_LINK_MAX		65000
++
++/*
++ * Macro-instructions used to manage several block sizes
++ */
++#define EXT2_MIN_BLOCK_LOG_SIZE		10	/* 1024 */
++#define EXT2_MAX_BLOCK_LOG_SIZE		16	/* 65536 */
++#define EXT2_MIN_BLOCK_SIZE	(1 << EXT2_MIN_BLOCK_LOG_SIZE)
++#define EXT2_MAX_BLOCK_SIZE	(1 << EXT2_MAX_BLOCK_LOG_SIZE)
++#ifdef __KERNEL__
++#define EXT2_BLOCK_SIZE(s)	((s)->s_blocksize)
++#define EXT2_BLOCK_SIZE_BITS(s)	((s)->s_blocksize_bits)
++#define EXT2_ADDR_PER_BLOCK_BITS(s)	(EXT2_SB(s)->addr_per_block_bits)
++#define EXT2_INODE_SIZE(s)	(EXT2_SB(s)->s_inode_size)
++#define EXT2_FIRST_INO(s)	(EXT2_SB(s)->s_first_ino)
++#else
++#define EXT2_BLOCK_SIZE(s)	(EXT2_MIN_BLOCK_SIZE << (s)->s_log_block_size)
++#define EXT2_BLOCK_SIZE_BITS(s)	((s)->s_log_block_size + 10)
++#define EXT2_INODE_SIZE(s)	(((s)->s_rev_level == EXT2_GOOD_OLD_REV) ? \
++				 EXT2_GOOD_OLD_INODE_SIZE : (s)->s_inode_size)
++#define EXT2_FIRST_INO(s)	(((s)->s_rev_level == EXT2_GOOD_OLD_REV) ? \
++				 EXT2_GOOD_OLD_FIRST_INO : (s)->s_first_ino)
++#endif
++#define EXT2_ADDR_PER_BLOCK(s)	(EXT2_BLOCK_SIZE(s) / sizeof(__u32))
++
++/*
++ * Macro-instructions used to manage allocation clusters
++ */
++#define EXT2_MIN_CLUSTER_LOG_SIZE	EXT2_MIN_BLOCK_LOG_SIZE
++#define EXT2_MAX_CLUSTER_LOG_SIZE	29	/* 512MB  */
++#define EXT2_MIN_CLUSTER_SIZE		EXT2_MIN_BLOCK_SIZE
++#define EXT2_MAX_CLUSTER_SIZE		(1 << EXT2_MAX_CLUSTER_LOG_SIZE)
++#define EXT2_CLUSTER_SIZE(s)		(EXT2_MIN_BLOCK_SIZE << \
++						(s)->s_log_cluster_size)
++#define EXT2_CLUSTER_SIZE_BITS(s)	((s)->s_log_cluster_size + 10)
++
++/*
++ * Macro-instructions used to manage fragments
++ *
++ * Note: for backwards compatibility only, for the dump program.
++ * Ext2/3/4 will never support fragments....
++ */
++#define EXT2_MIN_FRAG_SIZE              EXT2_MIN_BLOCK_SIZE
++#define EXT2_MAX_FRAG_SIZE              EXT2_MAX_BLOCK_SIZE
++#define EXT2_MIN_FRAG_LOG_SIZE          EXT2_MIN_BLOCK_LOG_SIZE
++#define EXT2_FRAG_SIZE(s)		EXT2_BLOCK_SIZE(s)
++#define EXT2_FRAGS_PER_BLOCK(s)		1
++
++/*
++ * ACL structures
++ */
++struct ext2_acl_header	/* Header of Access Control Lists */
++{
++	__u32	aclh_size;
++	__u32	aclh_file_count;
++	__u32	aclh_acle_count;
++	__u32	aclh_first_acle;
++};
++
++struct ext2_acl_entry	/* Access Control List Entry */
++{
++	__u32	acle_size;
++	__u16	acle_perms;	/* Access permissions */
++	__u16	acle_type;	/* Type of entry */
++	__u16	acle_tag;	/* User or group identity */
++	__u16	acle_pad1;
++	__u32	acle_next;	/* Pointer on next entry for the */
++					/* same inode or on next free entry */
++};
++
++/*
++ * Structure of a blocks group descriptor
++ */
++struct ext2_group_desc
++{
++	__u32	bg_block_bitmap;	/* Blocks bitmap block */
++	__u32	bg_inode_bitmap;	/* Inodes bitmap block */
++	__u32	bg_inode_table;		/* Inodes table block */
++	__u16	bg_free_blocks_count;	/* Free blocks count */
++	__u16	bg_free_inodes_count;	/* Free inodes count */
++	__u16	bg_used_dirs_count;	/* Directories count */
++	__u16	bg_flags;
++	__u32	bg_exclude_bitmap_lo;	/* Exclude bitmap for snapshots */
++	__u16	bg_block_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap) LSB */
++	__u16	bg_inode_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap) LSB */
++	__u16	bg_itable_unused;	/* Unused inodes count */
++	__u16	bg_checksum;		/* crc16(s_uuid+grouo_num+group_desc)*/
++};
++
++/*
++ * Structure of a blocks group descriptor
++ */
++struct ext4_group_desc
++{
++	__u32	bg_block_bitmap;	/* Blocks bitmap block */
++	__u32	bg_inode_bitmap;	/* Inodes bitmap block */
++	__u32	bg_inode_table;		/* Inodes table block */
++	__u16	bg_free_blocks_count;	/* Free blocks count */
++	__u16	bg_free_inodes_count;	/* Free inodes count */
++	__u16	bg_used_dirs_count;	/* Directories count */
++	__u16	bg_flags;		/* EXT4_BG_flags (INODE_UNINIT, etc) */
++	__u32	bg_exclude_bitmap_lo;	/* Exclude bitmap for snapshots */
++	__u16	bg_block_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap) LSB */
++	__u16	bg_inode_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap) LSB */
++	__u16	bg_itable_unused;	/* Unused inodes count */
++	__u16	bg_checksum;		/* crc16(sb_uuid+group+desc) */
++	__u32	bg_block_bitmap_hi;	/* Blocks bitmap block MSB */
++	__u32	bg_inode_bitmap_hi;	/* Inodes bitmap block MSB */
++	__u32	bg_inode_table_hi;	/* Inodes table block MSB */
++	__u16	bg_free_blocks_count_hi;/* Free blocks count MSB */
++	__u16	bg_free_inodes_count_hi;/* Free inodes count MSB */
++	__u16	bg_used_dirs_count_hi;	/* Directories count MSB */
++	__u16	bg_itable_unused_hi;	/* Unused inodes count MSB */
++	__u32	bg_exclude_bitmap_hi;	/* Exclude bitmap block MSB */
++	__u16	bg_block_bitmap_csum_hi;/* crc32c(s_uuid+grp_num+bitmap) MSB */
++	__u16	bg_inode_bitmap_csum_hi;/* crc32c(s_uuid+grp_num+bitmap) MSB */
++	__u32	bg_reserved;
++};
++
++#define EXT2_BG_INODE_UNINIT	0x0001 /* Inode table/bitmap not initialized */
++#define EXT2_BG_BLOCK_UNINIT	0x0002 /* Block bitmap not initialized */
++#define EXT2_BG_INODE_ZEROED	0x0004 /* On-disk itable initialized to zero */
++
++/*
++ * Data structures used by the directory indexing feature
++ *
++ * Note: all of the multibyte integer fields are little endian.
++ */
++
++/*
++ * Note: dx_root_info is laid out so that if it should somehow get
++ * overlaid by a dirent the two low bits of the hash version will be
++ * zero.  Therefore, the hash version mod 4 should never be 0.
++ * Sincerely, the paranoia department.
++ */
++struct ext2_dx_root_info {
++	__u32 reserved_zero;
++	__u8 hash_version; /* 0 now, 1 at release */
++	__u8 info_length; /* 8 */
++	__u8 indirect_levels;
++	__u8 unused_flags;
++};
++
++#define EXT2_HASH_LEGACY		0
++#define EXT2_HASH_HALF_MD4		1
++#define EXT2_HASH_TEA			2
++#define EXT2_HASH_LEGACY_UNSIGNED	3 /* reserved for userspace lib */
++#define EXT2_HASH_HALF_MD4_UNSIGNED	4 /* reserved for userspace lib */
++#define EXT2_HASH_TEA_UNSIGNED		5 /* reserved for userspace lib */
++
++#define EXT2_HASH_FLAG_INCOMPAT	0x1
++
++struct ext2_dx_entry {
++	__u32 hash;
++	__u32 block;
++};
++
++struct ext2_dx_countlimit {
++	__u16 limit;
++	__u16 count;
++};
++
++
++/*
++ * Macro-instructions used to manage group descriptors
++ */
++#define EXT2_MIN_DESC_SIZE             32
++#define EXT2_MIN_DESC_SIZE_64BIT       64
++#define EXT2_MAX_DESC_SIZE             EXT2_MIN_BLOCK_SIZE
++#define EXT2_DESC_SIZE(s)                                                \
++       ((EXT2_SB(s)->s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT) ? \
++	(s)->s_desc_size : EXT2_MIN_DESC_SIZE)
++
++#define EXT2_BLOCKS_PER_GROUP(s)	(EXT2_SB(s)->s_blocks_per_group)
++#define EXT2_INODES_PER_GROUP(s)	(EXT2_SB(s)->s_inodes_per_group)
++#define EXT2_CLUSTERS_PER_GROUP(s)	(EXT2_SB(s)->s_clusters_per_group)
++#define EXT2_INODES_PER_BLOCK(s)	(EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s))
++/* limits imposed by 16-bit value gd_free_{blocks,inode}_count */
++#define EXT2_MAX_BLOCKS_PER_GROUP(s)	((((unsigned) 1 << 16) - 8) *	\
++					 (EXT2_CLUSTER_SIZE(s) / \
++					  EXT2_BLOCK_SIZE(s)))
++#define EXT2_MAX_CLUSTERS_PER_GROUP(s)	(((unsigned) 1 << 16) - 8)
++#define EXT2_MAX_INODES_PER_GROUP(s)	(((unsigned) 1 << 16) - \
++					 EXT2_INODES_PER_BLOCK(s))
++#ifdef __KERNEL__
++#define EXT2_DESC_PER_BLOCK(s)		(EXT2_SB(s)->s_desc_per_block)
++#define EXT2_DESC_PER_BLOCK_BITS(s)	(EXT2_SB(s)->s_desc_per_block_bits)
++#else
++#define EXT2_DESC_PER_BLOCK(s)		(EXT2_BLOCK_SIZE(s) / EXT2_DESC_SIZE(s))
++#endif
++
++/*
++ * Constants relative to the data blocks
++ */
++#define EXT2_NDIR_BLOCKS		12
++#define EXT2_IND_BLOCK			EXT2_NDIR_BLOCKS
++#define EXT2_DIND_BLOCK			(EXT2_IND_BLOCK + 1)
++#define EXT2_TIND_BLOCK			(EXT2_DIND_BLOCK + 1)
++#define EXT2_N_BLOCKS			(EXT2_TIND_BLOCK + 1)
++
++/*
++ * Inode flags
++ */
++#define EXT2_SECRM_FL			0x00000001 /* Secure deletion */
++#define EXT2_UNRM_FL			0x00000002 /* Undelete */
++#define EXT2_COMPR_FL			0x00000004 /* Compress file */
++#define EXT2_SYNC_FL			0x00000008 /* Synchronous updates */
++#define EXT2_IMMUTABLE_FL		0x00000010 /* Immutable file */
++#define EXT2_APPEND_FL			0x00000020 /* writes to file may only append */
++#define EXT2_NODUMP_FL			0x00000040 /* do not dump file */
++#define EXT2_NOATIME_FL			0x00000080 /* do not update atime */
++/* Reserved for compression usage... */
++#define EXT2_DIRTY_FL			0x00000100
++#define EXT2_COMPRBLK_FL		0x00000200 /* One or more compressed clusters */
++#define EXT2_NOCOMPR_FL			0x00000400 /* Access raw compressed data */
++#define EXT2_ECOMPR_FL			0x00000800 /* Compression error */
++/* End compression flags --- maybe not all used */
++#define EXT2_BTREE_FL			0x00001000 /* btree format dir */
++#define EXT2_INDEX_FL			0x00001000 /* hash-indexed directory */
++#define EXT2_IMAGIC_FL			0x00002000
++#define EXT3_JOURNAL_DATA_FL		0x00004000 /* file data should be journaled */
++#define EXT2_NOTAIL_FL			0x00008000 /* file tail should not be merged */
++#define EXT2_DIRSYNC_FL 		0x00010000 /* Synchronous directory modifications */
++#define EXT2_TOPDIR_FL			0x00020000 /* Top of directory hierarchies*/
++#define EXT4_HUGE_FILE_FL               0x00040000 /* Set to each huge file */
++#define EXT4_EXTENTS_FL 		0x00080000 /* Inode uses extents */
++#define EXT4_EA_INODE_FL	        0x00200000 /* Inode used for large EA */
++/* EXT4_EOFBLOCKS_FL 0x00400000 was here */
++#define EXT4_SNAPFILE_FL		0x01000000  /* Inode is a snapshot */
++#define EXT4_SNAPFILE_DELETED_FL	0x04000000  /* Snapshot is being deleted */
++#define EXT4_SNAPFILE_SHRUNK_FL		0x08000000  /* Snapshot shrink has completed */
++#define EXT2_RESERVED_FL		0x80000000 /* reserved for ext2 lib */
++
++#define EXT2_FL_USER_VISIBLE		0x004BDFFF /* User visible flags */
++#define EXT2_FL_USER_MODIFIABLE		0x004B80FF /* User modifiable flags */
++
++/*
++ * ioctl commands
++ */
++
++/* Used for online resize */
++struct ext2_new_group_input {
++	__u32 group;		/* Group number for this data */
++	__u32 block_bitmap;	/* Absolute block number of block bitmap */
++	__u32 inode_bitmap;	/* Absolute block number of inode bitmap */
++	__u32 inode_table;	/* Absolute block number of inode table start */
++	__u32 blocks_count;	/* Total number of blocks in this group */
++	__u16 reserved_blocks;	/* Number of reserved blocks in this group */
++	__u16 unused;		/* Number of reserved GDT blocks in group */
++};
++
++struct ext4_new_group_input {
++	__u32 group;		/* Group number for this data */
++	__u64 block_bitmap;	/* Absolute block number of block bitmap */
++	__u64 inode_bitmap;	/* Absolute block number of inode bitmap */
++	__u64 inode_table;	/* Absolute block number of inode table start */
++	__u32 blocks_count;	/* Total number of blocks in this group */
++	__u16 reserved_blocks;	/* Number of reserved blocks in this group */
++	__u16 unused;
++};
++
++#ifdef __GNU__			/* Needed for the Hurd */
++#define _IOT_ext2_new_group_input _IOT (_IOTS(__u32), 5, _IOTS(__u16), 2, 0, 0)
++#endif
++
++#define EXT2_IOC_GETFLAGS		_IOR('f', 1, long)
++#define EXT2_IOC_SETFLAGS		_IOW('f', 2, long)
++#define EXT2_IOC_GETVERSION		_IOR('v', 1, long)
++#define EXT2_IOC_SETVERSION		_IOW('v', 2, long)
++#define EXT2_IOC_GETVERSION_NEW		_IOR('f', 3, long)
++#define EXT2_IOC_SETVERSION_NEW		_IOW('f', 4, long)
++#define EXT2_IOC_GROUP_EXTEND		_IOW('f', 7, unsigned long)
++#define EXT2_IOC_GROUP_ADD		_IOW('f', 8,struct ext2_new_group_input)
++#define EXT4_IOC_GROUP_ADD		_IOW('f', 8,struct ext4_new_group_input)
++#define EXT4_IOC_RESIZE_FS		_IOW('f', 16, __u64)
++
++/*
++ * Structure of an inode on the disk
++ */
++struct ext2_inode {
++	__u16	i_mode;		/* File mode */
++	__u16	i_uid;		/* Low 16 bits of Owner Uid */
++	__u32	i_size;		/* Size in bytes */
++	__u32	i_atime;	/* Access time */
++	__u32	i_ctime;	/* Inode change time */
++	__u32	i_mtime;	/* Modification time */
++	__u32	i_dtime;	/* Deletion Time */
++	__u16	i_gid;		/* Low 16 bits of Group Id */
++	__u16	i_links_count;	/* Links count */
++	__u32	i_blocks;	/* Blocks count */
++	__u32	i_flags;	/* File flags */
++	union {
++		struct {
++			__u32	l_i_version; /* was l_i_reserved1 */
++		} linux1;
++		struct {
++			__u32  h_i_translator;
++		} hurd1;
++	} osd1;				/* OS dependent 1 */
++	__u32	i_block[EXT2_N_BLOCKS];/* Pointers to blocks */
++	__u32	i_generation;	/* File version (for NFS) */
++	__u32	i_file_acl;	/* File ACL */
++	__u32	i_size_high;	/* Formerly i_dir_acl, directory ACL */
++	__u32	i_faddr;	/* Fragment address */
++	union {
++		struct {
++			__u16	l_i_blocks_hi;
++			__u16	l_i_file_acl_high;
++			__u16	l_i_uid_high;	/* these 2 fields    */
++			__u16	l_i_gid_high;	/* were reserved2[0] */
++			__u16	l_i_checksum_lo; /* crc32c(uuid+inum+inode) */
++			__u16	l_i_reserved;
++		} linux2;
++		struct {
++			__u8	h_i_frag;	/* Fragment number */
++			__u8	h_i_fsize;	/* Fragment size */
++			__u16	h_i_mode_high;
++			__u16	h_i_uid_high;
++			__u16	h_i_gid_high;
++			__u32	h_i_author;
++		} hurd2;
++	} osd2;				/* OS dependent 2 */
++};
++
++/*
++ * Permanent part of an large inode on the disk
++ */
++struct ext2_inode_large {
++	__u16	i_mode;		/* File mode */
++	__u16	i_uid;		/* Low 16 bits of Owner Uid */
++	__u32	i_size;		/* Size in bytes */
++	__u32	i_atime;	/* Access time */
++	__u32	i_ctime;	/* Inode Change time */
++	__u32	i_mtime;	/* Modification time */
++	__u32	i_dtime;	/* Deletion Time */
++	__u16	i_gid;		/* Low 16 bits of Group Id */
++	__u16	i_links_count;	/* Links count */
++	__u32	i_blocks;	/* Blocks count */
++	__u32	i_flags;	/* File flags */
++	union {
++		struct {
++			__u32	l_i_version; /* was l_i_reserved1 */
++		} linux1;
++		struct {
++			__u32  h_i_translator;
++		} hurd1;
++	} osd1;				/* OS dependent 1 */
++	__u32	i_block[EXT2_N_BLOCKS];/* Pointers to blocks */
++	__u32	i_generation;	/* File version (for NFS) */
++	__u32	i_file_acl;	/* File ACL */
++	__u32	i_size_high;	/* Formerly i_dir_acl, directory ACL */
++	__u32	i_faddr;	/* Fragment address */
++	union {
++		struct {
++			__u16	l_i_blocks_hi;
++			__u16	l_i_file_acl_high;
++			__u16	l_i_uid_high;	/* these 2 fields    */
++			__u16	l_i_gid_high;	/* were reserved2[0] */
++			__u16	l_i_checksum_lo; /* crc32c(uuid+inum+inode) */
++			__u16	l_i_reserved;
++		} linux2;
++		struct {
++			__u8	h_i_frag;	/* Fragment number */
++			__u8	h_i_fsize;	/* Fragment size */
++			__u16	h_i_mode_high;
++			__u16	h_i_uid_high;
++			__u16	h_i_gid_high;
++			__u32	h_i_author;
++		} hurd2;
++	} osd2;				/* OS dependent 2 */
++	__u16	i_extra_isize;
++	__u16	i_checksum_hi;	/* crc32c(uuid+inum+inode) */
++	__u32	i_ctime_extra;	/* extra Change time (nsec << 2 | epoch) */
++	__u32	i_mtime_extra;	/* extra Modification time (nsec << 2 | epoch) */
++	__u32	i_atime_extra;	/* extra Access time (nsec << 2 | epoch) */
++	__u32	i_crtime;	/* File creation time */
++	__u32	i_crtime_extra;	/* extra File creation time (nsec << 2 | epoch)*/
++	__u32	i_version_hi;	/* high 32 bits for 64-bit version */
++};
++
++#define i_dir_acl	i_size_high
++
++#if defined(__KERNEL__) || defined(__linux__)
++#define i_reserved1	osd1.linux1.l_i_reserved1
++#define i_frag		osd2.linux2.l_i_frag
++#define i_fsize		osd2.linux2.l_i_fsize
++#define i_uid_low	i_uid
++#define i_gid_low	i_gid
++#define i_uid_high	osd2.linux2.l_i_uid_high
++#define i_gid_high	osd2.linux2.l_i_gid_high
++#else
++#if defined(__GNU__)
++
++#define i_translator	osd1.hurd1.h_i_translator
++#define i_frag		osd2.hurd2.h_i_frag;
++#define i_fsize		osd2.hurd2.h_i_fsize;
++#define i_uid_high	osd2.hurd2.h_i_uid_high
++#define i_gid_high	osd2.hurd2.h_i_gid_high
++#define i_author	osd2.hurd2.h_i_author
++
++#endif  /* __GNU__ */
++#endif	/* defined(__KERNEL__) || defined(__linux__) */
++
++#define inode_uid(inode)	((inode).i_uid | (inode).osd2.linux2.l_i_uid_high << 16)
++#define inode_gid(inode)	((inode).i_gid | (inode).osd2.linux2.l_i_gid_high << 16)
++#define ext2fs_set_i_uid_high(inode,x) ((inode).osd2.linux2.l_i_uid_high = (x))
++#define ext2fs_set_i_gid_high(inode,x) ((inode).osd2.linux2.l_i_gid_high = (x))
++
++/*
++ * File system states
++ */
++#define EXT2_VALID_FS			0x0001	/* Unmounted cleanly */
++#define EXT2_ERROR_FS			0x0002	/* Errors detected */
++#define EXT3_ORPHAN_FS			0x0004	/* Orphans being recovered */
++
++/*
++ * Misc. filesystem flags
++ */
++#define EXT2_FLAGS_SIGNED_HASH		0x0001  /* Signed dirhash in use */
++#define EXT2_FLAGS_UNSIGNED_HASH	0x0002  /* Unsigned dirhash in use */
++#define EXT2_FLAGS_TEST_FILESYS		0x0004	/* OK for use on development code */
++#define EXT2_FLAGS_IS_SNAPSHOT		0x0010	/* This is a snapshot image */
++#define EXT2_FLAGS_FIX_SNAPSHOT		0x0020	/* Snapshot inodes corrupted */
++#define EXT2_FLAGS_FIX_EXCLUDE		0x0040	/* Exclude bitmaps corrupted */
++
++/*
++ * Mount flags
++ */
++#define EXT2_MOUNT_CHECK		0x0001	/* Do mount-time checks */
++#define EXT2_MOUNT_GRPID		0x0004	/* Create files with directory's group */
++#define EXT2_MOUNT_DEBUG		0x0008	/* Some debugging messages */
++#define EXT2_MOUNT_ERRORS_CONT		0x0010	/* Continue on errors */
++#define EXT2_MOUNT_ERRORS_RO		0x0020	/* Remount fs ro on errors */
++#define EXT2_MOUNT_ERRORS_PANIC		0x0040	/* Panic on errors */
++#define EXT2_MOUNT_MINIX_DF		0x0080	/* Mimics the Minix statfs */
++#define EXT2_MOUNT_NO_UID32		0x0200  /* Disable 32-bit UIDs */
++
++#define clear_opt(o, opt)		o &= ~EXT2_MOUNT_##opt
++#define set_opt(o, opt)			o |= EXT2_MOUNT_##opt
++#define test_opt(sb, opt)		(EXT2_SB(sb)->s_mount_opt & \
++					 EXT2_MOUNT_##opt)
++/*
++ * Maximal mount counts between two filesystem checks
++ */
++#define EXT2_DFL_MAX_MNT_COUNT		20	/* Allow 20 mounts */
++#define EXT2_DFL_CHECKINTERVAL		0	/* Don't use interval check */
++
++/*
++ * Behaviour when detecting errors
++ */
++#define EXT2_ERRORS_CONTINUE		1	/* Continue execution */
++#define EXT2_ERRORS_RO			2	/* Remount fs read-only */
++#define EXT2_ERRORS_PANIC		3	/* Panic */
++#define EXT2_ERRORS_DEFAULT		EXT2_ERRORS_CONTINUE
++
++#if (__GNUC__ >= 4)
++#define ext4_offsetof(TYPE,MEMBER) __builtin_offsetof(TYPE,MEMBER)
++#else
++#define ext4_offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
++#endif
++
++/*
++ * Structure of the super block
++ */
++struct ext2_super_block {
++	__u32	s_inodes_count;		/* Inodes count */
++	__u32	s_blocks_count;		/* Blocks count */
++	__u32	s_r_blocks_count;	/* Reserved blocks count */
++	__u32	s_free_blocks_count;	/* Free blocks count */
++	__u32	s_free_inodes_count;	/* Free inodes count */
++	__u32	s_first_data_block;	/* First Data Block */
++	__u32	s_log_block_size;	/* Block size */
++	__u32	s_log_cluster_size;	/* Allocation cluster size */
++	__u32	s_blocks_per_group;	/* # Blocks per group */
++	__u32	s_clusters_per_group;	/* # Fragments per group */
++	__u32	s_inodes_per_group;	/* # Inodes per group */
++	__u32	s_mtime;		/* Mount time */
++	__u32	s_wtime;		/* Write time */
++	__u16	s_mnt_count;		/* Mount count */
++	__s16	s_max_mnt_count;	/* Maximal mount count */
++	__u16	s_magic;		/* Magic signature */
++	__u16	s_state;		/* File system state */
++	__u16	s_errors;		/* Behaviour when detecting errors */
++	__u16	s_minor_rev_level;	/* minor revision level */
++	__u32	s_lastcheck;		/* time of last check */
++	__u32	s_checkinterval;	/* max. time between checks */
++	__u32	s_creator_os;		/* OS */
++	__u32	s_rev_level;		/* Revision level */
++	__u16	s_def_resuid;		/* Default uid for reserved blocks */
++	__u16	s_def_resgid;		/* Default gid for reserved blocks */
++	/*
++	 * These fields are for EXT2_DYNAMIC_REV superblocks only.
++	 *
++	 * Note: the difference between the compatible feature set and
++	 * the incompatible feature set is that if there is a bit set
++	 * in the incompatible feature set that the kernel doesn't
++	 * know about, it should refuse to mount the filesystem.
++	 *
++	 * e2fsck's requirements are more strict; if it doesn't know
++	 * about a feature in either the compatible or incompatible
++	 * feature set, it must abort and not try to meddle with
++	 * things it doesn't understand...
++	 */
++	__u32	s_first_ino;		/* First non-reserved inode */
++	__u16   s_inode_size;		/* size of inode structure */
++	__u16	s_block_group_nr;	/* block group # of this superblock */
++	__u32	s_feature_compat;	/* compatible feature set */
++	__u32	s_feature_incompat;	/* incompatible feature set */
++	__u32	s_feature_ro_compat;	/* readonly-compatible feature set */
++	__u8	s_uuid[16];		/* 128-bit uuid for volume */
++	char	s_volume_name[16];	/* volume name */
++	char	s_last_mounted[64];	/* directory where last mounted */
++	__u32	s_algorithm_usage_bitmap; /* For compression */
++	/*
++	 * Performance hints.  Directory preallocation should only
++	 * happen if the EXT2_FEATURE_COMPAT_DIR_PREALLOC flag is on.
++	 */
++	__u8	s_prealloc_blocks;	/* Nr of blocks to try to preallocate*/
++	__u8	s_prealloc_dir_blocks;	/* Nr to preallocate for dirs */
++	__u16	s_reserved_gdt_blocks;	/* Per group table for online growth */
++	/*
++	 * Journaling support valid if EXT2_FEATURE_COMPAT_HAS_JOURNAL set.
++	 */
++	__u8	s_journal_uuid[16];	/* uuid of journal superblock */
++	__u32	s_journal_inum;		/* inode number of journal file */
++	__u32	s_journal_dev;		/* device number of journal file */
++	__u32	s_last_orphan;		/* start of list of inodes to delete */
++	__u32	s_hash_seed[4];		/* HTREE hash seed */
++	__u8	s_def_hash_version;	/* Default hash version to use */
++	__u8	s_jnl_backup_type; 	/* Default type of journal backup */
++	__u16	s_desc_size;		/* Group desc. size: INCOMPAT_64BIT */
++	__u32	s_default_mount_opts;
++	__u32	s_first_meta_bg;	/* First metablock group */
++	__u32	s_mkfs_time;		/* When the filesystem was created */
++	__u32	s_jnl_blocks[17]; 	/* Backup of the journal inode */
++	__u32	s_blocks_count_hi;	/* Blocks count high 32bits */
++	__u32	s_r_blocks_count_hi;	/* Reserved blocks count high 32 bits*/
++	__u32	s_free_blocks_hi; 	/* Free blocks count */
++	__u16	s_min_extra_isize;	/* All inodes have at least # bytes */
++	__u16	s_want_extra_isize; 	/* New inodes should reserve # bytes */
++	__u32	s_flags;		/* Miscellaneous flags */
++	__u16   s_raid_stride;		/* RAID stride */
++	__u16   s_mmp_update_interval;  /* # seconds to wait in MMP checking */
++	__u64   s_mmp_block;            /* Block for multi-mount protection */
++	__u32   s_raid_stripe_width;    /* blocks on all data disks (N*stride)*/
++	__u8	s_log_groups_per_flex;	/* FLEX_BG group size */
++	__u8    s_reserved_char_pad;
++	__u16	s_reserved_pad;		/* Padding to next 32bits */
++	__u64	s_kbytes_written;	/* nr of lifetime kilobytes written */
++	__u32	s_snapshot_inum;	/* Inode number of active snapshot */
++	__u32	s_snapshot_id;		/* sequential ID of active snapshot */
++	__u64	s_snapshot_r_blocks_count; /* reserved blocks for active
++					      snapshot's future use */
++	__u32	s_snapshot_list;	/* inode number of the head of the on-disk snapshot list */
++#define EXT4_S_ERR_START ext4_offsetof(struct ext2_super_block, s_error_count)
++	__u32	s_error_count;		/* number of fs errors */
++	__u32	s_first_error_time;	/* first time an error happened */
++	__u32	s_first_error_ino;	/* inode involved in first error */
++	__u64	s_first_error_block;	/* block involved of first error */
++	__u8	s_first_error_func[32];	/* function where the error happened */
++	__u32	s_first_error_line;	/* line number where error happened */
++	__u32	s_last_error_time;	/* most recent time of an error */
++	__u32	s_last_error_ino;	/* inode involved in last error */
++	__u32	s_last_error_line;	/* line number where error happened */
++	__u64	s_last_error_block;	/* block involved of last error */
++	__u8	s_last_error_func[32];	/* function where the error happened */
++#define EXT4_S_ERR_END ext4_offsetof(struct ext2_super_block, s_mount_opts)
++	__u8	s_mount_opts[64];
++	__u32	s_usr_quota_inum;	/* inode number of user quota file */
++	__u32	s_grp_quota_inum;	/* inode number of group quota file */
++	__u32	s_overhead_blocks;	/* overhead blocks/clusters in fs */
++	__u32   s_reserved[108];        /* Padding to the end of the block */
++	__u32	s_checksum;		/* crc32c(superblock) */
++};
++
++#define EXT4_S_ERR_LEN (EXT4_S_ERR_END - EXT4_S_ERR_START)
++
++/*
++ * Codes for operating systems
++ */
++#define EXT2_OS_LINUX		0
++#define EXT2_OS_HURD		1
++#define EXT2_OBSO_OS_MASIX	2
++#define EXT2_OS_FREEBSD		3
++#define EXT2_OS_LITES		4
++
++/*
++ * Revision levels
++ */
++#define EXT2_GOOD_OLD_REV	0	/* The good old (original) format */
++#define EXT2_DYNAMIC_REV	1	/* V2 format w/ dynamic inode sizes */
++
++#define EXT2_CURRENT_REV	EXT2_GOOD_OLD_REV
++#define EXT2_MAX_SUPP_REV	EXT2_DYNAMIC_REV
++
++#define EXT2_GOOD_OLD_INODE_SIZE 128
++
++/*
++ * Journal inode backup types
++ */
++#define EXT3_JNL_BACKUP_BLOCKS	1
++
++/*
++ * Feature set definitions
++ */
++
++#define EXT2_HAS_COMPAT_FEATURE(sb,mask)			\
++	( EXT2_SB(sb)->s_feature_compat & (mask) )
++#define EXT2_HAS_RO_COMPAT_FEATURE(sb,mask)			\
++	( EXT2_SB(sb)->s_feature_ro_compat & (mask) )
++#define EXT2_HAS_INCOMPAT_FEATURE(sb,mask)			\
++	( EXT2_SB(sb)->s_feature_incompat & (mask) )
++
++#define EXT2_FEATURE_COMPAT_DIR_PREALLOC	0x0001
++#define EXT2_FEATURE_COMPAT_IMAGIC_INODES	0x0002
++#define EXT3_FEATURE_COMPAT_HAS_JOURNAL		0x0004
++#define EXT2_FEATURE_COMPAT_EXT_ATTR		0x0008
++#define EXT2_FEATURE_COMPAT_RESIZE_INODE	0x0010
++#define EXT2_FEATURE_COMPAT_DIR_INDEX		0x0020
++#define EXT2_FEATURE_COMPAT_LAZY_BG		0x0040
++/* #define EXT2_FEATURE_COMPAT_EXCLUDE_INODE	0x0080 not used, legacy */
++#define EXT2_FEATURE_COMPAT_EXCLUDE_BITMAP	0x0100
++
++
++#define EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER	0x0001
++#define EXT2_FEATURE_RO_COMPAT_LARGE_FILE	0x0002
++/* #define EXT2_FEATURE_RO_COMPAT_BTREE_DIR	0x0004 not used */
++#define EXT4_FEATURE_RO_COMPAT_HUGE_FILE	0x0008
++#define EXT4_FEATURE_RO_COMPAT_GDT_CSUM		0x0010
++#define EXT4_FEATURE_RO_COMPAT_DIR_NLINK	0x0020
++#define EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE	0x0040
++#define EXT4_FEATURE_RO_COMPAT_HAS_SNAPSHOT	0x0080
++#define EXT4_FEATURE_RO_COMPAT_QUOTA		0x0100
++#define EXT4_FEATURE_RO_COMPAT_BIGALLOC		0x0200
++#define EXT4_FEATURE_RO_COMPAT_METADATA_CSUM	0x0400
++#define EXT4_FEATURE_RO_COMPAT_REPLICA		0x0800
++
++#define EXT2_FEATURE_INCOMPAT_COMPRESSION	0x0001
++#define EXT2_FEATURE_INCOMPAT_FILETYPE		0x0002
++#define EXT3_FEATURE_INCOMPAT_RECOVER		0x0004 /* Needs recovery */
++#define EXT3_FEATURE_INCOMPAT_JOURNAL_DEV	0x0008 /* Journal device */
++#define EXT2_FEATURE_INCOMPAT_META_BG		0x0010
++#define EXT3_FEATURE_INCOMPAT_EXTENTS		0x0040
++#define EXT4_FEATURE_INCOMPAT_64BIT		0x0080
++#define EXT4_FEATURE_INCOMPAT_MMP		0x0100
++#define EXT4_FEATURE_INCOMPAT_FLEX_BG		0x0200
++#define EXT4_FEATURE_INCOMPAT_EA_INODE		0x0400
++#define EXT4_FEATURE_INCOMPAT_DIRDATA		0x1000
++
++#define EXT2_FEATURE_COMPAT_SUPP	0
++#define EXT2_FEATURE_INCOMPAT_SUPP    (EXT2_FEATURE_INCOMPAT_FILETYPE| \
++				       EXT4_FEATURE_INCOMPAT_MMP)
++#define EXT2_FEATURE_RO_COMPAT_SUPP	(EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER| \
++					 EXT2_FEATURE_RO_COMPAT_LARGE_FILE| \
++					 EXT4_FEATURE_RO_COMPAT_DIR_NLINK| \
++					 EXT2_FEATURE_RO_COMPAT_BTREE_DIR)
++
++/*
++ * Default values for user and/or group using reserved blocks
++ */
++#define EXT2_DEF_RESUID		0
++#define EXT2_DEF_RESGID		0
++
++/*
++ * Default mount options
++ */
++#define EXT2_DEFM_DEBUG		0x0001
++#define EXT2_DEFM_BSDGROUPS	0x0002
++#define EXT2_DEFM_XATTR_USER	0x0004
++#define EXT2_DEFM_ACL		0x0008
++#define EXT2_DEFM_UID16		0x0010
++#define EXT3_DEFM_JMODE		0x0060
++#define EXT3_DEFM_JMODE_DATA	0x0020
++#define EXT3_DEFM_JMODE_ORDERED	0x0040
++#define EXT3_DEFM_JMODE_WBACK	0x0060
++#define EXT4_DEFM_NOBARRIER	0x0100
++#define EXT4_DEFM_BLOCK_VALIDITY 0x0200
++#define EXT4_DEFM_DISCARD	0x0400
++#define EXT4_DEFM_NODELALLOC	0x0800
++
++/*
++ * Structure of a directory entry
++ */
++#define EXT2_NAME_LEN 255
++
++struct ext2_dir_entry {
++	__u32	inode;			/* Inode number */
++	__u16	rec_len;		/* Directory entry length */
++	__u16	name_len;		/* Name length */
++	char	name[EXT2_NAME_LEN];	/* File name */
++};
++
++/*
++ * The new version of the directory entry.  Since EXT2 structures are
++ * stored in intel byte order, and the name_len field could never be
++ * bigger than 255 chars, it's safe to reclaim the extra byte for the
++ * file_type field.
++ */
++struct ext2_dir_entry_2 {
++	__u32	inode;			/* Inode number */
++	__u16	rec_len;		/* Directory entry length */
++	__u8	name_len;		/* Name length */
++	__u8	file_type;
++	char	name[EXT2_NAME_LEN];	/* File name */
++};
++
++/*
++ * Ext2 directory file types.  Only the low 3 bits are used.  The
++ * other bits are reserved for now.
++ */
++#define EXT2_FT_UNKNOWN		0
++#define EXT2_FT_REG_FILE	1
++#define EXT2_FT_DIR		2
++#define EXT2_FT_CHRDEV		3
++#define EXT2_FT_BLKDEV		4
++#define EXT2_FT_FIFO		5
++#define EXT2_FT_SOCK		6
++#define EXT2_FT_SYMLINK		7
++
++#define EXT2_FT_MAX		8
++
++/*
++ * EXT2_DIR_PAD defines the directory entries boundaries
++ *
++ * NOTE: It must be a multiple of 4
++ */
++#define EXT2_DIR_PAD			4
++#define EXT2_DIR_ROUND			(EXT2_DIR_PAD - 1)
++#define EXT2_DIR_REC_LEN(name_len)	(((name_len) + 8 + EXT2_DIR_ROUND) & \
++					 ~EXT2_DIR_ROUND)
++
++/*
++ * This structure is used for multiple mount protection. It is written
++ * into the block number saved in the s_mmp_block field in the superblock.
++ * Programs that check MMP should assume that if SEQ_FSCK (or any unknown
++ * code above SEQ_MAX) is present then it is NOT safe to use the filesystem,
++ * regardless of how old the timestamp is.
++ *
++ * The timestamp in the MMP structure will be updated by e2fsck at some
++ * arbitary intervals (start of passes, after every few groups of inodes
++ * in pass1 and pass1b).  There is no guarantee that e2fsck is updating
++ * the MMP block in a timely manner, and the updates it does are purely
++ * for the convenience of the sysadmin and not for automatic validation.
++ *
++ * Note: Only the mmp_seq value is used to determine whether the MMP block
++ *	is being updated.  The mmp_time, mmp_nodename, and mmp_bdevname
++ *	fields are only for informational purposes for the administrator,
++ *	due to clock skew between nodes and hostname HA service takeover.
++ */
++#define EXT4_MMP_MAGIC     0x004D4D50U /* ASCII for MMP */
++#define EXT4_MMP_SEQ_CLEAN 0xFF4D4D50U /* mmp_seq value for clean unmount */
++#define EXT4_MMP_SEQ_FSCK  0xE24D4D50U /* mmp_seq value when being fscked */
++#define EXT4_MMP_SEQ_MAX   0xE24D4D4FU /* maximum valid mmp_seq value */
++
++struct mmp_struct {
++	__u32	mmp_magic;		/* Magic number for MMP */
++	__u32	mmp_seq;		/* Sequence no. updated periodically */
++	__u64	mmp_time;		/* Time last updated */
++	char	mmp_nodename[64];	/* Node which last updated MMP block */
++	char	mmp_bdevname[32];	/* Bdev which last updated MMP block */
++	__u16	mmp_check_interval;	/* Changed mmp_check_interval */
++	__u16	mmp_pad1;
++	__u32	mmp_pad2[227];
++};
++
++/*
++ * Default interval for MMP update in seconds.
++ */
++#define EXT4_MMP_UPDATE_INTERVAL	5
++
++/*
++ * Maximum interval for MMP update in seconds.
++ */
++#define EXT4_MMP_MAX_UPDATE_INTERVAL	300
++
++/*
++ * Minimum interval for MMP checking in seconds.
++ */
++#define EXT4_MMP_MIN_CHECK_INTERVAL     5
++
++#endif	/* _EXT2FS_EXT2_FS_H */
+Index: syslinux-4.03/libinstaller/linuxioctl.h
+===================================================================
+--- syslinux-4.03.orig/libinstaller/linuxioctl.h
++++ syslinux-4.03/libinstaller/linuxioctl.h
+@@ -9,17 +9,33 @@
+ 
+ #include <sys/ioctl.h>
+ 
++#ifdef __linux__
++
+ #define statfs _kernel_statfs	/* HACK to deal with broken 2.4 distros */
+ 
+ #include <linux/fd.h>		/* Floppy geometry */
+ #include <linux/hdreg.h>	/* Hard disk geometry */
+ 
+-#include <linux/fs.h>		/* FIGETBSZ, FIBMAP, FS_IOC_FIEMAP */
++#include <linux/fs.h>		/* FIGETBSZ, FIBMAP, FS_IOC_* */
+ #include <linux/msdos_fs.h>	/* FAT_IOCTL_SET_ATTRIBUTES */
+ 
+ #undef SECTOR_SIZE		/* Defined in msdos_fs.h for no good reason */
+ #undef SECTOR_BITS
+-#include <linux/ext2_fs.h>	/* EXT2_IOC_* */
++
++#ifndef FS_IOC_GETFLAGS
++/* Old kernel headers, these were once ext2-specific... */
++# include <linux/ext2_fs.h>	/* EXT2_IOC_* */
++
++# define FS_IOC_GETFLAGS EXT2_IOC_GETFLAGS
++# define FS_IOC_SETFLAGS EXT2_IOC_SETFLAGS
++
++# define FS_IMMUTABLE_FL EXT2_IMMUTABLE_FL
++
++#else
++
++# include <ext2fs/ext2_fs.h>
++
++#endif
+ 
+ #ifndef FAT_IOCTL_GET_ATTRIBUTES
+ # define FAT_IOCTL_GET_ATTRIBUTES	_IOR('r', 0x10, __u32)
+@@ -37,11 +53,13 @@
+ 
+ #undef statfs
+ 
+-#if defined(__linux__) && !defined(BLKGETSIZE64)
++#ifndef  BLKGETSIZE64
+ /* This takes a u64, but the size field says size_t.  Someone screwed big. */
+ # define BLKGETSIZE64 _IOR(0x12,114,size_t)
+ #endif
+ 
+ #include <linux/loop.h>
+ 
++#endif /* __linux__ */
++
+ #endif /* LIBINSTALLER_LINUXIOCTL_H */
+Index: syslinux-4.03/libinstaller/syslxcom.c
+===================================================================
+--- syslinux-4.03.orig/libinstaller/syslxcom.c
++++ syslinux-4.03/libinstaller/syslxcom.c
+@@ -121,9 +121,9 @@ void clear_attributes(int fd)
+ 	{
+ 	    int flags;
+ 
+-	    if (!ioctl(fd, EXT2_IOC_GETFLAGS, &flags)) {
+-		flags &= ~EXT2_IMMUTABLE_FL;
+-		ioctl(fd, EXT2_IOC_SETFLAGS, &flags);
++	    if (!ioctl(fd, FS_IOC_GETFLAGS, &flags)) {
++		flags &= ~FS_IMMUTABLE_FL;
++		ioctl(fd, FS_IOC_SETFLAGS, &flags);
+ 	    }
+ 	    break;
+ 	}
+@@ -151,9 +151,9 @@ void set_attributes(int fd)
+ 	{
+ 	    int flags;
+ 
+-	    if (st.st_uid == 0 && !ioctl(fd, EXT2_IOC_GETFLAGS, &flags)) {
+-		flags |= EXT2_IMMUTABLE_FL;
+-		ioctl(fd, EXT2_IOC_SETFLAGS, &flags);
++	    if (st.st_uid == 0 && !ioctl(fd, FS_IOC_GETFLAGS, &flags)) {
++		flags |= FS_IMMUTABLE_FL;
++		ioctl(fd, FS_IOC_SETFLAGS, &flags);
+ 	    }
+ 	    break;
+ 	}

meta/recipes-devtools/syslinux/syslinux_4.03.bb

@@ -7,10 +7,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
 # If you really want to run syslinux, you need mtools.  We just want the
 # ldlinux.* stuff for now, so skip mtools-native
 DEPENDS = "nasm-native"
-PR = "r2"
+PR = "r3"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/utils/boot/syslinux/syslinux-${PV}.tar.bz2 \
-           file://cross-build.patch"
+           file://cross-build.patch \
+           file://libinstaller-Avoid-using-linux-ext2_fs.h.patch"
 
 SRC_URI[md5sum] = "a7ca38a0a5786b6efae8fb01a1ae8070"
 SRC_URI[sha256sum] = "c65567e324f9d1f7f794ae8f9578a0292bbd47d7b8d895a004d2f0152d0bda38"

meta/recipes-extended/ghostscript/ghostscript_9.02.bb

@@ -40,6 +40,7 @@ EXTRA_OECONF = "--without-x --with-system-libtiff --without-jbig2dec --without-j
 # http://bugs.ghostscript.com/show_bug.cgi?id=692443
 # http://bugs.ghostscript.com/show_bug.cgi?id=692426
 CFLAGS += "-DHAVE_SYS_TIME_H=1"
+BUILD_CFLAGS += "-DHAVE_SYS_TIME_H=1"
 
 inherit autotools
 

scripts/qemuimage-testlib

@@ -83,7 +83,7 @@ Test_SCP()
 	local src=$2
 	local des=$3
 	local tmpfile=`mktemp`
-	local timeout=60
+	local time_out=60
 	local ret=0
 
 	# We use expect to interactive with target by ssh
@@ -109,7 +109,7 @@ Test_SSH()
 	shift
 	local command=$@
 	local tmpfile=`mktemp`
-	local timeout=60
+	local time_out=60
 	local ret=0
 	local exp_cmd=`cat << EOF
 eval spawn ssh -o UserKnownHostsFile=$tmpfile root@$ip_addr "$command"