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.

.editorconfig

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

docs/dev/basics.rst

@@ -32,7 +32,7 @@ rerun
 
 ::
 
-	make update
+  make update
 
 `make update` also applies the patches that can be found in the directories found in
 `patches`; the resulting branch will be called `patched`, while the commit specified in `modules`
@@ -44,7 +44,7 @@ using
 
 ::
 
-	make update-patches
+  make update-patches
 
 If applying a patch fails because you have changed the base commit, the repository will be reset to the old `patched` branch
 and you can try rebasing it onto the new `base` branch yourself and after that call `make update-patches` to fix the problem.
@@ -54,7 +54,7 @@ commits, making `git reflog` the only way to recover them!
 
 ::
 
-	make refresh-patches
+  make refresh-patches
 
 In order to refresh patches when updating feeds or the OpenWrt base, `make refresh-patches` applies and updates all of their patches without installing feed packages to the OpenWrt buildsystem.
 

docs/dev/debugging.rst

@@ -32,12 +32,12 @@ The tooling is contained in the kernel source tree in the file
 `decode_stacktrace.sh <https://github.com/torvalds/linux/blob/master/scripts/decode_stacktrace.sh>`__.
 This file and the needed source tree are available in the directory: ::
 
-    openwrt/build_dir/target-<architecture>/linux-<architecture>/linux-<version>/
+  openwrt/build_dir/target-<architecture>/linux-<architecture>/linux-<version>/
 
 .. note::
-   Make sure to use a kernel tree that matches the version and patches
+  Make sure to use a kernel tree that matches the version and patches
-   that was used to build the kernel.
+  that was used to build the kernel.
-   If in doubt just re-build the images for the target.
+  If in doubt just re-build the images for the target.
 
 Some more information on how to use this tool can be found at
 `LWN <https://lwn.net/Articles/592724/>`__.
@@ -48,4 +48,4 @@ Obtaining Stacktraces
 On many targets stacktraces can be read from the following
 location after reboot: ::
 
-    /sys/kernel/debug/crashlog
+  /sys/kernel/debug/crashlog

docs/dev/packages.rst

@@ -9,13 +9,16 @@ 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)
-   development then. This usually takes at least a few minutes to get your changes
+  One way is to rebuild the complete firmware, flash it, configure it and verify your
-   working so you can test them. Especially if you iterate a lot, this becomes tedious.
+  development then. This usually takes at least a few minutes to get your changes
-2) Another way is to rebuild only the package you are currently working on and
+  working so you can test them. Especially if you iterate a lot, this becomes tedious.
-   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
+2)
-   even a qemu in most cases.
+  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.
 
 Gluon provides scripts to enhance workflow 2). Here is an example illustrating
 the workflow using these scripts:

docs/features/autoupdater.rst

@@ -99,16 +99,16 @@ These commands can be used on a node:
 
 ::
 
-   # Update with some probability
+  # Update with some probability
-   autoupdater
+  autoupdater
 
 ::
 
-   # Force update check, even when the updater is disabled
+  # Force update check, even when the updater is disabled
-   autoupdater -f
+  autoupdater -f
 
 ::
 
-   # If fallback is true the updater will perform an update only if the timespan
+  # If fallback is true the updater will perform an update only if the timespan
-   # PRIORITY days (as defined in the manifest) and another 24h have passed
+  # PRIORITY days (as defined in the manifest) and another 24h have passed
-   autoupdater --fallback
+  autoupdater --fallback

docs/features/multidomain.rst

@@ -21,18 +21,18 @@ Overview
 Multidomain support allows to build a single firmware with multiple,
 switchable domain configurations. The nomenclature is as follows:
 
--  ``site``: an aggregate over multiple domains
+- ``site``: an aggregate over multiple domains
--  ``domain``: mesh network with connectivity parameters that prevent
+- ``domain``: mesh network with connectivity parameters that prevent
-   accidental bridging with other domains
+  accidental bridging with other domains
--  ``domain code``: unique domain identifier
+- ``domain code``: unique domain identifier
--  ``domain name``: pretty name for a domain code
+- ``domain name``: pretty name for a domain code
 
 By default Gluon builds firmware with a single domain embedded into
 ``site.conf``. To use multiple domains, enable it in ``site.mk``:
 
 ::
 
