jeans/motioneyeos
jeans/motioneyeos
1
0
Fork 0
mirror of https://github.com/motioneye-project/motioneyeos.git synced 2025-07-29 06:06:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

manual: fix spelling mistakes

Browse Source 
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit is contained in:
Simon Dawson 2014-05-31 09:26:20 +01:00 committed by Peter Korsgaard
parent 27a5414804
commit b3b4369848
6 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/manual/adding-packages-directory.txt
View File

@ -27,7 +27,7 @@ config BR2_PACKAGE_LIBFOO
http://foosoftware.org/libfoo/ 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 configuration option must be indented with one tab. The help text
itself should be indented with one tab and two spaces, and it must itself should be indented with one tab and two spaces, and it must
mention the upstream URL of the project. mention the upstream URL of the project.

4
docs/manual/adding-packages-luarocks.txt
View File

@ -49,7 +49,7 @@ package to be built.
==== +luarocks-package+ reference ==== +luarocks-package+ reference
LuaRocks is a deployment and management system for Lua modules, and supports 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+ Buildroot, the +luarocks-package+ infrastructure only supports the +builtin+
mode. LuaRocks packages that use the +make+ or +cmake+ build mechanisms mode. LuaRocks packages that use the +make+ or +cmake+ build mechanisms
should instead be packaged using the +generic-package+ and +cmake-package+ should instead be packaged using the +generic-package+ and +cmake-package+
@ -57,7 +57,7 @@ infrastructures in Buildroot, respectively.
The main macro of the LuaRocks package infrastructure is +luarocks-package+: The main macro of the LuaRocks package infrastructure is +luarocks-package+:
like +generic-package+ it works by defining a number of variables providing 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 is worth mentioning that building LuaRocks packages for the host is not
supported, so the macro +host-luarocks-package+ is not implemented. supported, so the macro +host-luarocks-package+ is not implemented.

2
docs/manual/adding-packages-virtual.txt
View File

@ -12,7 +12,7 @@ the provider used in the rootfs.
For example, 'OpenGL ES' is an API for 2D and 3D graphics on embedded systems. 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 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. package and +sunxi-mali+ and +ti-gfx+ will be the providers.
==== +virtual-package+ tutorial ==== +virtual-package+ tutorial

6
docs/manual/configure.txt
View File

@ -230,7 +230,7 @@ different solutions to handle the +/dev+ directory :
* The first solution is *Static using device table*. This is the old * The first solution is *Static using device table*. This is the old
classical way of handling device files in Linux. With this method, classical way of handling device files in Linux. With this method,
the device files are persistently stored in the root filesystem 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 automatically create and remove those device files when hardware
devices are added or removed from the system. Buildroot therefore devices are added or removed from the system. Buildroot therefore
creates a standard set of device files using a _device table_, the creates a standard set of device files using a _device table_, the
@ -257,14 +257,14 @@ different solutions to handle the +/dev+ directory :
possible to use this option). When mounted in +/dev+, this virtual possible to use this option). When mounted in +/dev+, this virtual
filesystem will automatically make _device files_ appear and filesystem will automatically make _device files_ appear and
disappear as hardware devices are added and removed from the 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 filled dynamically by the kernel. Using _devtmpfs_ requires the
following kernel configuration options to be enabled: following kernel configuration options to be enabled:
+CONFIG_DEVTMPFS+ and +CONFIG_DEVTMPFS_MOUNT+. When Buildroot is in +CONFIG_DEVTMPFS+ and +CONFIG_DEVTMPFS_MOUNT+. When Buildroot is in
charge of building the Linux kernel for your embedded device, it charge of building the Linux kernel for your embedded device, it
makes sure that those two options are enabled. However, if you makes sure that those two options are enabled. However, if you
build your Linux kernel outside of Buildroot, then it is your 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). your Buildroot system will not boot).
* The third solution is *Dynamic using mdev*. This method also relies * The third solution is *Dynamic using mdev*. This method also relies

2
docs/manual/make-tips.txt
View File

@ -67,7 +67,7 @@ The manual outputs will be generated in 'output/docs/manual'.
- A few tools are required to build the documentation (see: - A few tools are required to build the documentation (see:
xref:requirement-optional[]). 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: To delete all build products as well as the configuration:

2
docs/manual/using-buildroot-development.txt
View File

@ -57,7 +57,7 @@ any other version control system. To achieve this, Buildroot will use
_rsync_ to copy the source code of the component from the specified _rsync_ to copy the source code of the component from the specified
+<pkg>_OVERRIDE_SRCDIR+ to +output/build/<package>-custom/+. +<pkg>_OVERRIDE_SRCDIR+ to +output/build/<package>-custom/+.
This mechanism is best used in conjuction with the +make This mechanism is best used in conjunction with the +make
<pkg>-rebuild+ and +make <pkg>-reconfigure+ targets. A +make <pkg>-rebuild+ and +make <pkg>-reconfigure+ targets. A +make
<pkg>-rebuild all+ sequence will _rsync_ the source code from <pkg>-rebuild all+ sequence will _rsync_ the source code from
+<pkg>_OVERRIDE_SRCDIR+ to +output/build/<package>-custom+ (thanks to +<pkg>_OVERRIDE_SRCDIR+ to +output/build/<package>-custom+ (thanks to