Documentation: poky-ref-manual - Removed all trailing whitespace.

(From yocto-docs rev: 564a28c2501034ea7e2eb16afc43dfaf931b6f6f)

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

1 files changed, 90 insertions, 91 deletions

diff --git a/documentation/poky-ref-manual/faq.xml b/documentation/poky-ref-manual/faq.xml
index 945c7f19af..176573de28 100644
--- a/documentation/poky-ref-manual/faq.xml
+++ b/documentation/poky-ref-manual/faq.xml
@@ -19,11 +19,11 @@
                 and BitBake.
                 Thus, the generic term used here for the build system is
                 the "OpenEmbedded build system."
-                Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with 
+                Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with
                 changes always being merged to OE-Core or BitBake first before being pulled back
                 into Poky.
                 This practice benefits both projects immediately.
-                For a fuller description of the term "Poky", see the 
+                For a fuller description of the term "Poky", see the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>poky</ulink> term in the Yocto Project
                 Development Manual.
             </para>
@@ -47,9 +47,9 @@
                 </itemizedlist>
             </para>
             <para>
-                These tarballs are self-contained with all required libraries and should work 
-                on most Linux systems.  
-                To use the tarballs extract them into the root 
+                These tarballs are self-contained with all required libraries and should work
+                on most Linux systems.
+                To use the tarballs extract them into the root
                 directory and run the appropriate command:
                 <literallayout class='monospaced'>
      $ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH
@@ -72,12 +72,12 @@
             <para>
                 There are three areas that help with stability;
                 <itemizedlist>
-                    <listitem><para>The Yocto Project team keeps 
+                    <listitem><para>The Yocto Project team keeps
                         <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> small
                         and focused, containing around 830 recipes as opposed to the thousands
                         available in other OpenEmbedded community layers.
                         Keeping it small makes it easy to test and maintain.</para></listitem>
-                    <listitem><para>The Yocto Project team runs manual and automated tests 
+                    <listitem><para>The Yocto Project team runs manual and automated tests
                         using a small, fixed set of reference hardware as well as emulated
                         targets.</para></listitem>
                     <listitem><para>The Yocto Project uses an an autobuilder,
@@ -100,7 +100,7 @@
                 <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
             </para>
             <para>
-                Usually, if the board is not completely exotic, adding support in 
+                Usually, if the board is not completely exotic, adding support in
                 the Yocto Project is fairly straightforward.
             </para>
         </answer>
@@ -115,10 +115,10 @@
         <answer>
             <para>
                 The software running on the <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink>
-                is built using the OpenEmbedded build system.  
+                is built using the OpenEmbedded build system.
                 See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink>
                 website for more information.
-                There are a number of pre-production devices using the OpenEmbedded build system 
+                There are a number of pre-production devices using the OpenEmbedded build system
                 and the Yocto Project team
                 announces them as soon as they are released.
             </para>
@@ -133,8 +133,8 @@
         </question>
         <answer>
             <para>
-                Because the same set of recipes can be used to create output of various formats, the 
-                output of an OpenEmbedded build depends on how it was started. 
+                Because the same set of recipes can be used to create output of various formats, the
+                output of an OpenEmbedded build depends on how it was started.
                 Usually, the output is a flashable image ready for the target device.
             </para>
         </answer>
@@ -150,7 +150,7 @@
             <para>
                 To add a package, you need to create a BitBake recipe.
                 For information on how to add a package, see the section
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg'>Adding a Package</ulink>" 
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg'>Adding a Package</ulink>"
                 in the Yocto Project Development Manual.
             </para>
         </answer>
@@ -159,16 +159,16 @@
     <qandaentry>
         <question>
             <para>
-                Do I have to reflash my entire board with a new Yocto Project image when recompiling 
+                Do I have to reflash my entire board with a new Yocto Project image when recompiling
                 a package?
             </para>
         </question>
         <answer>
             <para>
                 The OpenEmbedded build system can build packages in various formats such as
-                <filename>ipk</filename> for <filename>opkg</filename>, 
-                Debian package (<filename>.deb</filename>), or RPM. 
-                The packages can then be upgraded using the package tools on the device, much like 
+                <filename>ipk</filename> for <filename>opkg</filename>,
+                Debian package (<filename>.deb</filename>), or RPM.
+                The packages can then be upgraded using the package tools on the device, much like
                 on a desktop distribution such as Ubuntu or Fedora.
             </para>
         </answer>
@@ -182,11 +182,11 @@
         </question>
         <answer>
             <para>
