Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev

5 files changed, 333 insertions, 133 deletions

diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml
index 143cbe0fe7..7ae3ee5ada 100644
--- a/docs/usermanual/chapters/common_use_cases.xml
+++ b/docs/usermanual/chapters/common_use_cases.xml
@@ -105,7 +105,7 @@ SRCDATE = "20061014"
     <section>
         <title>building from unstable source code</title>
         <para>Building against the latest, bleeding-edge source has some intricacies of its own.
-        For one, it is desirable to pin down a souce code revision that is known to build to 
+        For one, it is desirable to pin down a 1 code revision that is known to build to
         prevent random breakage in OE at the most inopportune time for all OE users.  Here is
         how to do that properly.
           <itemizedlist>
@@ -169,7 +169,7 @@ inherit image
       toolchain is in your <command>PATH</command>.</para>
 
       <screen>
-<command>ls</command> pre-built/cross/bin
+$ <command>ls</command> pre-built/cross/bin
 
 arm-linux-g++
 arm-linux-ld
@@ -196,7 +196,7 @@ arm-linux-objdump
       <title>The prebuilt libraries</title>
 
       <para>We need the header files and the libraries itself. The following
-      directory layout is assume. <command>PRE_BUILT</command> has two
+      directory layout is assumed. <command>PRE_BUILT</command> has two
       subdirectories one is called <emphasis>include</emphasis> and holds the
       header files and the other directory is called <emphasis>lib</emphasis>
       and holds the shared and static libraries. Additionally a Qt2 directory
@@ -204,7 +204,7 @@ arm-linux-objdump
       <emphasis>lib</emphasis> sub-directory.</para>
 
       <screen>
-<command>ls</command> $PRE_BUILT
+$ <command>ls</command> $PRE_BUILT
 include
 lib
 qt2
@@ -221,7 +221,7 @@ qt2
       available.</para>
 
       <section>
-        <title>Sourcable script</title>
+        <title>Sourceable script</title>
 
         <para>To ease the usage of OpenEmbedded we start by creating a
         source-able script. This is actually a small variation from the
@@ -379,20 +379,16 @@ NOTE: Couldn't find shared library provider for libm.so.6
 </screen>
 
       <para>OpenEmbedded tries to automatically add run-time dependencies
-      (RDEPENDS) to the package. It uses the <emphasis><link
-      linkend="shlibs">shlibs</link></emphasis> system to do add them, in this
-      case it was not able to find packages providing these libraries as they
-      are prebuilt. This means they will not be added to the RDEPENDS of the
-      just created package. The result can be fatal. If you use OpenEmbedded
-      to create images you will end up with a image without a libc being
-      installed. This will lead to a fatal failure. To workaround this issue
-      you could create a package for the metadata to install every needed
-      library and use ${BOOTSTRAP_EXTRA_RDEPENDS} to make sure this package is
-      installed when creating images.</para>
-      
-      <para>However, the correct way to resolve this is to provide explicit 
-      mapping using ASSUME_SHLIBS variable. For example, for the libraries 
-      above (partial):
+      (RDEPENDS) to generated packages. It is inspecting binaries and
+      libraries and uses the <emphasis><link linkend="shlibs">shlibs</link>
+      </emphasis> system to do add dependencies for the linked libraries,
+      however in this case it was not able to find packages providing these
+      libraries as they were prebuilt.
+      </para>
+
+      <para>One way to resolve this problem is to provide an explicit mapping
+      using the ASSUME_SHLIBS variable in a config file <filename>local.conf</filename>.
+      For example, for the libraries above (partial):
       <screen>
 ASSUME_SHLIBS = "libqtopia2.so.2:qtopia2_2.4 libc.so.6:libc"
 </screen>
@@ -406,4 +402,227 @@ ASSUME_SHLIBS = "libqtopia2.so.2:qtopia2_2.4 libc.so.6:libc"
 
     <para>This section is a stub, help us by expanding it</para>
   </section>
+
+  <section id="commonuse_qte_sdk">
+    <title>Creating Software Development Kits (SDKs)</title>
+
+    <section>
+        <title>What is provided by a SDK</title>
+
+        <para>The Software Development Kit (SDK) should be easy to install and
+        enable your user-base to create binaries and libraries that work on the
+        target hardware.
+        </para>
+
+        <para>To accomplish this goal OpenEmbedded SDKs contain tools for the
+        host and tools for the target hardware. Among these tools is a cross
+        compiler, libraries and header files for additional dependencies, pkg-config
+        files to allow buildsystems to easily find the dependencies, a file with
+        results for autoconf and a script that can be sourced to setup the
+        environment.
+        </para>
+    </section>
+
+    <section>
+        <title>Creating a SDK with your libraries pre-installed</title>
+
+        <section>
+            <title>Preparing the host side</title>
+            <para>Your SDK might need utilities that will run on the
+            host. These could include scripts, buildsystem software like
+            cmake, or an emulator like qemu. For these dependencies it is
+            imported that they <emphasis>inherit sdk</emphasis> and by
+            convention end with <emphasis>-sdk</emphasis> in the
+            <command>PN</command>.
+            </para>
+
+            <para>A new task should be created that will assure that all
+            host utilities will be installed. Place a file called
+            <filename>task-YOUR-toolchain-host.bb</filename> in the
+            <filename>recipes/tasks</filename> directory and place the
+            following content in it:
+<screen>
+require task-sdk-host.bb
+DESCRIPTION = "Host packages for YOUR SDK"
+LICENSE = "MIT"
+ALLOW_EMPTY = "1"
+RDEPENDS_${PN} += "YOUR-DEPENDENCY-sdk"
+</screen>
+            </para>
+        </section>
+
+        <section>
+            <title>Preparing the target side</title>
+            <para>Your SDK should provide your user with header files and libraries
+            he will need when doing application development. In OpenEmbedded the
+            <command>${PN}-dev</command> is providing the header files, pkg-config
+            files and symbolic links to libraries to allow using the library. The SDK
+            should install these development packages to the SDK.
+            </para>
+
+            <para>To install the development packages you will need to create a
+            new task. Create a new file <filename>task-YOUR-toolchain-target.bb</filename>
+            in the <filename>recipes/tasks</filename> directory and place the
+            following content in it:
+<screen>
+DESCRIPTION = "Target package for YOUR SDK"
+LICENSE = "MIT"
+ALLOW_EMPTY = "1"
+
+PR = "r0"
+
+RDEPENDS_${PN} += "\
+        task-sdk-bare \
+        your-lib-dev \
+        your-data
+        "
+</screen>
+            </para>
+        </section>
+
+        <section>
+            <title>Putting it together</title>
+            <para>In the previous two sections we have prepared the host and
+            target side. One thing that is missing is combining the two newly
+            created tasks and actually create the SDK. This is what we are going
+            to do now.</para>
+
+            <para>Create <filename>meta-toolchain-YOU.bb</filename> in the
+            <filename>recipes/meta</filename> directory and place the following
+            content in it:
+<screen>
+PR = "r0"
+TOOLCHAIN_TARGET_TASK = "task-YOUR-toolchain-target"
+TOOLCHAIN_HOST_TASK = "task-YOUR-toolchain-host"
+
+require meta-toolchain.bb
+SDK_SUFFIX = "toolchain-YOUR"
+</screen>
+
+            </para>
+
+            <para>Using <command>bitbake meta-toolchain-YOU</command> the SDK
+            creation should be started and you should find a <filename>sdk</filename>
+            directory inside your deploy directory with a SDK waiting for you. With
+            the above command you still need to have OE configured with your
+            <filename>conf/local.conf</filename> to select the machine and
+            distribution you are targeting.
+            </para>
+
+            <note><para>SDK creation currently does not work with the <emphasis>DISTRO</emphasis>
+            set to <emphasis>micro</emphasis>.</para></note>
+
+            <note><para>If the environment-setup script packaged in the SDK should
+            require more environment look at the <filename>meta-toolchain-qte.bb</filename>
+            to accomplish this.</para></note>
+        </section>
+    </section>
+  </section>
+
+  <section>
+    <title>Creating and Using a Qt Embedded SDK</title>
+
+        <section>
+            <title>Creating the SDK</title>
+
+            <para>The SDK should contain a build of Qt Embedded, but also
+            optional dependencies like directFB, glib-2.0, gstreamer-0.10, tslib
+            and more esoteric dependencies like mysql and postgres. This allows
+            developers to simply start developing using Qt and enables system
+            integrator to easily recompile Qt and base libraries without tracking
+            down extra dependencies.
+            </para>
+
+            <para>OpenEmbedded provides an easy way to create a Qt Embedded
+            SDK. In
+            <filename>recipes/tasks/task-qte-toolchain-host.bb</filename> host
+            tools like moc, uic, rcc, qmake will get installed and in <filename>
+            recipes/tasks/task-qte-toolchain-target.bb</filename> the Qt4 header
+            files and libraries will be installed.
+            </para>
+
+            <para>To build the SDK, setup OpenEmbedded in the usual way by picking
+            a <emphasis>DISTRO</emphasis> and <emphasis>MACHINE</emphasis>. Issue
+            the below command and after the operation finished you should find
+            a SDK in the deployment directory.
+<screen>
+$ <command>bitbake</command> meta-toolchain-qte
+</screen>
+            </para>
+
+            <note><para>The deployment directory depends on the distribution
+            and used C library. In the case of Angstrom and glibc it is
+            located in <filename>tmp/deploy/glibc/sdk</filename>.</para></note>
+
+            <note><para>Change <filename>qt4-embedded.inc</filename> and
+            <filename>qt4.inc</filename> for using different Qt configuration
+            flags. This might include a custom qconfig.h to produce a reduced
+            size build.</para></note>
+
+            <note><para>When distributing the SDK make sure to include a written offer
+            to provide the sourcecode of GPL licensed applications or provide
+            parts of the <filename>sources</filename> folder. The <filename>
+            sources</filename> folder is located right next to the <filename>sdk</filename>
+            one.</para></note>
+        </section>
+
+
+        <section>
+            <title>Using the Qt Embedded SDK</title>
+
+            <para>In this example we are assuming that the target hardware
+            is an armv5t system and the SDK targets the Angstrom Distribution. You
+            should start by downloading the SDK and untar it to the root folder
+            (<filename>/</filename>). Once this operation is finished you will
+            find a new directory <filename>/usr/local/angstrom/arm/</filename> and
+            it contains the <filename>environment-setup</filename> to setup the
+            <emphasis>QMAKESPEC</emphasis> and various other paths.
+            </para>
+
+<screen>
+Untar the SDK once
+$ <command>tar</command> -C / -xjf angstrom-armv5te-linux-gnueabi-toolchain-qte.tar.bz2
+
+Before using it source the environment
+$ <command>.</command> /usr/local/angstrom/arm/environment-setup
+
+Use qmake2 to build software for the target
+$ <command>qmake2</command>
+</screen>
+
+            <para>Creating and building a simple example. We will create a simple
+            Qt Embedded application and use <command>qmake2</command> and
+            <command>make</command> to cross compile.
+
+<screen>
+$ <command>.</command> /usr/local/angstrom/arm/environment-setup
+$ <command>cd</command> $HOME
+$ <command>mkdir</command> qte-example
+$ <command>cd</command> qte-example
+
+$ <command>echo</command> "TEMPLATE=app
+SOURCES=main.cpp
+" > qte-example.pro
+
+$ <command>echo</command> '#include &lt;QApplication&gt;
+#include &lt;QPushButton&gt;
+
+int main(int argc, char** argv) {
+    QApplication app(argc, argv);
+
+    QPushButton btn("Hello World");
+    btn.show();
+    btn.showMaximized();
+
+    return app.exec();
+}
+' > main.cpp
+
+$ <command>qmake2</command>
+$ <command>make</command>
+</screen>
+            </para>
+
+        </section>
+  </section>
 </chapter>
