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, 132 insertions, 132 deletions

diff --git a/documentation/poky-ref-manual/usingpoky.xml b/documentation/poky-ref-manual/usingpoky.xml
index e5b5edb846..286b5fa783 100644
--- a/documentation/poky-ref-manual/usingpoky.xml
+++ b/documentation/poky-ref-manual/usingpoky.xml
@@ -17,8 +17,8 @@
     <para>
         This section provides a summary of the build process and provides information
         for less obvious aspects of the build process.
-        For general information on how to build an image using the OpenEmbedded build 
-        system, see the  
+        For general information on how to build an image using the OpenEmbedded build
+        system, see the
         "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
         section of the Yocto Project Quick Start.
     </para>
@@ -35,12 +35,12 @@
         </para>
 
         <para>
-            The <filename>build_dir</filename> is optional and specifies the directory the 
-            OpenEmbedded build system uses for the build - 
+            The <filename>build_dir</filename> is optional and specifies the directory the
+            OpenEmbedded build system uses for the build -
             the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
             If you do not specify a Build Directory it defaults to <filename>build</filename>
             in your current working directory.
-            A common practice is to use a different Build Directory for different targets. 
+            A common practice is to use a different Build Directory for different targets.
             For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
             target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
             See <link linkend="structure-core-script">&OE_INIT_FILE;</link>
@@ -55,13 +55,13 @@
         </para>
 
         <para>
-            The <filename>target</filename> is the name of the recipe you want to build. 
+            The <filename>target</filename> is the name of the recipe you want to build.
             Common targets are the images in <filename>meta/recipes-core/images</filename>,
-            <filename>/meta/recipes-sato/images</filename>, etc. all found in the 
+            <filename>/meta/recipes-sato/images</filename>, etc. all found in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-            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 the OpenEmbedded build system supports, see the 
+            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 the OpenEmbedded build system supports, see the
             "<link linkend="ref-images">Images</link>" chapter.
         </para>
 
@@ -76,9 +76,9 @@
         <title>Building an Image Using GPL Components</title>
 
         <para>
-            When building an image using GPL components, you need to maintain your original 
+            When building an image using GPL components, you need to maintain your original
             settings and not switch back and forth applying different versions of the GNU
-            General Public License.  
+            General Public License.
             If you rebuild using different versions of GPL, dependency errors might occur
             due to some components not being rebuilt.
         </para>
@@ -89,11 +89,11 @@
     <title>Installing and Using the Result</title>
 
     <para>
-        Once an image has been built, it often needs to be installed. 
-        The images and kernels built by the OpenEmbedded build system are placed in the 
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> in 
-        <filename class="directory">tmp/deploy/images</filename>. 
-        For information on how to run pre-built images such as <filename>qemux86</filename> 
+        Once an image has been built, it often needs to be installed.
+        The images and kernels built by the OpenEmbedded build system are placed in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> in
+        <filename class="directory">tmp/deploy/images</filename>.
+        For information on how to run pre-built images such as <filename>qemux86</filename>
         and <filename>qemuarm</filename>, see the
         "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
         section in the Yocto Project Quick Start.
@@ -106,25 +106,25 @@
     <title>Debugging Build Failures</title>
 
     <para>
-        The exact method for debugging build failures depends on the nature of the 
-        problem and on the system's area from which the bug originates. 
-        Standard debugging practices such as comparison against the last 
-        known working version with examination of the changes and the re-application of steps 
+        The exact method for debugging build failures depends on the nature of the
+        problem and on the system's area from which the bug originates.
+        Standard debugging practices such as comparison against the last
+        known working version with examination of the changes and the re-application of steps
         to identify the one causing the problem are
-        valid for the Yocto Project just as they are for any other system. 
-        Even though it is impossible to detail every possible potential failure, 
+        valid for the Yocto Project just as they are for any other system.
+        Even though it is impossible to detail every possible potential failure,
         this section provides some general tips to aid in debugging.
     </para>
 
     <section id='usingpoky-debugging-taskfailures'>
         <title>Task Failures</title>
 
