docs: consistently indent .rst files with 2 spaces

2 spaces is the most common indentation width used in the docs; adjust
the rest for consistency.

Also change .editorconfig accordingly.
This commit is contained in:
Matthias Schiffer 2021-12-24 14:16:04 +01:00
parent 0e19b1a5c2
commit 854fef4e12
No known key found for this signature in database
GPG Key ID: 16EF3F64CB201D9C
21 changed files with 719 additions and 723 deletions

View File

@ -25,7 +25,7 @@ indent_size = 4
[*.rst] [*.rst]
indent_style = space indent_style = space
indent_size = 3 indent_size = 2
[*.yml] [*.yml]
indent_style = space indent_style = space

View File

@ -9,10 +9,13 @@ Development workflow
When you are developing packages, it often happens that you iteratively want to deploy When you are developing packages, it often happens that you iteratively want to deploy
and verify the state your development. There are two ways to verify your changes: and verify the state your development. There are two ways to verify your changes:
1) One way is to rebuild the complete firmware, flash it, configure it and verify your 1)
One way is to rebuild the complete firmware, flash it, configure it and verify your
development then. This usually takes at least a few minutes to get your changes development then. This usually takes at least a few minutes to get your changes
working so you can test them. Especially if you iterate a lot, this becomes tedious. working so you can test them. Especially if you iterate a lot, this becomes tedious.
2) Another way is to rebuild only the package you are currently working on and
2)
Another way is to rebuild only the package you are currently working on and
to deploy this package to your test system. Here not even a reboot is required. to deploy this package to your test system. Here not even a reboot is required.
This makes iterating relatively fast. Your test system could be real hardware or This makes iterating relatively fast. Your test system could be real hardware or
even a qemu in most cases. even a qemu in most cases.

View File

@ -27,29 +27,25 @@ domain_seed
mesh, but should be different for firmware that is not supposed to mesh with mesh, but should be different for firmware that is not supposed to mesh with
each other. each other.
The recommended way to generate a value for a new site is: The recommended way to generate a value for a new site is::
::
echo $(hexdump -v -n 32 -e '1/1 "%02x"' </dev/urandom) echo $(hexdump -v -n 32 -e '1/1 "%02x"' </dev/urandom)
prefix4 \: optional prefix4 \: optional
The IPv4 Subnet of your community mesh network in CIDR notation, e.g. The IPv4 Subnet of your community mesh network in CIDR notation, e.g. ::
::
prefix4 = '10.111.111.0/18' prefix4 = '10.111.111.0/18'
Required if ``next_node.ip4`` is set. Required if ``next_node.ip4`` is set.
prefix6 prefix6
The IPv6 subnet of your community mesh network, e.g. The IPv6 subnet of your community mesh network, e.g. ::
::
prefix6 = 'fdca::ffee:babe:1::/64' prefix6 = 'fdca::ffee:babe:1::/64'
node_prefix6 node_prefix6
The ipv6 prefix from which the unique IP-addresses for nodes are selected The ipv6 prefix from which the unique IP-addresses for nodes are selected
in babel-based networks. This may overlap with prefix6. e.g. in babel-based networks. This may overlap with prefix6. e.g. ::
::
node_prefix6 = 'fdca::ffee:babe:2::/64' node_prefix6 = 'fdca::ffee:babe:2::/64'
@ -57,21 +53,18 @@ node_client_prefix6
The ipv6 prefix from which the client-specific IP-address is calculated that The ipv6 prefix from which the client-specific IP-address is calculated that
is assigned to each node by l3roamd to allow efficient communication when is assigned to each node by l3roamd to allow efficient communication when
roaming. This is exclusively useful when running a routing mesh protocol roaming. This is exclusively useful when running a routing mesh protocol
like babel. e.g. like babel. e.g. ::
::
node_client_prefix6 = 'fdca::ffee:babe:3::/64' node_client_prefix6 = 'fdca::ffee:babe:3::/64'
timezone timezone
The timezone of your community live in, e.g. The timezone of your community live in, e.g. ::
::
-- Europe/Berlin -- Europe/Berlin
timezone = 'CET-1CEST,M3.5.0,M10.5.0/3' timezone = 'CET-1CEST,M3.5.0,M10.5.0/3'
ntp_servers ntp_servers
List of NTP servers available in your community or used by your community, e.g.: List of NTP servers available in your community or used by your community, e.g.::
::
ntp_servers = {'1.ntp.services.ffac','2.ntp.services.ffac'} ntp_servers = {'1.ntp.services.ffac','2.ntp.services.ffac'}
@ -109,8 +102,7 @@ opkg \: optional
- ``%GR`` is replaced by the Gluon release (as specified in ``site.mk``) - ``%GR`` is replaced by the Gluon release (as specified in ``site.mk``)
regdom \: optional regdom \: optional
The wireless regulatory domain responsible for your area, e.g.: The wireless regulatory domain responsible for your area, e.g. ::
::
regdom = 'DE' regdom = 'DE'
@ -123,7 +115,6 @@ wifi24 \: optional
time units (TU). A time unit is equivalent to 1024 µs. time units (TU). A time unit is equivalent to 1024 µs.
If not set, the default value of 100 TU (=102.4 ms) is used. If not set, the default value of 100 TU (=102.4 ms) is used.
There are currently two interface types available. You may choose to There are currently two interface types available. You may choose to
configure any subset of them: configure any subset of them:
@ -158,6 +149,7 @@ wifi24 \: optional
``mesh`` also accepts an optional ``mcast_rate`` (kbit/s) parameter for ``mesh`` also accepts an optional ``mcast_rate`` (kbit/s) parameter for
setting the multicast bitrate. Increasing the default value of 1000 to something setting the multicast bitrate. Increasing the default value of 1000 to something
like 12000 is recommended. like 12000 is recommended.
:: ::
wifi24 = { wifi24 = {
@ -205,6 +197,7 @@ wifi5 \: optional
next_node \: package next_node \: package
Configuration of the local node feature of Gluon Configuration of the local node feature of Gluon
:: ::
next_node = { next_node = {