diff --git a/docs/usermanual/chapters/getting_oe.xml b/docs/usermanual/chapters/getting_oe.xml
index 83fbad1fab..e8d1f2cc9d 100644
--- a/docs/usermanual/chapters/getting_oe.xml
+++ b/docs/usermanual/chapters/getting_oe.xml
@@ -22,8 +22,8 @@
 	<para>To create the directory structure:
 
     <screen>
-$ mkdir -p $OEBASE/build/conf
-$ cd $OEBASE</screen>
+$ <command>mkdir</command> -p $OEBASE/build/conf
+$ <command>cd</command> $OEBASE</screen>
 
 	The <literal>$OEBASE/build</literal> directory will contain your
 	local configurations and extensions to the OpenEmbedded system which allow
@@ -50,41 +50,22 @@ $ cd $OEBASE</screen>
     set the PATH variable so that the BitBake tools are accessible (see
     <xref linkend="gettingoe_configuring_oe"/>).</para>
 
-	<section><title>Getting <application>BitBake</application> Using Subversion</title>
-	  <para>To checkout the latest version of the BitBake 1.8 branch, use the
-		following command:
+	<section><title>Downloading a <application>BitBake</application> release</title>
+	  <para>Releases are available from the berlios project website. The current
+          release series is <application>BitBake</application> <emphasis>1.8</emphasis>
+          and the current release is <emphasis>1.8.12</emphasis>. To download execute
+	  the following commands:
 		<screen>