-        <para>The log file for shell tasks is available in 
-            <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>. 
+        <para>The log file for shell tasks is available in
+            <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>.
             For example, the <filename>compile</filename> task for the QEMU minimal image for the x86
-            machine (<filename>qemux86</filename>) might be 
+            machine (<filename>qemux86</filename>) might be
             <filename>tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_compile.20830</filename>.
-            To see what BitBake runs to generate that log, look at the corresponding 
+            To see what BitBake runs to generate that log, look at the corresponding
             <filename>run.do_taskname.pid</filename> file located in the same directory.
         </para>
 
@@ -137,17 +137,17 @@
         <title>Running Specific Tasks</title>
 
         <para>
-            Any given package consists of a set of tasks.  
-            The standard BitBake behavior in most cases is: <filename>fetch</filename>, 
-            <filename>unpack</filename>, 
+            Any given package consists of a set of tasks.
+            The standard BitBake behavior in most cases is: <filename>fetch</filename>,
+            <filename>unpack</filename>,
             <filename>patch</filename>, <filename>configure</filename>,
             <filename>compile</filename>, <filename>install</filename>, <filename>package</filename>,
-            <filename>package_write</filename>, and <filename>build</filename>. 
-            The default task is <filename>build</filename> and any tasks on which it depends 
+            <filename>package_write</filename>, and <filename>build</filename>.
+            The default task is <filename>build</filename> and any tasks on which it depends
             build first.
             Some tasks exist, such as <filename>devshell</filename>, that are not part of the
-            default build chain.  
-            If you wish to run a task that is not part of the default build chain, you can use the 
+            default build chain.
+            If you wish to run a task that is not part of the default build chain, you can use the
             <filename>-c</filename> option in BitBake as follows:
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop -c devshell
@@ -155,8 +155,8 @@
         </para>
 
         <para>
-            If you wish to rerun a task, use the <filename>-f</filename> force option. 
-            For example, the following sequence forces recompilation after changing files in the 
+            If you wish to rerun a task, use the <filename>-f</filename> force option.
+            For example, the following sequence forces recompilation after changing files in the
             working directory.
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop
@@ -173,7 +173,7 @@
         <para>
             This sequence first builds <filename>matchbox-desktop</filename> and then recompiles it.
             The last command reruns all tasks (basically the packaging tasks) after the compile.
-            BitBake recognizes that the <filename>compile</filename> task was rerun and therefore 
+            BitBake recognizes that the <filename>compile</filename> task was rerun and therefore
             understands that the other tasks also need to be run again.
         </para>
 
@@ -191,13 +191,13 @@
         <title>Dependency Graphs</title>
 
         <para>
-            Sometimes it can be hard to see why BitBake wants to build some other packages before a given 
+            Sometimes it can be hard to see why BitBake wants to build some other packages before a given
             package you have specified.
-            The <filename>bitbake -g targetname</filename> command creates the 
+            The <filename>bitbake -g targetname</filename> command creates the
             <filename>depends.dot</filename>, <filename>package-depends.dot</filename>,
-            and <filename>task-depends.dot</filename> files in the current directory. 
+            and <filename>task-depends.dot</filename> files in the current directory.
             These files show the package and task dependencies and are useful for debugging problems.
-            You can use the <filename>bitbake -g -u depexp targetname</filename> command to 
+            You can use the <filename>bitbake -g -u depexp targetname</filename> command to
             display the results in a more human-readable form.
         </para>
     </section>
@@ -208,7 +208,7 @@
         <para>
             You can see debug output from BitBake by using the <filename>-D</filename> option.
             The debug output gives more information about what BitBake
-            is doing and the reason behind it. 
+            is doing and the reason behind it.
             Each <filename>-D</filename> option you use increases the logging level.
             The most common usage is <filename>-DDD</filename>.
         </para>
@@ -217,7 +217,7 @@
             The output from <filename>bitbake -DDD -v targetname</filename> can reveal why
             BitBake chose a certain version of a package or why BitBake
             picked a certain provider.
