manual: fix spelling mistakes

	  http://foosoftware.org/libfoo/

---------------------------

The +bool+ line, +help+ line and other meta-informations about the

The +bool+ line, +help+ line and other meta-information about the

configuration option must be indented with one tab. The help text

itself should be indented with one tab and two spaces, and it must

mention the upstream URL of the project.

==== +luarocks-package+ reference

LuaRocks is a deployment and management system for Lua modules, and supports

various +build.type+: +builtin+, +make+ and +cmake+. In the contetx of

various +build.type+: +builtin+, +make+ and +cmake+. In the context of

Buildroot, the +luarocks-package+ infrastructure only supports the +builtin+

mode. LuaRocks packages that use the +make+ or +cmake+ build mechanisms

should instead be packaged using the +generic-package+ and +cmake-package+

The main macro of the LuaRocks package infrastructure is +luarocks-package+:

like +generic-package+ it works by defining a number of variables providing

meta informations about the package, and then calling +luarocks-package+. It

meta information about the package, and then calling +luarocks-package+. It

is worth mentioning that building LuaRocks packages for the host is not

supported, so the macro +host-luarocks-package+ is not implemented.

For example, 'OpenGL ES' is an API for 2D and 3D graphics on embedded systems.

The implementation of this API is different for the 'Allwinner Tech Sunxi' and

the 'Texas Instruments OMAP35xx' plaftorms. So +libgles+ will be a virtual

the 'Texas Instruments OMAP35xx' platforms. So +libgles+ will be a virtual

package and +sunxi-mali+ and +ti-gfx+ will be the providers.

==== +virtual-package+ tutorial

 * 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 across 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

   possible to use this option). When mounted in +/dev+, this virtual

   filesystem will automatically make _device files_ appear and

   disappear as hardware devices are added and removed from the

   system. This filesystem is not persistent accross reboots: it is

   system. This filesystem is not persistent across reboots: it is

   filled dynamically by the kernel. Using _devtmpfs_ requires the

   following kernel configuration options to be enabled:

   +CONFIG_DEVTMPFS+ and +CONFIG_DEVTMPFS_MOUNT+. When Buildroot is in

   charge of building the Linux kernel for your embedded device, it

   makes sure that those two options are enabled. However, if you

   build your Linux kernel outside of Buildroot, then it is your

   responsability to enable those two options (if you fail to do so,

   responsibility to enable those two options (if you fail to do so,

   your Buildroot system will not boot).

 * The third solution is *Dynamic using mdev*. This method also relies

- A few tools are required to build the documentation (see:

  xref:requirement-optional[]).

.Reseting Buildroot for a new target:

.Resetting Buildroot for a new target:

To delete all build products as well as the configuration: