BTRFS in default is not compiled in and we use it as root-FS so it
should be.

This should be something we are going to upstream rather then this.

The device tree changed name.

This now uses default profile and is just one of boards in mpc85xx.

This should move Turris 1.x closer to upstream.

These options are redundant as they are set because of appropriate
target configuration few lines above.

This removes all configuration options that were there to directly
influence kernel config instead of just OpenWrt one. This no longer
works so we can drop it.
Some of those options were moved to patches.
Other are active automatically because of OpenWrt default kernel
configuration and some were dropped without replacement.

This fixes target compilation for mvebu target as some patches are
adding additional options.

This is required because we no longer copy all CONFIG_KERNEL_ options to
platform kernel config file.

This was colliding with OpenWrt's own configuration push and was kind of
hack. Replacement is to use OpenWrt's approach. That is same but in
OpenWrt configuration. To ensure that configuration is used by OpenWrt
KConfig in OWrt tree has to be added.
The new approach also simplifies some stuff because we can let KConfig
to do configuration for us. There is no need to specify specific
options to configuration in this repository. An example can be Turris
Omnia LEDS support (file target/linux/mvebu/image/Config.in):

config KERNEL_LEDS_OMNIA
	bool "Build Turris Omnia LEDS support to kernel"
	depends TARGET_mvebu
	default y if TARGET_mvebu_cortexa9_DEVICE_cznic_turris-omnia
	default n

This adds option CONFIG_KERNEL_LEDS_OMNIA that is copied to kernel
configuration as CONFIG_LEDS_OMNIA. It is available only for
TARGET_mvebu as it is part of patch for that target. In default it is
set to no. No is copied to kernel configuration as "# CONFIG_LEDS_OMNIA
is not set" and that ensures that for other boards kernel compiles as it
knows how to set this option. The default for Turris Omnia board is yes
and that inserts correct "CONFIG_LEDS_OMNIA=y" to kernel config.

There are suppose to be options required on top of already enabled one
by docker.

These options are not in use. They are not activated because of missing
dependency activation. Both of them require module to be enabled and
that module has to packaged. In case of NFT the packages are already in
upstream. In case of XT packages are missing and should possibly be
created in upstream.

The host builds were intended for updater but we no longer build updater
trough OpenWrt build system so we no longer need these host builds.

There are various changes done to configuration on top of just general
cleanup.

All constants from compile_pkgs were moved to configs as it makes sense
that they are in one location not in script.

The settings to use specific version of toolchain was removed. Now we
use upstream default toolchain version which prevents problems with some
packages not being compiled because of old toolchain is used.

All options settings support and capabilities of target were dropped as
they are overriden by target setting non the less so they make no sense.
These should be modified in OpenWrt target not in configuration.

All package settings were dropped with exception of essential packages
and package disablements.
The reason why essential packages were not dropped is to ensure that all
failed build won't be deployed. With future tests done as part of build
this file can be dropped.
And lastly we have to preserve disablement of packages to not build
them as intended.

All DEFAULT options were dropped as they are setting default for symbol
and are intended to be set from target but all of them are overruled by
setting that all packages should be build (CONFIG_ALL).

This is refactored kernel config from master branch before more changes
are applied.

Michal Hrusecky authored 5 years ago and Karel Koci committed 5 years ago

Need to fix dependencies because of upstream package split.

Karel Koci authored 5 years ago and Karel Koci committed 5 years ago

This reverts commit 9b6f3aea.

With updater version 64.0 we can specify that all install requests
should be considered optional so this can be replaced with single line.

Karel Koci authored 5 years ago and Karel Koci committed 5 years ago

We have problem of chicken and egg. To know if we can update we need to
update updater but doing so we have to start updating system. The
problem is that reverting to 3.x with new updater would be pretty hacky
and is also not something we want. The common problem is that users
install some packages with opkg and those are added to updater's
/etc/updater/conf.d/opkg-auto.lua file. Updater is stuck when such
package is no longer provided. Modifying given file is not ideal because
user can have other files that are not automatically managed and running
replacement scripts on them is not good idea. Instead it is better to
ensure that update proceeds even if there is a request for package that
is no longer in repository.

This commit adds two types of rules for packages that are not in Turris
OS 4.0 compared to Turris OS 3.x.
Fist rule is to convince updater that package exists but is effectively
empty. That is done by marking package as virtual:
    Package("NAME", { virtual = true })
Other rule is that package is somewhat replaced by some other package
and we add temporally provide for missing package in to it:
    Package("EXISTING", { provides = {"NAME"} })

This should push problems with requests for non-existing packages to
last step of migration, that is after removal of tos3to4 package.

The list I worked on here was generated only for Omnia. Turris 1.x
should be almost same and mostly just subset so this should be enough.
First I downloaded all repositories indexes from 3.11.9 and from 4.0.1.

    cd 3x
    for repo in base hardware lucics management node openwisp packages php printing routing sidn telephony turrispackages; do curl https://repo.turris.cz/omnia/packages/$repo/Packages > $repo; done
    cd ../4x
    for repo in base core luci openwisp packages routing sidn telephony turrispackages; do curl https://repo.turris.cz/hbs/omnia/packages/$repo/Packages > $repo; done

Next step was to collect all package names.

    cd ../3x
    for repo in $(ls); do sed -n 's/Package: \(.*\)/\1/p' $repo; done | sort > ../3s
    cd ../4x
    for repo in $(ls); do sed -n 's/Package: \(.*\)/\1/p' $repo; done | sort > ../4s

And lastly diff was made for packages missing in 4s but present in 3s:

    cd ..
    diff --new-line-format="" --unchanged-line-format="" 3s 4s

This fixes problem with preferences in feeds and removes patch required
to prevent such collision.

My patch, which was present in the hack folder, is no longer applying as
mariadb was updated in OpenWrt 18.06, 19.07 and master branches.
This patch was meant to be a workaround as something in OpenWrt was
changed and it caused inconsistency in the installation of packages and we
would like to have provided mariadb in our feed, this was the easiest
and a quicker solution at that time.

Solution is provided in this commit: a42ef21a740653ee76146bfccee1ab6afbd65539

Add directories and files generated byt generate_lists and
generate_medkit.

The default value of output_path should have been set after arguments
parsing as empty variable is used to detect if variable was provided or
not.

Also change help as OUTPUT_PATH is optional and there is default in
place if not provided.

This was missed in previous commit cd222783

The empty `space` variable in Makefile for hostapd was causing that
invalid Kconfig was generated and configuration phase failed.

This is happening only with latest GNUMake.

This can be shared between multiple scripts so move it to centralized
file.