-                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, 
-                creating a much smaller footprint. 
+                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,
+                creating a much smaller footprint.
             </para>
         </answer>
     </qandaentry>
@@ -200,7 +200,7 @@
         </question>
         <answer>
             <para>
-                You are probably running the build on an NTFS filesystem. 
+                You are probably running the build on an NTFS filesystem.
                 Use <filename>ext2</filename>, <filename>ext3</filename>, or <filename>ext4</filename> instead.
             </para>
         </answer>
@@ -214,8 +214,8 @@
         </question>
         <answer>
             <para>
-                To get the Yocto Project working under RHEL/CentOS 5.1 you need to first 
-                install some required packages. 
+                To get the Yocto Project working under RHEL/CentOS 5.1 you need to first
+                install some required packages.
                 The standard CentOS packages needed are:
                 <itemizedlist>
                     <listitem><para>"Development tools" (selected during installation)</para></listitem>
@@ -224,19 +224,19 @@
                 </itemizedlist>
                 On top of these, you need the following external packages:
                 <itemizedlist>
-                    <listitem><para><filename>python-sqlite2</filename> from 
+                    <listitem><para><filename>python-sqlite2</filename> from
                         <ulink url='http://dag.wieers.com/rpm/packages/python-sqlite2/'>DAG repository</ulink>
                         </para></listitem>
-                    <listitem><para><filename>help2man</filename> from 
+                    <listitem><para><filename>help2man</filename> from
                         <ulink url='http://centos.karan.org/el4/extras/stable/x86_64/RPMS/repodata/repoview/help2man-0-1.33.1-2.html'>Karan repository</ulink></para></listitem>
                 </itemizedlist>
             </para>
 
             <para>
-                Once these packages are installed, the OpenEmbedded build system will be able 
+                Once these packages are installed, the OpenEmbedded build system will be able
                 to build standard images.
-                However, there might be a problem with the QEMU emulator segfaulting. 
-                You can either disable the generation of binary locales by setting 
+                However, there might be a problem with the QEMU emulator segfaulting.
+                You can either disable the generation of binary locales by setting
                 <filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link>
                 </filename> to "0" or by removing the <filename>linux-2.6-execshield.patch</filename>
                 from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.
@@ -247,22 +247,22 @@
     <qandaentry>
         <question>
             <para>
-                I see lots of 404 responses for files on 
+                I see lots of 404 responses for files on
                 <filename>http://www.yoctoproject.org/sources/*</filename>. Is something wrong?
             </para>
         </question>
         <answer>
             <para>
                 Nothing is wrong.
-                The OpenEmbedded build system checks any configured source mirrors before downloading 
-                from the upstream sources. 
-                The build system does this searching for both source archives and 
-                pre-checked out versions of SCM managed software. 
-                These checks help in large installations because it can reduce load on the SCM servers 
-                themselves. 
-                The address above is one of the default mirrors configured into the 
+                The OpenEmbedded build system checks any configured source mirrors before downloading
+                from the upstream sources.
+                The build system does this searching for both source archives and
+                pre-checked out versions of SCM managed software.
+                These checks help in large installations because it can reduce load on the SCM servers
+                themselves.
+                The address above is one of the default mirrors configured into the
                 build system.
-                Consequently, if an upstream source disappears, the team 
+                Consequently, if an upstream source disappears, the team
                 can place sources there so builds continue to work.
             </para>
         </answer>
@@ -271,16 +271,16 @@
     <qandaentry>
         <question>
             <para>
-                I have machine-specific data in a package for one machine only but the package is 
+                I have machine-specific data in a package for one machine only but the package is
                 being marked as machine-specific in all cases, how do I prevent this?
             </para>
         </question>
         <answer>
             <para>
                 Set <filename><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link>
-                </filename> = "0" in the <filename>.bb</filename> file but make sure the package is 
-                manually marked as 
-                machine-specific in the case that needs it. 
+                </filename> = "0" in the <filename>.bb</filename> file but make sure the package is
+                manually marked as
+                machine-specific in the case that needs it.
                 The code that handles <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in <filename>base.bbclass</filename>.
             </para>
         </answer>
@@ -295,9 +295,9 @@
         <answer>
             <para>
                 Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
-                and you therefore need to specify the proxy settings in a 
-                <filename>.wgetrc</filename> file in your home directory. 
-                Example settings in that file would be 
+                and you therefore need to specify the proxy settings in a
+                <filename>.wgetrc</filename> file in your home directory.
+                Example settings in that file would be
                 <literallayout class='monospaced'>
      http_proxy = http://proxy.yoyodyne.com:18023/
      ftp_proxy = http://proxy.yoyodyne.com:18023/