-            This command could also help you in a situation where you think BitBake did something 
+            This command could also help you in a situation where you think BitBake did something
             unexpected.
         </para>
     </section>
@@ -226,9 +226,9 @@
         <title>Building with No Dependencies</title>
         <para>
             If you really want to build a specific <filename>.bb</filename> file, you can use
-            the command form <filename>bitbake -b &lt;somepath/somefile.bb&gt;</filename>. 
+            the command form <filename>bitbake -b &lt;somepath/somefile.bb&gt;</filename>.
             This command form does not check for dependencies so you should use it
-            only when you know its dependencies already exist. 
+            only when you know its dependencies already exist.
             You can also specify fragments of the filename.
             In this case, BitBake checks for a unique match.
         </para>
@@ -243,31 +243,31 @@
             to show the environment from parsing a single recipe file only.
         </para>
     </section>
-    
+
     <section id='recipe-logging-mechanisms'>
         <title>Recipe Logging Mechanisms</title>
         <para>
-            Best practices exist while writing recipes that both log build progress and 
-            act on build conditions such as warnings and errors. 
+            Best practices exist while writing recipes that both log build progress and
+            act on build conditions such as warnings and errors.
             Both Python and Bash language bindings exist for the logging mechanism:
             <itemizedlist>
                 <listitem><para><emphasis>Python:</emphasis> For Python functions, BitBake
-                    supports several loglevels: <filename>bb.fatal</filename>, 
+                    supports several loglevels: <filename>bb.fatal</filename>,
                     <filename>bb.error</filename>, <filename>bb.warn</filename>,
                     <filename>bb.note</filename>, <filename>bb.plain</filename>,
                     and <filename>bb.debug</filename>.</para></listitem>
-                <listitem><para><emphasis>Bash:</emphasis> For Bash functions, the same set 
+                <listitem><para><emphasis>Bash:</emphasis> For Bash functions, the same set
                     of loglevels exist and are accessed with a similar syntax:
-                    <filename>bbfatal</filename>, <filename>bberror</filename>, 
-                    <filename>bbwarn</filename>, <filename>bbnote</filename>, 
+                    <filename>bbfatal</filename>, <filename>bberror</filename>,
+                    <filename>bbwarn</filename>, <filename>bbnote</filename>,
                     <filename>bbplain</filename>, and <filename>bbdebug</filename>.</para></listitem>
             </itemizedlist>
         </para>
 
         <para>
-            For guidance on how logging is handled in both Python and Bash recipes, see the 
-            <filename>logging.bbclass</filename> file in the 
-            <filename>meta/classes</filename> folder of the 
+            For guidance on how logging is handled in both Python and Bash recipes, see the
+            <filename>logging.bbclass</filename> file in the
+            <filename>meta/classes</filename> folder of the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
         </para>
 
@@ -275,14 +275,14 @@
             <title>Logging With Python</title>
             <para>
                 When creating recipes using Python and inserting code that handles build logs
-                keep in mind the goal is to have informative logs while keeping the console as 
-                "silent" as possible. 
+                keep in mind the goal is to have informative logs while keeping the console as
+                "silent" as possible.
                 Also, if you want status messages in the log use the "debug" loglevel.
             </para>
 
             <para>
                 Following is an example written in Python.