-    GLUON_MULTIDOMAIN=1
+  GLUON_MULTIDOMAIN=1
 
 In the site repository, create the ``domains/`` directory, which will
 hold your domain configurations. Each domain configuration file is named
@@ -41,26 +41,26 @@ supported.
 
 ::
 
-    site/
+  site/
-    |-- site.conf
+  |-- site.conf
-    |-- site.mk
+  |-- site.mk
-    |-- i18n/
+  |-- i18n/
-    |-- domains/
+  |-- domains/
-      |-- alpha_centauri.conf
+    |-- alpha_centauri.conf
-      |-- beta_centauri.conf
+    |-- beta_centauri.conf
-      |-- gamma_centauri.conf
+    |-- gamma_centauri.conf
 
 The domain configuration ``alpha_centauri.conf`` could look like this.
 
 ::
 
-    {
+  {
-      domain_names = {
+    domain_names = {
-        alpha_centauri = 'Alpha Centauri'
+      alpha_centauri = 'Alpha Centauri'
-      },
+    },
 
-      -- more domain specific config follows below
+    -- more domain specific config follows below
-    }
+  }
 
 In this example “Alpha Centauri” is the user-visible ``domain_name`` for the
 domain_code ``alpha_centauri``. Also note that the domain code
@@ -93,12 +93,12 @@ Via commandline
 
 ::
 
-    gluon-switch-domain 'newdomaincode'
+  gluon-switch-domain 'newdomaincode'
 
 When the node is not in config mode, ``gluon-switch-domain`` will automatically
 reboot the node by default. This can be suppressed by passing ``--no-reboot``::
 
-    gluon-switch-domain --no-reboot 'newdomaincode'
+  gluon-switch-domain --no-reboot 'newdomaincode'
 
 Switching the domain without reboot is currently **experimental**.
 
@@ -123,115 +123,115 @@ site or domain context.
 site.conf only variables
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
--  Used in as initial default values, when the firmware was just flashed
+- Used in as initial default values, when the firmware was just flashed
-   and/or the config mode is skipped, so they do not make sense in a
+  and/or the config mode is skipped, so they do not make sense in a
-   domain specific way:
+  domain specific way:
 
-   -  authorized_keys
+  - authorized_keys
-   -  default_domain
+  - default_domain
-   -  poe_passthrough
+  - poe_passthrough
-   -  mesh_on_wan
+  - mesh_on_wan
-   -  mesh_on_lan
+  - mesh_on_lan
-   -  single_as_lan
+  - single_as_lan
-   -  setup_mode.skip
+  - setup_mode.skip
-   -  autoupdater.branch
+  - autoupdater.branch
-   -  mesh_vpn.enabled
+  - mesh_vpn.enabled
-   -  mesh_vpn.pubkey_privacy
+  - mesh_vpn.pubkey_privacy
-   -  mesh_vpn.bandwidth_limit
+  - mesh_vpn.bandwidth_limit
-   -  mesh_vpn.bandwidth_limit.enabled
+  - mesh_vpn.bandwidth_limit.enabled
-   -  mesh_vpn.bandwidth_limit.ingress
+  - mesh_vpn.bandwidth_limit.ingress
-   -  mesh_vpn.bandwidth_limit.egress
+  - mesh_vpn.bandwidth_limit.egress
 
--  Variables that influence the appearance of the config mode,
+- Variables that influence the appearance of the config mode,
-   domain-independent because they are relevant before a domain was selected.
+  domain-independent because they are relevant before a domain was selected.
 
-   -  config_mode.geo_location.show_altitude
+  - config_mode.geo_location.show_altitude
-   -  config_mode.hostname.optional
+  - config_mode.hostname.optional
-   -  config_mode.remote_login
+  - config_mode.remote_login
-   -  config_mode.remote_login.show_password_form
+  - config_mode.remote_login.show_password_form
-   -  config_mode.remote_login.min_password_length
+  - config_mode.remote_login.min_password_length
-   -  hostname_prefix
+  - hostname_prefix
-   -  mesh_vpn.fastd.configurable
+  - mesh_vpn.fastd.configurable
-   -  roles.default
+  - roles.default
-   -  roles.list
+  - roles.list
 
--  Specific to a firmware build itself:
+- Specific to a firmware build itself:
 
-   -  site_code
+  - site_code
-   -  site_name
+  - site_name
-   -  autoupdater.branches.*.name
+  - autoupdater.branches.*.name
-   -  autoupdater.branches.*.good_signatures
+  - autoupdater.branches.*.good_signatures
-   -  autoupdater.branches.*.pubkeys
+  - autoupdater.branches.*.pubkeys
 
--  We simply do not see any reason, why these variables could be helpful
+- We simply do not see any reason, why these variables could be helpful
-   in a domain specific way:
+  in a domain specific way:
 
-   -  mesh_vpn.fastd.syslog_level
+  - mesh_vpn.fastd.syslog_level
-   -  timezone
+  - timezone
-   -  regdom
+  - regdom
 
 domain.conf only variables
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
--  Obviously:
+- Obviously:
 
-   -  domain_names
+  - domain_names
 
-      -  a table of domain codes to domain names
+    - a table of domain codes to domain names
-         ``domain_names = { foo = 'Foo Domain', bar = 'Bar Domain', baz = 'Baz Domain' }``
+      ``domain_names = { foo = 'Foo Domain', bar = 'Bar Domain', baz = 'Baz Domain' }``
 
-   -  hide_domain
+  - hide_domain
 
-      -  prevents a domain name(s) from appearing in config mode, either
+    - prevents a domain name(s) from appearing in config mode, either
-         boolean or array of domain codes
+      boolean or array of domain codes
 
-         -  ``true``, ``false``
+      - ``true``, ``false``
-         -  ``{ 'foo', 'bar' }``
+      - ``{ 'foo', 'bar' }``
 
--  Because each domain is considered as an own layer 2 network, these
+- Because each domain is considered as an own layer 2 network, these
-   values should be different in each domain:
+  values should be different in each domain:
 
-   -  next_node.ip4
+  - next_node.ip4
-   -  next_node.ip6
+  - next_node.ip6
-   -  next_node.name
+  - next_node.name
-   -  prefix6
+  - prefix6
-   -  prefix4
+  - prefix4
-   -  extra_prefixes6
+  - extra_prefixes6
 
--  To prevent accidental bridging of different domains, all meshing
+- To prevent accidental bridging of different domains, all meshing
-   technologies should be separated:
+  technologies should be separated:
 
-   -  domain_seed (wired mesh)
+  - domain_seed (wired mesh)
 
-      -  must be a random value used to derive the vxlan id for wired meshing
+    - must be a random value used to derive the vxlan id for wired meshing
 
-   -  wifi*.mesh.id
+  - wifi*.mesh.id
-   -  mesh_vpn.fastd.groups.*.peers.remotes
+  - mesh_vpn.fastd.groups.*.peers.remotes
-   -  mesh_vpn.fastd.groups.*.peers.key
+  - mesh_vpn.fastd.groups.*.peers.key
-   -  mesh_vpn.tunneldigger.brokers
+  - mesh_vpn.tunneldigger.brokers
 
--  Clients consider WiFi networks sharing the same ESSID as if they were
+- Clients consider WiFi networks sharing the same ESSID as if they were
-   the same L2 network and try to reconfirm and reuse previous
+  the same L2 network and try to reconfirm and reuse previous
-   addressing. If multiple neighbouring domains shared the same ESSID,
+  addressing. If multiple neighbouring domains shared the same ESSID,
-   the roaming experience of clients would degrade.
+  the roaming experience of clients would degrade.
 
-   -  wifi*.ap.ssid
+  - wifi*.ap.ssid
 
--  Some values should be only set in legacy domains and not in new domains.
+- Some values should be only set in legacy domains and not in new domains.
 
