manual: fix typo in abbreviation 'i.e.'

Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

diff --git a/docs/manual/adding-packages-autotools.txt b/docs/manual/adding-packages-autotools.txt
index d0c92ffdb8baa555b530b54abd0a573d6cf6c771..cc668b526c58c52f0734fd8c8162c997ba01687c 100644 (file)
--- a/docs/manual/adding-packages-autotools.txt
+++ b/docs/manual/adding-packages-autotools.txt
@@ -119,7 +119,7 @@ cases, typical packages will therefore only use a few of them.
   +make+ command. By default, empty.
 
 * +LIBFOO_AUTORECONF+, tells whether the package should
-  be autoreconfigured or not (i.e, if the configure script and
+  be autoreconfigured or not (i.e. if the configure script and
   Makefile.in files should be re-generated by re-running autoconf,
   automake, libtool, etc.). Valid values are +YES+ and
   +NO+. By default, the value is +NO+

diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
index 9681de00c62bdfe786e79ea51687a0912cb8b6eb..c1c9477a2ec6c34b6e47795b94aa2bd0ff5b812d 100644 (file)
--- a/docs/manual/configure.txt
+++ b/docs/manual/configure.txt
@@ -82,7 +82,7 @@ most important ones allow to:
    built. This library provides the interface between userspace
    applications and the Linux kernel. In order to know how to "talk"
    to the Linux kernel, the C library needs to have access to the
-   _Linux kernel headers_ (i.e, the +.h+ files from the kernel), which
+   _Linux kernel headers_ (i.e. the +.h+ files from the kernel), which
    define the interface between userspace and the kernel (system
    calls, data structures, etc.). Since this interface is backward
    compatible, the version of the Linux kernel headers used to build
@@ -97,7 +97,7 @@ most important ones allow to:
  * Change the version of the GCC compiler, binutils and the C library.
 
  * Select a number of toolchain options (uClibc only): whether the
-   toolchain should have largefile support (i.e support for files
+   toolchain should have largefile support (i.e. support for files
    larger than 2 GB on 32 bits systems), IPv6 support, RPC support
    (used mainly for NFS), wide-char support, locale support (for
    internationalization), C\++ support or thread support. Depending on
@@ -180,17 +180,17 @@ Buildroot itself. In general, all toolchains that support the
 developers.
 
 We do not support toolchains or SDK generated by OpenEmbedded or
-Yocto, because these toolchains are not pure toolchains (i.e just the
+Yocto, because these toolchains are not pure toolchains (i.e. just the
 compiler, binutils, the C and C++ libraries). Instead these toolchains
 come with a very large set of pre-compiled libraries and
 programs. Therefore, Buildroot cannot import the 'sysroot' of the
 toolchain, as it would contain hundreds of megabytes of pre-compiled
 libraries that are normally built by Buildroot.
 
-We also do not support using the distribution toolchain (i.e the
+We also do not support using the distribution toolchain (i.e. the
 gcc/binutils/C library installed by your distribution) as the
 toolchain to build software for the target. This is because your
-distribution toolchain is not a "pure" toolchain (i.e only with the
+distribution toolchain is not a "pure" toolchain (i.e. only with the
 C/C++ library), so we cannot import it properly into the Buildroot
 build environment. So even if you are building a system for a x86 or
 x86_64 target, you have to generate a cross-compilation toolchain with
@@ -235,7 +235,7 @@ different solutions to handle the +/dev+ directory :
  * The first solution is *Static using device table*. This is the old
    classical way of handling device files in Linux. With this method,
    the device files are persistently stored in the root filesystem
-   (i.e they persist accross reboots), and there is nothing that will
+   (i.e. they persist accross reboots), and there is nothing that will
    automatically create and remove those device files when hardware
    devices are added or removed from the system. Buildroot therefore
    creates a standard set of device files using a _device table_, the

diff --git a/docs/manual/customize-outside-br.txt b/docs/manual/customize-outside-br.txt
index 7498940948c777dbabf8e33f716b3a101e89682c..6ee55a358ecf059465f8caa8f0bfce510f42f34e 100644 (file)
--- a/docs/manual/customize-outside-br.txt
+++ b/docs/manual/customize-outside-br.txt
@@ -78,7 +78,7 @@ Or disable the usage of external definitions:
    directories called +board/<boardname>/+ under +BR2_EXTERNAL+. This
    matches the directory structure used within Buildroot.
 
- * One can store package recipes (i.e +Config.in+ and
+ * One can store package recipes (i.e. +Config.in+ and
    +<packagename>.mk+), or even custom configuration options and make
    logic. Buildroot automatically includes +BR2_EXTERNAL/Config.in+ to
    make it appear in the top-level configuration menu, and includes

diff --git a/docs/manual/faq-troubleshooting.txt b/docs/manual/faq-troubleshooting.txt
index a5079e341d31c763b5eeb1e8884573ebc81c4859..473b0e283b18cda6d50095300a0fcb1682f61870 100644 (file)
--- a/docs/manual/faq-troubleshooting.txt
+++ b/docs/manual/faq-troubleshooting.txt
@@ -138,7 +138,7 @@ is much more complicated than that:
 
  * When a package is unselected from the configuration, it is not
    sufficient to remove just the files it installed. One must also
-   remove all its reverse dependencies (i.e packages relying on it)
+   remove all its reverse dependencies (i.e. packages relying on it)
    and rebuild all those packages. For example, package A depends
    optionally on the OpenSSL library. Both are selected, and Buildroot
    is built. Package A is built with crypto support using OpenSSL.