-$ cd $OEBASE
-$ <command>svn</command> co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake
+$ <command>cd</command> $OEBASE
+$ <command>wget</command>http://download.berlios.de/bitbake/bitbake-1.8.12.tar.gz
+$ <command>tar</command> -xvzf bitbake-1.8.12.tar.gz
+$ <command>mv</command> bitbake-1.8.12 bitbake
 </screen>
 	  </para>
 
-	  <para><application>BitBake</application> is checked out now and
+	  <para><application>BitBake</application> is now downloaded and
 		the <varname>$OEBASE</varname> directory will contain
 		a <literal>bitbake/</literal> subdirectory.</para>
-
-	  <para>If you need to access a Subversion server through a proxy, see the
-		<ulink url="http://subversion.tigris.org/faq.html#proxy">SVN FAQ</ulink>
-	  </para>
-	</section>
-
-	<section><title>Updating <application>BitBake</application></title>
-	  <para>Bitbake is being revised fairly often. Periodically it's a good
-		idea to check the repository of bitbake stable branches to see if a
-		new stable branch is available or if the current branch has been
-		revised. Compare your existing bitbake directory with the latest
-		bitbake branch in the repository. Your existing bitbake branch and
-		its 'last changed revision' number can be found as follows:
-
-		<screen>$ cd $OEBASE/bitbake; svn info</screen>
-
-		If there is a new stable branch, you will want to move or delete
-		your existing bitbake directory and repeat the process listed above
-		under "To obtain bitbake". If there is no new branch, it is easy to
-		update bitbake:
-
-		<screen>$ cd $OEBASE/bitbake; svn update</screen>
-	  </para>
 	</section>
   </section>
 
@@ -104,8 +85,8 @@ $ <command>svn</command> co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ b
     <section><title>Checking Out OpenEmbedded With Git</title>
       <para>Once you have installed Git, checkout the OpenEmbedded repository:
         <screen>
-$ cd $OEBASE
-$ git clone git://git.openembedded.org/openembedded</screen>
+$ <command>cd</command> $OEBASE
+$ <command>git</command> clone git://git.openembedded.org/openembedded</screen>
         The <literal>$OEBASE/openembedded/</literal> directory should now
         exist.</para>
     </section>
@@ -117,22 +98,22 @@ $ git clone git://git.openembedded.org/openembedded</screen>
         seems good practice to update your OpenEmbedded tree at least
         daily. To do this, run:
         <screen>
-$ cd $OEBASE
-$ git pull</screen>
+$ <command>cd</command> $OEBASE
+$ <command>git</command> pull</screen>
       </para>
     </section>
     <section><title>Changing Branches</title>
       <para>Working with multiple branches is very easy to do with Git. The
         OpenEmbedded repository holds many branches. To list all branches, use this command:
-        <screen>$ git branch -a</screen>
+        <screen>$ <command>git</command> branch -a</screen>
         Branch names that begin with <literal>origin/</literal> denote
         branches that exist on the remote server. The name with a * in front
         of it is the branch currently checked out. If you want to work with a
         remote branch, you must first create a local copy of it. The following
         command will create a local copy of a remote branch:
-        <screen>$ git branch &lt;local_name&gt; &lt;remote_name&gt;</screen>
+        <screen>$ <command>git</command> branch &lt;local_name&gt; &lt;remote_name&gt;</screen>
         To change branches, use this command:
-        <screen>$ git checkout &lt;branch_name&gt;</screen>
+        <screen>$ <command>git</command> checkout &lt;branch_name&gt;</screen>
         There are more complicated branch operations that can be done with git,
         but those are beyond the scope of this document.</para>
     </section>
@@ -168,12 +149,12 @@ $ git pull</screen>
           <para>If you use a CSH like shell (e.g. on a FreeBSD system), you
             will set environment variables like this:
             <screen>
-$ setenv VAR_NAME "VAR_VALUE"</screen>
+$ <command>setenv</command> VAR_NAME "VAR_VALUE"</screen>
           </para>
         </footnote>, do this:
 
         <screen>
-$ export OEBASE=/path/to/your/oe/installation</screen>
+$ <command>export</command> OEBASE=/path/to/your/oe/installation</screen>
 
       </para>
 
@@ -182,7 +163,7 @@ $ export OEBASE=/path/to/your/oe/installation</screen>
         your <varname>PATH</varname> environment variable like this:
 
         <screen>