-   -  mesh.vxlan
+  - mesh.vxlan
 
-      -  By default, this value is `true`. It should be only set to `false`
+    - By default, this value is `true`. It should be only set to `false`
-         for one legacy domain, since vxlan prevents accidental wired
+      for one legacy domain, since vxlan prevents accidental wired
-         merges of domains. For old domains this value is still available
+      merges of domains. For old domains this value is still available
-         to keep compatibility between all nodes in one domain.
+      to keep compatibility between all nodes in one domain.
 
-   -  next_node.mac
+  - next_node.mac
 
-      -  For new domains, the default value should be used, since there is
+    - For new domains, the default value should be used, since there is
-         no need for a special mac (or domain specific mac). For old domains
+      no need for a special mac (or domain specific mac). For old domains
-         this value is still available to keep compatibility between all
+      this value is still available to keep compatibility between all
-         nodes in one domain.
+      nodes in one domain.
 
 Example config
 --------------

docs/features/vpn.rst

@@ -52,6 +52,6 @@ socket can be interrogated, after installing for example `socat`.
 
 ::
 
-       opkg update
+  opkg update
-       opkg install socat
+  opkg install socat
-       socat - UNIX-CONNECT:/var/run/fastd.mesh_vpn.socket
+  socat - UNIX-CONNECT:/var/run/fastd.mesh_vpn.socket

docs/package/gluon-mesh-batman-adv.rst

@@ -2,7 +2,7 @@ gluon-mesh-batman-adv
 =====================
 
 .. image:: gluon-mesh-batman-adv-logo.svg
-   :width: 300 px
+  :width: 300 px
 
 B.A.T.M.A.N. Advanced (often referenced as batman-adv) is an implementation of
 the B.A.T.M.A.N. routing protocol in form of a linux kernel module operating on layer 2.
@@ -47,7 +47,7 @@ Multicast Architecture
 ----------------------
 
 .. image:: gluon-mesh-batman-adv-multicast.svg
-   :width: 300 px
+  :width: 300 px
 
 While generally broadcast capability is a nice feature of a layer 2
 mesh protocol, it quickly reaches its limit.

docs/package/gluon-scheduled-domain-switch.rst

@@ -15,15 +15,15 @@ site.conf
 All those settings have to be defined exclusively in the domain, not the site.
 
 domain_switch : optional (needed for domains to switch)
-    target_domain :
+  target_domain :
-        - target domain to switch to
+    - target domain to switch to
-    switch_after_offline_mins :
+  switch_after_offline_mins :
-        - amount of time without reachable gateway to switch unconditionally
+    - amount of time without reachable gateway to switch unconditionally
-    switch_time :
+  switch_time :
-        - UNIX epoch after which domain will be switched
+    - UNIX epoch after which domain will be switched
-    connection_check_targets :
+  connection_check_targets :
-        - array of IPv6 addresses which are probed to determine if the node is
+    - array of IPv6 addresses which are probed to determine if the node is
-	  connected to the mesh
+      connected to the mesh
 
 Example::
 

docs/releases/v2015.1.rst

