Merge pull request #2349 from freifunk-gluon/doc-indent

docs: consistent indentation + minor fixes

.editorconfig

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

docs/dev/packages.rst

@@ -9,10 +9,13 @@ Development workflow
 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:
 
-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
   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.
   This makes iterating relatively fast. Your test system could be real hardware or
   even a qemu in most cases.

docs/features/multidomain.rst

@@ -188,7 +188,7 @@ domain.conf only variables
       - ``true``, ``false``
       - ``{ 'foo', 'bar' }``
 
--  Because each domain is considered as an own layer 2 network, these
+- Because each domain is considered a separate layer 2 network, these
   values should be different in each domain:
 
   - next_node.ip4

docs/releases/v2019.1.1.rst

@@ -30,13 +30,15 @@ Known issues
 
 * The integration of the BATMAN_V routing algorithm is incomplete.
 
-   - | Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
-     | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+  - Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
 
-   - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
+    metric.
+
+  - Throughput values are not correctly acquired for different interface types.
+    (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+
+    This affects virtual interface types like bridges and VXLAN.
 
 * Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
   (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)

docs/releases/v2019.1.2.rst

@@ -26,13 +26,15 @@ Known issues
 
 * The integration of the BATMAN_V routing algorithm is incomplete.
 
-   - | Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
-     | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+  - Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
 
-   - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
+    metric.
+
+  - Throughput values are not correctly acquired for different interface types.
+    (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+
+    This affects virtual interface types like bridges and VXLAN.
 
 * Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
   (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)

docs/releases/v2019.1.3.rst

@@ -36,13 +36,15 @@ Known issues
 
 * The integration of the BATMAN_V routing algorithm is incomplete.
 
-   - | Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
-     | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+  - Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
 
-   - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
+    metric.
+
+  - Throughput values are not correctly acquired for different interface types.
+    (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+
+    This affects virtual interface types like bridges and VXLAN.
 
 * Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
   (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)

docs/releases/v2019.1.rst

@@ -253,13 +253,15 @@ Known issues
 
 * The integration of the BATMAN_V routing algorithm is incomplete.
 
-   - | Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
-     | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+  - Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
 
-   - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
+    metric.
+
+  - Throughput values are not correctly acquired for different interface types.
+    (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+
+    This affects virtual interface types like bridges and VXLAN.
 
 * Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
   (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)

docs/releases/v2020.1.1.rst

@@ -25,13 +25,15 @@ Known issues
 
 - The integration of the BATMAN_V routing algorithm is incomplete.
 
-   - | Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
-     | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+  - Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
 
-   - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
+    metric.
+
+  - Throughput values are not correctly acquired for different interface types.
+    (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+
+    This affects virtual interface types like bridges and VXLAN.
 
 - Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
   (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)

docs/releases/v2020.1.2.rst

@@ -50,13 +50,15 @@ Known issues
 
 - The integration of the BATMAN_V routing algorithm is incomplete.
 
-   - | Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
-     | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+  - Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
 
-   - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
+    metric.
+
+  - Throughput values are not correctly acquired for different interface types.
+    (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+
+    This affects virtual interface types like bridges and VXLAN.
 
 - Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
   (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)

docs/releases/v2020.1.3.rst

@@ -30,13 +30,15 @@ Known issues
 
 - The integration of the BATMAN_V routing algorithm is incomplete.
 
-   - | Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
-     | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+  - Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
 
-   - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
+    metric.
+
+  - Throughput values are not correctly acquired for different interface types.
+    (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+
+    This affects virtual interface types like bridges and VXLAN.
 
 - Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
   (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)

docs/releases/v2020.1.rst

@@ -206,13 +206,15 @@ Known issues
 
 * The integration of the BATMAN_V routing algorithm is incomplete.
 
-   - | Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
-     | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+  - Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
 
-   - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
+    metric.
+
+  - Throughput values are not correctly acquired for different interface types.
+    (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+
+    This affects virtual interface types like bridges and VXLAN.
 
 * Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
   (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)

docs/user/site.rst

@@ -27,29 +27,25 @@ domain_seed
   mesh, but should be different for firmware that is not supposed to mesh with
   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)
 
 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'
 
   Required if ``next_node.ip4`` is set.
 
 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'
 
 node_prefix6
   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'
 
@@ -57,25 +53,22 @@ node_client_prefix6
   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 
   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'
 
 timezone
-    The timezone of your community live in, e.g.
-    ::
+  The timezone of your community live in, e.g. ::
 
     -- Europe/Berlin
     timezone = 'CET-1CEST,M3.5.0,M10.5.0/3'
 
 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'}
 
-    This NTP servers must be reachable via IPv6 from the nodes. If you don't want to set an IPv6 address
+  These NTP servers must be reachable via IPv6 from the nodes. If you don't want to set an IPv6 address
   explicitly, but use a hostname (which is recommended), see also the :ref:`FAQ <faq-dns>`.
 
 opkg \: optional
@@ -109,8 +102,7 @@ opkg \: optional
   - ``%GR`` is replaced by the Gluon release (as specified in ``site.mk``)
 
 regdom \: optional
-    The wireless regulatory domain responsible for your area, e.g.:
-    ::
+  The wireless regulatory domain responsible for your area, e.g. ::
 
     regdom = 'DE'
 
@@ -123,7 +115,6 @@ wifi24 \: optional
   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.
 
-
   There are currently two interface types available. You may choose to
   configure any subset of them:
 
@@ -158,6 +149,7 @@ wifi24 \: optional
   ``mesh`` also accepts an optional ``mcast_rate`` (kbit/s) parameter for
   setting the multicast bitrate. Increasing the default value of 1000 to something
   like 12000 is recommended.
+
   ::
 
     wifi24 = {
@@ -205,6 +197,7 @@ wifi5 \: optional
 
 next_node \: package
   Configuration of the local node feature of Gluon
+
   ::
 
     next_node = {