@@ -317,10 +317,10 @@
         </question>
         <answer>
             <para>
-                The <filename>*-native</filename> targets are designed to run on the system 
+                The <filename>*-native</filename> targets are designed to run on the system
                 being used for the build.
-                These are usually tools that are needed to assist the build in some way such as 
-                <filename>quilt-native</filename>, which is used to apply patches. 
+                These are usually tools that are needed to assist the build in some way such as
+                <filename>quilt-native</filename>, which is used to apply patches.
                 The non-native version is the one that runs on the target device.
             </para>
         </answer>
@@ -335,11 +335,11 @@
         <answer>
             <para>
                 If the same build is failing in totally different and random ways,
-                the most likely explanation is that either the hardware you're running the 
-                build on has some problem, or, if you are running the build under virtualisation, 
-                the virtualisation probably has bugs. 
-                The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and 
-                CPU activity and is sensitive to even single bit failures in any of these areas. 
+                the most likely explanation is that either the hardware you're running the
+                build on has some problem, or, if you are running the build under virtualisation,
+                the virtualisation probably has bugs.
+                The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and
+                CPU activity and is sensitive to even single bit failures in any of these areas.
                 True random failures have always been traced back to hardware or virtualisation issues.
             </para>
         </answer>
@@ -356,8 +356,8 @@
                 This is a difficult question and you need to consult your lawyer for the answer
                 for your specific case.
                 It is worth bearing in mind that for GPL compliance there needs to be enough
-                information shipped to allow someone else to rebuild the same end result 
-                you are shipping. 
+                information shipped to allow someone else to rebuild the same end result
+                you are shipping.
                 This means sharing the source code, any patches applied to it, and also any
                 configuration information about how that package was configured and built.
             </para>
@@ -390,9 +390,9 @@
         </question>
         <answer>
             <para>
-                The default interfaces file provided by the netbase recipe does not 
-                automatically bring up network interfaces. 
-                Therefore, you will need to add a BSP-specific netbase that includes an interfaces 
+                The default interfaces file provided by the netbase recipe does not
+                automatically bring up network interfaces.
+                Therefore, you will need to add a BSP-specific netbase that includes an interfaces
                 file.
                 See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</ulink>"
                 section for information on creating these types of miscellaneous recipe files.
@@ -415,11 +415,11 @@
         </question>
         <answer>
             <para>
-                Images are created to be 1.2 times the size of the populated root filesystem. 
-                To modify this ratio so that there is more free space available, you need to 
-                set the configuration value <filename>IMAGE_OVERHEAD_FACTOR</filename>.  
-                For example, setting <filename>IMAGE_OVERHEAD_FACTOR</filename> to 1.5 sets 
-                the image size ratio to one and a half times the size of the populated 
+                Images are created to be 1.2 times the size of the populated root filesystem.
+                To modify this ratio so that there is more free space available, you need to
+                set the configuration value <filename>IMAGE_OVERHEAD_FACTOR</filename>.
+                For example, setting <filename>IMAGE_OVERHEAD_FACTOR</filename> to 1.5 sets
+                the image size ratio to one and a half times the size of the populated
                 root filesystem.
                 <literallayout class='monospaced'>
      IMAGE_OVERHEAD_FACTOR = "1.5"
@@ -436,9 +436,9 @@
         </question>
         <answer>
             <para>
-                The Yocto Project team has tried to do this before but too many of the tools 
-                the OpenEmbedded build system depends on such as <filename>autoconf</filename> 
-                break when they find spaces in pathnames.  
+                The Yocto Project team has tried to do this before but too many of the tools
+                the OpenEmbedded build system depends on such as <filename>autoconf</filename>
+                break when they find spaces in pathnames.
                 Until that situation changes, the team will not support spaces in pathnames.
             </para>
         </answer>
@@ -453,10 +453,10 @@
         <answer>
             <para>
                 The toolchain configuration is very flexible and customizable.
-                It is primarily controlled with the 
+                It is primarily controlled with the
                 <filename><link linkend='var-TCMODE'>TCMODE</link></filename> variable.
-                This variable controls which <filename>tcmode-*.inc</filename> file to include 
-                from the <filename>meta/conf/distro/include</filename> directory within the 
+                This variable controls which <filename>tcmode-*.inc</filename> file to include
+                from the <filename>meta/conf/distro/include</filename> directory within the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
             </para>
 