@@ -170,16 +170,16 @@ Site changes
     for example::
 
       fastd_mesh_vpn = {
-          methods = {'salsa2012+umac'},
+        methods = {'salsa2012+umac'},
-          mtu = 1426,
+        mtu = 1426,
-          groups = {
+        groups = {
-              backbone = {
+          backbone = {
-                  limit = 2,
+            limit = 2,
-                  peers = {
+            peers = {
-                      -- ...
+              -- ...
-                  }
+            }
-              }
           }
+        }
       }
 
   - ``config_mode``: The config mode messages aren't configured in ``site.conf`` anymore. Instead, they are
@@ -190,11 +190,11 @@ Site changes
     in the site i18n files. The ``site.conf`` section becomes::
 
       roles = {
-          default = 'foo',
+        default = 'foo',
-          list = {
+        list = {
-              'foo',
+          'foo',
-              'bar',
+          'bar',
-          }
+        }
       }
 
     The display string use i18n message IDs like ``gluon-luci-node-role:role:foo`` and ``gluon-luci-node-role:role:bar``.

docs/releases/v2016.1.5.rst

@@ -9,21 +9,21 @@ ar71xx-generic
 
 * OpenMesh
 
- - MR600 (v1, v2)
+  - MR600 (v1, v2)
- - MR900 (v1, v2)
+  - MR900 (v1, v2)
- - OM2P (v1, v2)
+  - OM2P (v1, v2)
- - OM2P-HS (v1, v2)
+  - OM2P-HS (v1, v2)
- - OM2P-LC
+  - OM2P-LC
- - OM5P
+  - OM5P
- - OM5P-AN
+  - OM5P-AN
 
 * Ubiquiti
 
- - Rocket M XW
+  - Rocket M XW
 
 * TP-LINK
 
- - TL-WR841N/ND v11
+  - TL-WR841N/ND v11
 
 Bugfixes
 ~~~~~~~~

docs/releases/v2019.1.1.rst

@@ -30,13 +30,13 @@ 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>`_)
+  - | 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
+    | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+    | metric.
 
-   - | Throughput values are not correctly acquired for different interface types.
+  - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+    | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    | 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,13 @@ 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>`_)
+  - | 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
+    | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+    | metric.
 
-   - | Throughput values are not correctly acquired for different interface types.
+  - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+    | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    | 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,13 @@ 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>`_)
+  - | 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
+    | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+    | metric.
 
-   - | Throughput values are not correctly acquired for different interface types.
+  - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+    | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    | 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

@@ -73,8 +73,8 @@ ramips-mt7621
 
 .. note::
 
-    The ``ipq806x`` target has been flagged as broken, as none of its devices are fully supported in this OpenWrt
+  The ``ipq806x`` target has been flagged as broken, as none of its devices are fully supported in this OpenWrt
-    release yet. You might have to update your build scripts accordingly.
+  release yet. You might have to update your build scripts accordingly.
 
 
 
@@ -109,20 +109,20 @@ have outdoor mode automatically enabled during their initial setup, specifically
 
 * Ubiquiti
 
-    - Bullet M
+  - Bullet M
-    - Litebeam M5
+  - Litebeam M5
-    - Nanostation M5
+  - Nanostation M5
-    - Nanostation M5 Loco
+  - Nanostation M5 Loco
-    - Rocket M5
+  - Rocket M5
-    - Rocket M5 TI
+  - Rocket M5 TI
-    - Unifi AC Mesh
+  - Unifi AC Mesh
-    - Unifi AC Mesh Pro
+  - Unifi AC Mesh Pro
-    - Unifi Outdoor
+  - Unifi Outdoor
 
 * TP-Link
 
-    - CPE510
+  - CPE510
-    - WBS510
+  - WBS510
 
 See the :ref:`wifi5 <user-site-wifi5>` section for the *site.conf* configuration of this feature.
 
@@ -253,13 +253,13 @@ 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>`_)
+  - | 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
+    | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+    | metric.
 
-   - | Throughput values are not correctly acquired for different interface types.
+  - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+    | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    | 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,13 @@ 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>`_)
+  - | 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
+    | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+    | metric.
 
-   - | Throughput values are not correctly acquired for different interface types.
+  - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+    | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    | 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,13 @@ 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>`_)
+  - | 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
+    | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+    | metric.
 
-   - | Throughput values are not correctly acquired for different interface types.
+  - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+    | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    | 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,13 @@ 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>`_)
+  - | 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
+    | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+    | metric.
 
-   - | Throughput values are not correctly acquired for different interface types.
+  - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+    | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    | 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

@@ -11,80 +11,80 @@ Added hardware support
 ath79-generic
 ~~~~~~~~~~~~~
 
--  devolo WiFi pro 1200e
+- devolo WiFi pro 1200e
--  devolo WiFi pro 1200i
+- devolo WiFi pro 1200i
--  devolo WiFi pro 1750c
+- devolo WiFi pro 1750c
--  devolo WiFi pro 1750e
+- devolo WiFi pro 1750e
--  devolo WiFi pro 1750i
+- devolo WiFi pro 1750i
--  devolo WiFi pro 1750x
+- devolo WiFi pro 1750x
--  GL.iNet GL-AR300M-Lite
+- GL.iNet GL-AR300M-Lite
--  OCEDO Raccoon
+- OCEDO Raccoon
--  TP-Link Archer C6 v2
+- TP-Link Archer C6 v2
 
 ipq40xx-generic
 ~~~~~~~~~~~~~~~
 
--  Aruba AP-303
+- Aruba AP-303
--  Aruba Instant On AP11
+- Aruba Instant On AP11
--  AVM FRITZ!Repeater 1200
+- AVM FRITZ!Repeater 1200
 
 ipq806x-generic
 ~~~~~~~~~~~~~~~
 
--  Netgear R7800
+- Netgear R7800
 
 lantiq-xway
 ~~~~~~~~~~~
 
--  AVM FRITZ!Box 7312
+- AVM FRITZ!Box 7312
--  AVM FRITZ!Box 7320
+- AVM FRITZ!Box 7320
--  AVM FRITZ!Box 7330
+- AVM FRITZ!Box 7330
--  AVM FRITZ!Box 7330 SL
+- AVM FRITZ!Box 7330 SL
 
 lantiq-xrx200
 ~~~~~~~~~~~~~
 
--  AVM FRITZ!Box 7360 (v1, v2)
+- AVM FRITZ!Box 7360 (v1, v2)
--  AVM FRITZ!Box 7360 SL
+- AVM FRITZ!Box 7360 SL
--  AVM FRITZ!Box 7362 SL
+- AVM FRITZ!Box 7362 SL
--  AVM FRITZ!Box 7412
+- AVM FRITZ!Box 7412
 
 mpc85xx-p1020
 ~~~~~~~~~~~~~
 
--  Enterasys WS-AP3710i
+- Enterasys WS-AP3710i
--  OCEDO Panda
+- OCEDO Panda
 
 ramips-mt7620
 ~~~~~~~~~~~~~
 
--  TP-Link Archer C2 (v1)
+- TP-Link Archer C2 (v1)
--  TP-Link Archer C20 (v1)
+- TP-Link Archer C20 (v1)
--  TP-Link Archer C20i
+- TP-Link Archer C20i
--  TP-Link Archer C50 (v1)
+- TP-Link Archer C50 (v1)
--  Xiaomi MiWifi Mini
+- Xiaomi MiWifi Mini
 
 ramips-mt7621
 ~~~~~~~~~~~~~
 
--  Netgear EX6150 (v1)
+- Netgear EX6150 (v1)
--  Netgear R6220
+- Netgear R6220
 
 ramips-mt76x8
 ~~~~~~~~~~~~~
 
--  GL.iNet VIXMINI
+- GL.iNet VIXMINI
--  TP-Link TL-MR3020 (v3)
+- TP-Link TL-MR3020 (v3)
--  TP-Link TL-WA801ND (v5)
+- TP-Link TL-WA801ND (v5)
--  TP-Link TL-WR902AC (v3)
+- TP-Link TL-WR902AC (v3)
 
 Removed hardware support
 ------------------------
 
--  ALFA Network Hornet-UB [#kernelpartition_too_small]_
+- ALFA Network Hornet-UB [#kernelpartition_too_small]_
--  ALFA Network Tube2H [#kernelpartition_too_small]_
+- ALFA Network Tube2H [#kernelpartition_too_small]_
--  ALFA Network N2 [#kernelpartition_too_small]_
+- ALFA Network N2 [#kernelpartition_too_small]_
--  ALFA Network N5 [#kernelpartition_too_small]_
+- ALFA Network N5 [#kernelpartition_too_small]_
 
 .. [#kernelpartition_too_small]
   The kernel partition on this device is too small to build a working image.
@@ -162,8 +162,8 @@ Site changes
 site.mk
 ~~~~~~~
 
--  The ``GLUON_WLAN_MESH`` variable can be dropped, as 802.11s is
+- The ``GLUON_WLAN_MESH`` variable can be dropped, as 802.11s is
-   the only supported wireless transport from now on.
+  the only supported wireless transport from now on.
 
 Internals
 ---------
@@ -206,13 +206,13 @@ 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>`_)
+  - | 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
+    | Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
-     | metric.
+    | metric.
 
-   - | Throughput values are not correctly acquired for different interface types.
+  - | Throughput values are not correctly acquired for different interface types.
-     | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
+    | (`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
-     | This affects virtual interface types like bridges and VXLAN.
+    | 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/getting_started.rst

@@ -44,7 +44,7 @@ We also provide a container environment that already tracks all these dependenci
 
 ::
 
-   ./scripts/container.sh
+  ./scripts/container.sh
 
 Building the images
 -------------------
@@ -54,31 +54,31 @@ version you'd like to checkout, e.g. *v2021.1*.
 
 ::
 
-    git clone https://github.com/freifunk-gluon/gluon.git gluon -b RELEASE
+  git clone https://github.com/freifunk-gluon/gluon.git gluon -b RELEASE
 
 This command will create a directory named *gluon/*.
 It might also tell a scary message about being in a *detached state*.
 **Don't panic!** Everything's fine.
 Now, enter the freshly created directory::
 
-    cd gluon
+  cd gluon
 
 It's time to add (or create) your site configuration. If you already
 have a site repository, just clone it::
 
-   git clone https://github.com/freifunk-alpha-centauri/site-ffac.git site
+  git clone https://github.com/freifunk-alpha-centauri/site-ffac.git site
 
 If you want to build a new site, create a new git repository *site/*::
 
-    mkdir site
+  mkdir site
-    cd site
+  cd site
-    git init
+  git init
 
 Copy *site.conf*, *site.mk* and *i18n* from *docs/site-example*::
 
-    cp ../docs/site-example/site.conf .
+  cp ../docs/site-example/site.conf .
-    cp ../docs/site-example/site.mk .
+  cp ../docs/site-example/site.mk .
-    cp -r ../docs/site-example/i18n .
+  cp -r ../docs/site-example/i18n .
 
 Edit these files as you see fit and commit them into the site repository.
 Extensive documentation about the site configuration can be found at:
@@ -88,9 +88,9 @@ to the Gluon main repository should be avoided, as it will make updates more com
 
 Next go back to the top-level Gluon directory and build Gluon::
 
-    cd ..
+  cd ..
-    make update                        # Get other repositories used by Gluon
+  make update                        # Get other repositories used by Gluon
-    make GLUON_TARGET=ath79-generic   # Build Gluon
+  make GLUON_TARGET=ath79-generic   # Build Gluon
 
 In case of errors read the messages carefully and try to fix the stated issues
 (e.g. install missing tools not available or look for Troubleshooting_ in the wiki.
@@ -102,9 +102,9 @@ To see a complete list of supported targets, call ``make`` without setting ``GLU
 
 To build all targets use a loop like this::
 
-    for TARGET in $(make list-targets); do
+  for TARGET in $(make list-targets); do
-      make GLUON_TARGET=$TARGET
+    make GLUON_TARGET=$TARGET
-    done
+  done
 
 You should generally reserve 5GB of disk space and additionally about 10GB for each `GLUON_TARGET`.
 
@@ -117,7 +117,7 @@ system.
 of multiple copies of the same image. If your webserver's configuration prohibits following
 symlinks, you can use the following command to resolve these links while copying the images::
 
-    cp -rL output/images /var/www
+  cp -rL output/images /var/www
 
 The directory `output/debug` contains a compressed kernel image for each
 architecture.
@@ -130,14 +130,14 @@ Cleaning the build tree
 
 There are two levels of `make clean`::
 
-    make clean GLUON_TARGET=ath79-generic
+  make clean GLUON_TARGET=ath79-generic
 
 will ensure all packages are rebuilt for a single target. This is usually not
 necessary, but may fix certain kinds of build failures.
 
 ::
 
-    make dirclean
+  make dirclean
 
 will clean the entire tree, so the toolchain will be rebuilt as well, which will take a while.