Start syncthing when installed. This makes sure that when the app is
installed through reforis, it will be available and working without any
manual configuration.

Enable syncthing in /etc/config by default to make sure when we
enable the service, syncthing can run without having to manually
enable it in the config.

Users, by default, expect that the service will run automatically and that
they will configure it while the service is running to see what was changed
and what is the behavior of each function there. This change is going to enable
syncthing to run after installing it instead of tweaking the config manually
(in LuCI or by hand). This is somehow different than how OpenWrt does it. They
force users to configure the app before running. Once they are confident that
the configuration looks good, they enable it, which is also good behavior.
Still, we need to improve the user experience and somehow make it different as
we want that even non-IT guys/girls can configure what they need and install
what they need in our simplified interface called (re)Foris, where we provided
list of packages, which they can install and if it does not run by default, it
looks like something is wrong. For syncthing, we also provide
Transmission WebApp, the integration for Turris OS, which you can find on the
landing page and easily click on it and start configuring it.

Start transmission when the package is installed. This makes sure that when
the app is installed through reforis, it will be available and working without
any manual configuration.

Enable transmission in /etc/config by default to make sure when we
enable the service, transmission can run without having to manually
enable it in the config.

Users, by default, expect that the service will run automatically and that
they will configure it while the service is running to see what was changed
and what is the behavior of each function there. This change is going to enable
transmission to run after installing it instead of tweaking the config manually
(in LuCI or by hand). This is somehow different than how OpenWrt does it. They
force users to configure the app before running. Once they are confident that
the configuration looks good, they enable it, which is also good behavior.
Still, we need to improve the user experience and somehow make it different as
we want that even non-IT guys/girls can configure what they need and install
what they need in our simplified interface called (re)Foris, where we provided
list of packages, which they can install and if it does not run by default, it
looks like something is wrong. For transmission, we also provide
Transmission WebApp, the integration for Turris OS, which you can find on the
landing page and easily click on it and start configuring it.

This patch comes from pending pull request to OpenWrt master branch:
https://github.com/openwrt/openwrt/commit/bf8a89084bebbc18670c27098d45fa6406b27e9f

missed in 53670fa1

Let's distinguish the version between HBK/HBT/HBS branches, otherwise,
it is same if it is not different and makes it harder for users to
know which branch or even the version they are using on the router.

This helps and also, it is good to mention that BIND was updated,
because it fixes three CVEs since I backported it to
OpenWrt 22.03 and OpenWrt 21.02.

This is WIP as I want to look at it further, because I want to look if
we can copy all the files in bin instead specifying all binaries by
hand, which would prevent this issue.

There are also other updates like unbound, kernel, but lets include only
highlights for this release.

Removed patches were included in Linux kernel

Michal Hrusecky authored 2 years ago and Josef Schlehofer committed 2 years ago

Hacky way to allow to override any settings for individual cards. This
makes it possible to fix configuration of cards that wrongly report
their capabilities.

Proper way is to somehow integrate it upfront, override reading of
possible capabilities and disable the options in all UIs and properly
report options that are not supported.

That would be quite some complex work and would take quite some time.
But this solution is simple enough and allows us to correct wrong
settings and make problematic cards work again.

This is not exactly dropped, but the relevant commit was applied to
Turris OS packages repository and there is also official 4.0.0 release,
so I switched directly to it.

Several changes were backported to OpenWrt 21.02, that's why we can drop
them from this patch.

Fixes: 5ce2c2ab
("patches/openwrt: Linux kernel 5.15: update to 5.15.86")