-$ export PATH=$OEBASE/bitbake/bin:$PATH</screen>
+$ <command>export</command> PATH=$OEBASE/bitbake/bin:$PATH</screen>
       </para>
 
       <para>In order for bitbake to find the configuration files for
@@ -190,7 +171,7 @@ $ export PATH=$OEBASE/bitbake/bin:$PATH</screen>
         variable.
 
         <screen>
-$ export BBPATH=$OEBASE/build:$OEBASE/openembedded</screen>
+$ <command>export</command> BBPATH=$OEBASE/build:$OEBASE/openembedded</screen>
       </para>
 
       <para>Finally, if you wish to allow BitBake to inherit
@@ -198,7 +179,7 @@ $ export BBPATH=$OEBASE/build:$OEBASE/openembedded</screen>
         need to set the <varname>BB_ENV_EXTRAWHITE</varname> variable:
 
         <screen>
-$ export BB_ENV_EXTRAWHITE="OEBASE"</screen>
+$ <command>export</command> BB_ENV_EXTRAWHITE="OEBASE"</screen>
 
         Note the absence of the "$" character which implies that you are
         setting <varname>BB_ENV_EXTRAWHITE</varname> to the variable name, not
@@ -211,9 +192,9 @@ $ export BB_ENV_EXTRAWHITE="OEBASE"</screen>
         copy the default <filename>local.conf.sample</filename> like this:
 
         <screen>
-$ cd $OEBASE
-$ cp openembedded/conf/local.conf.sample build/conf/local.conf
-$ vi build/conf/local.conf</screen>
+$ <command>cd</command> $OEBASE
+$ <command>cp</command> openembedded/conf/local.conf.sample build/conf/local.conf
+$ <command>vi</command> build/conf/local.conf</screen>
 
         It is actually recommended to start smaller and
         keep <filename>local.conf.sample</filename> in the background. Add
@@ -228,7 +209,7 @@ $ vi build/conf/local.conf</screen>
         the following three
         entries: <varname>BBFILES</varname>, <varname>DISTRO</varname>
         and <varname>MACHINE</varname>. For example, consider the following
-        mininal <literal>local.conf</literal> file for the &Aring;ngstr&ouml;m
+        minimal <literal>local.conf</literal> file for the &Aring;ngstr&ouml;m
         distribution and the Openmoko gta01 machine:
 
         <screen>
@@ -313,7 +294,7 @@ MACHINE = "om-gta01"</screen>
 
         <varlistentry>
           <term><filename>meta/</filename></term>
-          <listitem><para>A collection of usefull meta tasks and recipes that
+          <listitem><para>A collection of useful meta tasks and recipes that
               don't fit in a general category.</para></listitem>
         </varlistentry>
 
diff --git a/docs/usermanual/chapters/metadata.xml b/docs/usermanual/chapters/metadata.xml
index 3e76b2ddbb..c698be961a 100644
--- a/docs/usermanual/chapters/metadata.xml
+++ b/docs/usermanual/chapters/metadata.xml
@@ -67,7 +67,7 @@
         <varlistentry>
           <term><filename>recipes/</filename></term>
           <listitem>
-            <para>Conatins all of the
+            <para>Contains all of the
               <application>BitBake</application> <filename>.bb</filename>
               files. There is a subdirectory for each task or application
               and within that subdirectory is
diff --git a/docs/usermanual/chapters/recipes.xml b/docs/usermanual/chapters/recipes.xml
index 480e8be2b9..74e8e16366 100644
--- a/docs/usermanual/chapters/recipes.xml
+++ b/docs/usermanual/chapters/recipes.xml
@@ -146,7 +146,7 @@ VAR2 = "The version is ${PV}"</screen></para>
         <term>Conditional assignment</term>
 
         <listitem>
-          <para>Conditional assignement is used to assign a value to a
+          <para>Conditional assignment is used to assign a value to a
           variable, but only when the variable is currently unset. This is
           commonly used to provide a default value for use when no specific
           definition is provided by the machine or distro configuration of the
@@ -253,7 +253,7 @@ CFLAGS_prepend += "-I${S}/myincludes2 "</screen>Note also the lack of a space
           <emphasis>oe-stylize.py</emphasis> which can be used to reformat
           your recipes to the correct style. The output will contain a list of
           warnings (to let you know what you did wrong) which should be edited
-          out before using the new file.<screen>contrib/oe-stylize.py myrecipe.bb &gt; fixed-recipe.bb
+          out before using the new file.<screen>$ <command>contrib/oe-stylize.py</command> myrecipe.bb &gt; fixed-recipe.bb
 vi fixed-recipe.bb
 mv fixed.recipe.bb myrecipe.bb</screen></para>
         </listitem>
