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>

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+

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

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

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.