fix buildroot.html typos

    <p>All of these "make" commands will need to build a configuration

    utility, so you may need to install "development" packages for

    relevent libraries used by the configuration utilities.

    relevant libraries used by the configuration utilities.

    On Debian-like systems, the

    <code>libncurses5-dev</code> package is required to use the

    <i>menuconfig</i> interface, <code>libqt3-mt-dev</code> is

      toolchain and tools, these changes will be lost. </li>

      <li>Customize the target filesystem skeleton available under

      <code>target/generic/target_skeleton/</code>. You can customize

      <code>fs/skeleton/</code>. You can customize

      configuration files or other stuff here. However, the full file hierarchy

      is not yet present because it's created during the compilation process.

      Therefore, you can't do everything on this target filesystem skeleton, but

    and which steps remain to be done, Buildroot maintains stamp

    files (empty files that just tell whether this or that action

    has been done). The problem is that these stamp files are not

    uniformely named and handled by the different packages, so some

    uniformly named and handled by the different packages, so some

    understanding of the particular package is needed.</p>

    <p>For packages relying on Buildroot packages infrastructures (see

    <a href="#add_packages">this section</a> for details), the

    following stamp files are relevent:</p>

    following stamp files are relevant:</p>

    <ul>

    <p>The toolchain generated by Buildroot is located by default in

    <code>output/staging/</code>. The simplest way to use it

    is to add <code>output/staging/usr/bin/</code> to your PATH

    environnement variable and then to use

    environment variable and then to use

    <code>ARCH-linux-gcc</code>, <code>ARCH-linux-objdump</code>,

    <code>ARCH-linux-ld</code>, etc. </p>

     href="#generic-reference">reference</a>.</li>

     <li>Makefiles for autotools-based (autoconf, automake, etc.)

     softwares. We provide a dedicated infrastructure for such

     software. We provide a dedicated infrastructure for such

     packages, since autotools is a very common build system. This

     infrastructure <i>must</i> be used for new packages that rely on

     the autotools as their build system.<br/>We cover them through a

    gettext library should not be compiled, because it creates various

    kind of build failures.</p>

    <p>Additionnaly, some packages (such as libglib2) do require

    gettext unconditionnally, while other packages (those who

    <p>Additionally, some packages (such as libglib2) do require

    gettext unconditionally, while other packages (those who

    support <code>--disable-nls</code> in general) only require

    gettext when locale support is enabled.</p>

    </ul>

    <p>Therefore, packages that unconditionnally need gettext should:</p>

    <p>Therefore, packages that unconditionally need gettext should:</p>

    <ol>

      <li>Use <code>select BR2_PACKAGE_GETTEXT if