@@ -1071,9 +1071,9 @@ ${FILE_DIRNAME}/${PN}:${FILE_DIRNAME}/files:${FILE_DIRNAME}"</screen></para>
 
       <para>First we'll create the myhelloworld.c file and a readme file.
       We'll place this in the files subdirectory, which is one of the places
-      that is searched for file:// URIs:<screen>mkdir recipes/myhelloworld
-mkdir recipes/myhelloworld/files
-cat &gt; recipes/myhelloworld/files/myhelloworld.c
+      that is searched for file:// URIs:<screen>$ <command>mkdir</command> recipes/myhelloworld
+$ <command>mkdir</command> recipes/myhelloworld/files
+$ <command>cat</command> &gt; recipes/myhelloworld/files/myhelloworld.c
 #include &lt;stdio.h&gt;
 
 int main(int argc, char** argv)
@@ -1082,7 +1082,7 @@ int main(int argc, char** argv)
         return 0;
 }
 ^D
-cat &gt; recipes/myhelloworld/files/README.txt
+$ <command>cat</command> &gt; recipes/myhelloworld/files/README.txt
 Readme file for myhelloworld.
 ^D</screen></para>
 
@@ -1176,7 +1176,7 @@ PR = "r0"</screen></para>
       </itemizedlist>
 
       <para>We'll consider this release 0 and version 0.1 of a program called
-      helloworld. So we'll name the recipe myhelloworld_0.1.bb:<screen>cat &gt; recipes/myhelloworld/myhelloworld_0.1.bb
+      helloworld. So we'll name the recipe myhelloworld_0.1.bb:<screen>$ <command>cat</command> &gt; recipes/myhelloworld/myhelloworld_0.1.bb
 DESCRIPTION = "Hello world program"
 PR = "r0"
 
@@ -1193,7 +1193,7 @@ do_install() {
         install -m 0644 ${WORKDIR}/README.txt ${D}${docdir}/myhelloworld
 }
 ^D</screen>Now we are ready to build our package, hopefully it'll all work
-      since it's such a simple example:<screen>~/oe%&gt; bitbake -b recipes/myhelloworld/myhelloworld_0.1.bb
+      since it's such a simple example:<screen>$ <command>bitbake</command> -b recipes/myhelloworld/myhelloworld_0.1.bb
 NOTE: package myhelloworld-0.1: started
 NOTE: package myhelloworld-0.1-r0: task do_fetch: started
 NOTE: package myhelloworld-0.1-r0: task do_fetch: completed
@@ -1225,17 +1225,17 @@ NOTE: package myhelloworld-0.1-r0: task do_build: completed
 NOTE: package myhelloworld-0.1: completed
 Build statistics:
   Attempted builds: 1
-~/oe%&gt;</screen></para>
+$</screen></para>
 
       <para>The package was successfully built, the output consists of two
       .ipkg files, which are ready to be installed on the target. One contains
-      the binary and the other contains the readme file:<screen>~/oe%&gt; ls -l tmp/deploy/ipk/*/myhelloworld*
+      the binary and the other contains the readme file:<screen>$ <command>ls</command> -l tmp/deploy/ipk/*/myhelloworld*
 -rw-r--r--  1 lenehan lenehan 3040 Jan 12 14:46 tmp/deploy/ipk/sh4/myhelloworld_0.1-r0_sh4.ipk
 -rw-r--r--  1 lenehan lenehan  768 Jan 12 14:46 tmp/deploy/ipk/sh4/myhelloworld-doc_0.1-r0_sh4.ipk
-~/oe%&gt;</screen></para>
+$</screen></para>
 
       <para>It's worthwhile looking at the working directory to see where
-      various files ended up:<screen>~/oe%&gt; find tmp/work/myhelloworld-0.1-r0
+      various files ended up:<screen>$ <command>find</command> tmp/work/myhelloworld-0.1-r0
 tmp/work/myhelloworld-0.1-r0
 tmp/work/myhelloworld-0.1-r0/myhelloworld-0.1
 tmp/work/myhelloworld-0.1-r0/myhelloworld-0.1/patches
@@ -1271,7 +1271,7 @@ tmp/work/myhelloworld-0.1-r0/image/usr/share/doc
 tmp/work/myhelloworld-0.1-r0/image/usr/share/doc/myhelloworld
 tmp/work/myhelloworld-0.1-r0/myhelloworld.c
 tmp/work/myhelloworld-0.1-r0/README.txt