-                The code handles logging for a function that determines the number of tasks 
+                The code handles logging for a function that determines the number of tasks
                 needed to be run:
                 <literallayout class='monospaced'>
      python do_listtasks() {
@@ -307,8 +307,8 @@
             <title>Logging With Bash</title>
             <para>
                 When creating recipes using Bash and inserting code that handles build
-                logs you have the same goals - informative with minimal console output. 
-                The syntax you use for recipes written in Bash is similar to that of 
+                logs you have the same goals - informative with minimal console output.
+                The syntax you use for recipes written in Bash is similar to that of
                 recipes written in Python described in the previous section.
             </para>
 
@@ -337,22 +337,22 @@
             </para>
         </section>
     </section>
-    
+
     <section id='usingpoky-debugging-others'>
         <title>Other Tips</title>
 
         <para>
             Here are some other tips that you might find useful:
             <itemizedlist>
-                <listitem><para>When adding new packages, it is worth watching for 
+                <listitem><para>When adding new packages, it is worth watching for
                     undesirable items making their way into compiler command lines.
-                    For example, you do not want references to local system files like 
+                    For example, you do not want references to local system files like
                     <filename>/usr/lib/</filename> or <filename>/usr/include/</filename>.
                     </para></listitem>
-                <listitem><para>If you want to remove the psplash boot splashscreen, 
+                <listitem><para>If you want to remove the psplash boot splashscreen,
                     add <filename>psplash=false</filename> to  the kernel command line.
                     Doing so prevents psplash from loading and thus allows you to see the console.
-                    It is also possible to switch out of the splashscreen by 
+                    It is also possible to switch out of the splashscreen by
                     switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
                     </para></listitem>
             </itemizedlist>
@@ -365,25 +365,25 @@
 
     <para>
         A build's quality can be influenced by many things.
-        For example, if you upgrade a recipe to use a new version of an upstream software 
+        For example, if you upgrade a recipe to use a new version of an upstream software
         package or you experiment with some new configuration options, subtle changes
-        can occur that you might not detect until later. 
+        can occur that you might not detect until later.
         Consider the case where your recipe is using a newer version of an upstream package.
-        In this case, a new version of a piece of software might introduce an optional 
+        In this case, a new version of a piece of software might introduce an optional
         dependency on another library, which is auto-detected.
-        If that library has already been built when the software is building, 
-        then the software will link to the built library and that library will be pulled 
-        into your image along with the new software even if you did not want the 
+        If that library has already been built when the software is building,
+        then the software will link to the built library and that library will be pulled
+        into your image along with the new software even if you did not want the
         library.
     </para>
 
     <para>
         The <filename>buildhistory</filename> class exists to help you maintain
         the quality of your build output.
-        You can use the class to highlight unexpected and possibly unwanted 
+        You can use the class to highlight unexpected and possibly unwanted
         changes in the build output.
-        When you enable build history it records information about the contents of 
-        each package and image and then commits that information to a local Git 
+        When you enable build history it records information about the contents of
+        each package and image and then commits that information to a local Git
         repository where you can examine the information.
     </para>
 
@@ -396,7 +396,7 @@
                </para></listitem>
            <listitem><para>How to limit the information used for build history
                </para></listitem>
-           <listitem><para>How to examine the build history from both a 
+           <listitem><para>How to examine the build history from both a
                command-line and web interface</para></listitem>
        </itemizedlist>
     </para>
@@ -406,41 +406,41 @@
 
         <para>
             Build history is disabled by default.
-            To enable it, add the following statements to the end of your 
-            <filename>conf/local.conf</filename> file found in the 
+            To enable it, add the following statements to the end of your
+            <filename>conf/local.conf</filename> file found in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
             <literallayout class='monospaced'>
      INHERIT += "buildhistory"
      BUILDHISTORY_COMMIT = "1"
             </literallayout>
-            Enabling build history as previously described 
+            Enabling build history as previously described
             causes the build process to collect build
-            output information and commit it to a local 
+            output information and commit it to a local
             <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> repository.
             <note>
-                Enabling build history increases your build times slightly, 
+                Enabling build history increases your build times slightly,
                 particularly for images, and increases the amount of disk
                 space used during the build.
-            </note> 
+            </note>
         </para>
 
         <para>
             You can disable build history by removing the previous statements
             from your <filename>conf/local.conf</filename> file.
-            However, you should realize that enabling and disabling 
-            build history in this manner can change the 
-            <filename>do_package</filename> task checksums, which if you 
-            are using the OEBasicHash signature generator (the default 
+            However, you should realize that enabling and disabling
+            build history in this manner can change the
+            <filename>do_package</filename> task checksums, which if you
+            are using the OEBasicHash signature generator (the default
             for many current distro configurations including
-            <filename>DISTRO = "poky"</filename> and 
-            <filename>DISTRO = ""</filename>) will result in the packaging 
+            <filename>DISTRO = "poky"</filename> and
+            <filename>DISTRO = ""</filename>) will result in the packaging
             tasks being re-run during the subsequent build.
         </para>
 
         <para>
-            To disable the build history functionality without causing the 
-            packaging tasks to be re-run, add just this statement to your 
-            <filename>conf/local.conf</filename> file:               
+            To disable the build history functionality without causing the
+            packaging tasks to be re-run, add just this statement to your
+            <filename>conf/local.conf</filename> file:
             <literallayout class='monospaced'>
      BUILDHISTORY_FEATURES = ""
             </literallayout>
@@ -451,19 +451,19 @@
         <title>Understanding What the Build History Contains</title>
 
         <para>
-            Build history information is kept in  
+            Build history information is kept in
             <link linkend='var-TMPDIR'><filename>$TMPDIR</filename></link><filename>/buildhistory</filename>
             in the Build Directory.
             The following is an example abbreviated listing:
             <imagedata fileref="figures/buildhistory.png" align="center" width="6in" depth="4in" />
         </para>
- 
+
         <section id='build-history-package-information'>
             <title>Build History Package Information</title>
 
             <para>
                 The history for each package contains a text file that has
-                name-value pairs with information about the package. 
+                name-value pairs with information about the package.
                 For example, <filename>buildhistory/packages/core2-poky-linux/busybox/busybox/latest</filename>
                 contains the following:
                 <literallayout class='monospaced'>
@@ -474,21 +474,21 @@
      PKGSIZE = 564701
      FILES = /usr/bin/* /usr/sbin/* /usr/libexec/* /usr/lib/lib*.so.* \
         /etc /com /var /bin/* /sbin/* /lib/*.so.* /usr/share/busybox \
-        /usr/lib/busybox/* /usr/share/pixmaps /usr/share/applications \ 
+        /usr/lib/busybox/* /usr/share/pixmaps /usr/share/applications \
         /usr/share/idl /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers
      FILELIST = /etc/busybox.links /etc/init.d/hwclock.sh /bin/busybox /bin/sh
                 </literallayout>
-                Most of these name-value pairs corresponds to variables used 
+                Most of these name-value pairs corresponds to variables used
                 to produce the package.
-                The exceptions are <filename>FILELIST</filename>, which is the 
-                actual list of files in the package, and 
-                <filename>PKGSIZE</filename>, which is the total size of files 
+                The exceptions are <filename>FILELIST</filename>, which is the
+                actual list of files in the package, and
+                <filename>PKGSIZE</filename>, which is the total size of files
                 in the package in bytes.
             </para>
 
             <para>
-                There is also a file corresponding to the recipe from which the 
-                package came (e.g.  
+                There is also a file corresponding to the recipe from which the
+                package came (e.g.
                 <filename>buildhistory/packages/core2-poky-linux/busybox/latest</filename>):
                 <literallayout class='monospaced'>
      PV = 1.19.3
@@ -509,18 +509,18 @@
                 The files produced for each image are as follows:
                 <itemizedlist>
                     <listitem><para><emphasis>build-id:</emphasis>
-                        Human-readable information about the build configuration 
+                        Human-readable information about the build configuration
                         and metadata source revisions.</para></listitem>
                     <listitem><para><emphasis>*.dot:</emphasis>
-                        Dependency graphs for the image that are 
+                        Dependency graphs for the image that are
                         compatible with <filename>graphviz</filename>.
                         </para></listitem>
                     <listitem><para><emphasis>files-in-image.txt:</emphasis>
-                            A list of files in the image with permissions, 
+                            A list of files in the image with permissions,
                         owner, group, size, and symlink information.
                         </para></listitem>
                     <listitem><para><emphasis>image-info.txt:</emphasis>
-                        A text file containing name-value pairs with information 
+                        A text file containing name-value pairs with information
                         about the image.
                         See the following listing example for more information.
                         </para></listitem>
@@ -535,7 +535,7 @@
                 </itemizedlist>
                 <note>
                     Installed package information is able to be gathered and
-                    produced even if package management is disabled for the final 
+                    produced even if package management is disabled for the final
                     image.
                 </note>
             </para>
@@ -551,15 +551,15 @@
         package-management ssh-server-dropbear package-management
      IMAGE_LINGUAS = en-us en-gb
      IMAGE_INSTALL = task-core-boot task-base-extended
-     BAD_RECOMMENDATIONS = 
-     ROOTFS_POSTPROCESS_COMMAND = buildhistory_get_image_installed ;   rootfs_update_timestamp ;  
-     IMAGE_POSTPROCESS_COMMAND = buildhistory_get_imageinfo ; 
+     BAD_RECOMMENDATIONS =
+     ROOTFS_POSTPROCESS_COMMAND = buildhistory_get_image_installed ;   rootfs_update_timestamp ;
+     IMAGE_POSTPROCESS_COMMAND = buildhistory_get_imageinfo ;
      IMAGESIZE = 171816
                 </literallayout>
                 Other than <filename>IMAGESIZE</filename>, which is the
-                total size of the files in the image in Kbytes, the 
-                name-value pairs are variables that may have influenced the 
-                content of the image. 
+                total size of the files in the image in Kbytes, the
+                name-value pairs are variables that may have influenced the
+                content of the image.
                 This information is often useful when you are trying to determine
                 why a change in the package or file listings has occurred.
             </para>
@@ -568,15 +568,15 @@
         <section id='using-build-history-to-gather-image-information-only'>
             <title>Using Build History to Gather Image Information Only</title>
 
-            <para> 
-                As you can see, build history produces image information, 
+            <para>
+                As you can see, build history produces image information,
                 including dependency graphs, so you can see why something
-                was pulled into the image. 
-                If you are just interested in this information and not 
-                interested in collecting history or any package information, 
-                you can enable writing only image information without 
-                any history by adding the following 
-                to your <filename>conf/local.conf</filename> file found in the 
+                was pulled into the image.
+                If you are just interested in this information and not
+                interested in collecting history or any package information,
+                you can enable writing only image information without
+                any history by adding the following
+                to your <filename>conf/local.conf</filename> file found in the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
                 <literallayout class='monospaced'>
      INHERIT += "buildhistory"
@@ -590,28 +590,28 @@
             <title>Examining Build History Information</title>
 
             <para>
-                You can examine build history output from the command line or 
+                You can examine build history output from the command line or
                 from a web interface.
             </para>
 
             <para>
-                To see any changes that have occurred (assuming you have 
-                <filename>BUILDHISTORY_COMMIT = "1"</filename>), you can simply 
-                use any Git command that allows you to view the history of 
-                a repository. 
+                To see any changes that have occurred (assuming you have
+                <filename>BUILDHISTORY_COMMIT = "1"</filename>), you can simply
+                use any Git command that allows you to view the history of
+                a repository.
                 Here is one method:
                 <literallayout class='monospaced'>
-      $ git log -p 
+      $ git log -p
                 </literallayout>
-                You need to realize, however, that this method does show 
-                changes that are not significant (e.g. a package's size 
+                You need to realize, however, that this method does show
+                changes that are not significant (e.g. a package's size
                 changing by a few bytes).
             </para>
 
             <para>
                 A command-line tool called <filename>buildhistory-diff</filename>
-                does exist though that queries the Git repository and prints just 
-                the differences that might be significant in human-readable form. 
+                does exist though that queries the Git repository and prints just
+                the differences that might be significant in human-readable form.
                 Here is an example:
                 <literallayout class='monospaced'>
      $ ~/poky/poky/scripts/buildhistory-diff . HEAD^
@@ -632,7 +632,7 @@
             </para>
 
             <para>
-                To see changes to the build history using a web interface, follow    
+                To see changes to the build history using a web interface, follow
                 the instruction in the <filename>README</filename> file here.
                 <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/'></ulink>.
             </para>
@@ -646,6 +646,6 @@
 </section>
 
 </chapter>
-<!-- 
-vim: expandtab tw=80 ts=4 
+<!--
+vim: expandtab tw=80 ts=4
 -->