@@ -466,15 +466,15 @@
                 However, other patterns are accepted.
                 In particular, "external-*" refers to external toolchains of which there are some
                 basic examples included in the OpenEmbedded Core (<filename>meta</filename>).
-                You can use your own custom toolchain definition in your own layer 
-                (or as defined in the <filename>local.conf</filename> file) at the location 
+                You can use your own custom toolchain definition in your own layer
+                (or as defined in the <filename>local.conf</filename> file) at the location
                 <filename>conf/distro/include/tcmode-*.inc</filename>.
             </para>
 
             <para>
                 In addition to the toolchain configuration, you also need a corresponding toolchain recipe file.
-                This recipe file needs to package up any pre-built objects in the toolchain such as 
-                <filename>libgcc</filename>, <filename>libstdcc++</filename>, 
+                This recipe file needs to package up any pre-built objects in the toolchain such as
+                <filename>libgcc</filename>, <filename>libstdcc++</filename>,
                 any locales, and <filename>libc</filename>.
                 An example is the <filename>external-sourcery-toolchain.bb</filename>, which is located
                 in <filename>meta/recipes-core/meta/</filename> within the source directory.
@@ -485,7 +485,7 @@
     <qandaentry>
         <question>
             <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
-                How does the OpenEmbedded build system obtain source code and will it work behind my 
+                How does the OpenEmbedded build system obtain source code and will it work behind my
                 firewall or proxy server?
             </para>
         </question>
@@ -497,13 +497,13 @@
             </para>
             <para>
                 When the build system searches for source code, it first tries the local download directory.
-                If that location fails, Poky tries PREMIRRORS, the upstream source, 
+                If that location fails, Poky tries PREMIRRORS, the upstream source,
                 and then MIRRORS in that order.
             </para>
             <para>
-                By default, the OpenEmbedded build system uses the Yocto Project source PREMIRRORS 
-                for SCM-based sources, 
-                upstreams for normal tarballs, and then falls back to a number of other mirrors 
+                By default, the OpenEmbedded build system uses the Yocto Project source PREMIRRORS
+                for SCM-based sources,
+                upstreams for normal tarballs, and then falls back to a number of other mirrors
                 including the Yocto Project source mirror if those fail.
             </para>
             <para>
@@ -521,7 +521,7 @@
             <para>
                 These changes cause Poky to intercept Git, FTP, HTTP, and HTTPS
                 requests and direct them to the <filename>http://</filename> sources mirror.
-                You can use <filename>file://</filename> URLs to point to local directories 
+                You can use <filename>file://</filename> URLs to point to local directories
                 or network shares as well.
             </para>
             <para>
@@ -529,7 +529,7 @@
                 <literallayout class='monospaced'>
      BB_NO_NETWORK = "1"
                 </literallayout>
-                 This statement tells BitBake to throw an error instead of trying to access the 
+                 This statement tells BitBake to throw an error instead of trying to access the
                  Internet.
                  This technique is useful if you want to ensure code builds only from local sources.
              </para>
@@ -559,14 +559,14 @@
      ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
      http://.*/.* http://www.yoctoproject.org/sources/ \n \
      https://.*/.* http://www.yoctoproject.org/sources/ \n"
-     BB_FETCH_PREMIRRORONLY = "1" 
+     BB_FETCH_PREMIRRORONLY = "1"
                  </literallayout>
-                 These changes would cause Poky to successfully fetch source over HTTP and 
+                 These changes would cause Poky to successfully fetch source over HTTP and
                  any network accesses to anything other than the PREMIRROR would fail.
              </para>
              <para>
-                 The build system also honors the standard shell environment variables 
-                 <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, 
+                 The build system 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.
              </para>
@@ -582,16 +582,16 @@
         <answer>
             <para>
                 Yes - you can easily do this.
-                When you use BitBake to build an image, all the build output goes into the 
+                When you use BitBake to build an image, all the build output goes into the
                 directory created when you source the <filename>oe-init-build-env</filename>
                 setup file.
-                By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> 
+                By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
                 is named <filename>build</filename> but can be named
                 anything you want.
             </para>
 
             <para>
-                Within the build directory is the <filename>tmp</filename> directory. 
+                Within the build directory is the <filename>tmp</filename> directory.
                 To remove all the build output yet preserve any source code or downloaded files
                 from previous builds, simply remove the <filename>tmp</filename> directory.
             </para>
@@ -601,7 +601,6 @@
 
 </qandaset>
 </chapter>
-<!-- 
-vim: expandtab tw=80 ts=4 
+<!--
+vim: expandtab tw=80 ts=4
 -->
-