-~/oe%&gt;</screen>Things to note here are:</para>
+$</screen>Things to note here are:</para>
 
       <itemizedlist>
         <listitem>
@@ -1321,11 +1321,11 @@ tmp/work/myhelloworld-0.1-r0/README.txt
 
       <para>At this stage it's good to verify that we really did produce a
       binary for the target and not for our host system. We can check that
-      with the file command:<screen>~/oe%&gt; file tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld
+      with the file command:<screen>$ <command>file</command> tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld
 tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld: ELF 32-bit LSB executable, Hitachi SH, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, not stripped
-~/oe%&gt; file /bin/ls
+$ <command>file</command> /bin/ls
 /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, stripped
-~/oe%&gt;</screen>This shows us that the helloworld program is for an SH
+$</screen>This shows us that the helloworld program is for an SH
       processor (obviously this will change depending on what your target
       system is), while checking the <emphasis role="bold">/bin/ls</emphasis>
       program on the host shows us that the host system is an AMD X86-64 system.
@@ -1344,7 +1344,7 @@ tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld: ELF 32-b
       of building an autotools based package.</para>
 
       <para>Let's take a look at the tuxnes recipe which is an example of a
-      very simple autotools based recipe:<screen>%~oe&gt; cat recipes/tuxnes/tuxnes_0.75.bb
+      very simple autotools based recipe:<screen>$ <command>cat</command> recipes/tuxnes/tuxnes_0.75.bb
 DESCRIPTION = "Tuxnes Nintendo (8bit) Emulator"
 HOMEPAGE = "http://prdownloads.sourceforge.net/tuxnes/tuxnes-0.75.tar.gz"
 LICENSE = "GPLv2"
@@ -1503,7 +1503,7 @@ inherit autotools</screen></para>
           example from net-snmp shows oe_runconf being called manually so that
           the parameter for specifying the endianess can be computed and
           passed in to the configure script:<screen>do_configure() {
-    # Additional flag based on target endiness (see siteinfo.bbclass)
+    # Additional flag based on target endianess (see siteinfo.bbclass)
     ENDIANESS="${@base_conditional('SITEINFO_ENDIANESS', 'le', '--with-endianness=little', '--with-endianness=big', d)}"
     oenote Determined endianess as: $ENDIANESS
     oe_runconf $ENDIANESS
@@ -1576,7 +1576,7 @@ inherit autotools</screen></para>
           <para>The following example from net-snmp uses oenote to tell the
           user which endianess it determined was appropriate for the target
           device:<screen>do_configure() {
-    # Additional flag based on target endiness (see siteinfo.bbclass)
+    # Additional flag based on target endianess (see siteinfo.bbclass)
     ENDIANESS="${@base_conditional('SITEINFO_ENDIANESS', 'le', '--with-endianness=little', '--with-endianness=big', d)}"
     oenote Determined endianess as: $ENDIANESS
     oe_runconf $ENDIANESS
@@ -1694,7 +1694,7 @@ inherit autotools</screen></para>
           to le for little endian targets and to be for big endian
           targets:<screen>do_compile () {
     ...
-    # Additional flag based on target endiness (see siteinfo.bbclass)
+    # Additional flag based on target endianess (see siteinfo.bbclass)
     CFLAG="${CFLAG} ${@base_conditional('SITEINFO_ENDIANESS', 'le', '-DL_ENDIAN', '-DB_ENDIAN', d)}"
     ...</screen></para>
         </listitem>
@@ -2070,7 +2070,7 @@ PACKAGES += "FILES-${PN}-test"</screen>
       the install directory there is one subdirectory created per package, and
       the files are moved into the install directory as they are matched to a
       specific package. The following shows the packages and files for the
-      helloworld example:<screen>~/oe%&gt; find tmp/work/helloworld-0.1-r0/install
+      helloworld example:<screen>$ <command>find</command> tmp/work/helloworld-0.1-r0/install
 tmp/work/helloworld-0.1-r0/install
 tmp/work/helloworld-0.1-r0/install/helloworld-locale
 tmp/work/helloworld-0.1-r0/install/helloworld-dbg
@@ -2085,7 +2085,7 @@ tmp/work/helloworld-0.1-r0/install/helloworld
 tmp/work/helloworld-0.1-r0/install/helloworld/usr
 tmp/work/helloworld-0.1-r0/install/helloworld/usr/bin
 tmp/work/helloworld-0.1-r0/install/helloworld/usr/bin/helloworld
-~/oe%&gt;</screen>The above shows that the -local, -dbg and -dev packages are
+$</screen>The above shows that the -local, -dbg and -dev packages are
       all empty, and the -doc and base package contain a single file each.
       Using the "<emphasis role="bold">-type f</emphasis>" option to find to show
       just files will make this clearer as well.</para>
@@ -2093,17 +2093,17 @@ tmp/work/helloworld-0.1-r0/install/helloworld/usr/bin/helloworld
       <para>In addition to the install directory the image directory (which
       corresponds to the destination directory, <emphasis
       role="bold">D</emphasis>) will contain any files that were not
-      packaged:<screen>~/oe%&gt; find tmp/work/helloworld-0.1-r0/image
+      packaged:<screen>$ <command>find</command> tmp/work/helloworld-0.1-r0/image
 tmp/work/helloworld-0.1-r0/image
 tmp/work/helloworld-0.1-r0/image/usr
 tmp/work/helloworld-0.1-r0/image/usr/bin
 tmp/work/helloworld-0.1-r0/image/usr/share
 tmp/work/helloworld-0.1-r0/image/usr/share/doc
 tmp/work/helloworld-0.1-r0/image/usr/share/doc/helloworld
-~/oe%&gt;</screen>In this case all files were packaged and so there are no
+$</screen>In this case all files were packaged and so there are no
       left over files. Using find with "<emphasis role="bold">-type
-      f</emphasis>" makes this much clearer:<screen>~/oe%&gt; find tmp/work/helloworld-0.1-r0/image -type f
-~/oe%&gt;</screen></para>
+      f</emphasis>" makes this much clearer:<screen>$ <command>find</command> tmp/work/helloworld-0.1-r0/image -type f
+$</screen></para>
 
       <para>Messages regarding missing files are also displayed by bitbake during
       the package task:<screen>NOTE: package helloworld-0.1-r0: task do_package: started
@@ -2164,7 +2164,7 @@ NOTE: package helloworld-0.1-r0: task do_package: completed</screen>Except in
 
       <para>If we look at the <emphasis>lzo_1.08.bb</emphasis> recipe,
       currently at release 14, it generates a package containing a single
-      shared library :<screen>~oe/build/titan-glibc-25%&gt; find tmp/work/lzo-1.08-r14/install/
+      shared library :<screen>$ <command>find</command> tmp/work/lzo-1.08-r14/install/
 tmp/work/lzo-1.08-r14/install/lzo
 tmp/work/lzo-1.08-r14/install/lzo/usr
 tmp/work/lzo-1.08-r14/install/lzo/usr/lib
@@ -2178,7 +2178,7 @@ tmp/work/lzo-1.08-r14/install/lzo/usr/lib/liblzo.so.1.0.0</screen>Without
       enabled the package is renamed based on the name of the shared library,
       which is <command>liblzo.so.1.0.0</command> in this case. So the name
       <command>lzo</command> is replaced with
-      <command>liblzo1</command>:<screen>~oe/build/titan-glibc-25%&gt; find tmp/deploy/ipk/ -name '*lzo*'  
+      <command>liblzo1</command>:<screen>$ <command>find</command> tmp/deploy/ipk/ -name '*lzo*'  
 tmp/deploy/ipk/sh4/liblzo1_1.08-r14_sh4.ipk
 tmp/deploy/ipk/sh4/liblzo-dev_1.08-r14_sh4.ipk
 tmp/deploy/ipk/sh4/liblzo-dbg_1.08-r14_sh4.ipk</screen></para>
@@ -2485,9 +2485,9 @@ addtask unpack_extra after do_unpack before do_patch</screen></para>
     linkend="chapter_reference" />.</para>
 
     <para>Looking in the staging area under tmp you can see the result of the
-    bzip2 recipes staging task:<screen>%&gt; find tmp/staging -name '*bzlib*'
+    bzip2 recipes staging task:<screen>$ <command>find</command> tmp/staging -name '*bzlib*'
 tmp/staging/sh4-linux/include/bzlib.h
-%&gt; find tmp/staging -name '*libbz*'
+$ <command>find</command> tmp/staging -name '*libbz*'
 tmp/staging/sh4-linux/lib/libbz2.so
 tmp/staging/sh4-linux/lib/libbz2.so.1.0
 tmp/staging/sh4-linux/lib/libbz2.so.1
@@ -2928,7 +2928,7 @@ fi</screen></para>
     <para>Sometimes packages require root permissions in order to perform
     some action, such as changing user or group owners or creating device