- Mar 04, 2020
-
-
Karel Koci authored
This fixes previous configuration rework. For some reason we lost DSA (possibly in some rebase) and also devicetree was invalid. Compatible field is primarily used to match drivers so changing it is no way possible.
-
- Feb 24, 2020
-
-
Karel Koci authored
-
Karel Koci authored
Upstream fixed problem with invalid hash and that way broke validation for some of the files. Updating to latest version of usign fixes this.
-
- Feb 21, 2020
-
-
Karel Koci authored
These packages are same as language packages for Foris There is one speciality and that is that some of Luci's packages have English localization package as well so we have to add "en" to languages. There is full list of all Luci applications there are in repository. We should update this in future or modify the updater functionality so it would be possible to check for existence of package in repository.
-
Karel Koci authored
This has various advantages such as that we do not have to care to always set appropriate requests for language packages as well as for core package. It also ensures that localization is installed even if package is installed outside of package list it is mentioned in. There is also improvement for reForis. Now when you install reForis its plugins are going to be managed relative to those requested to be installed for Foris.
-
- Feb 20, 2020
-
-
Karel Koci authored
We provide now our own version of luajit package with moonjit. We can later think about upstreaming it.
-
- Feb 18, 2020
-
-
Karel Koci authored
This was renamed in HBL to report.
-
Karel Koci authored
-
This locks git mirror directory when we are updating mirrors. This should solve race condition with multiple builds failing to update mirrors and failing that way completely. Only update is protected. The expectation is that initialization is happenning only once and is protected by non-existence of directory. If there is going to be problem with initialization as well then we can add locking as well.
-
Karel Koci authored
This is required for rainbow on Turris 1.x. It is handy in general for any tool that needs to access memory mapped devices or memory directly in general so it is enabled on all devices.
-
Karel Koci authored
-
- Feb 17, 2020
-
-
Karel Koci authored
-
Karel Koci authored
The reason is that compared to default settings of sort version sort is going to sort correctly numbers. As an exalple: 1.1, 1.2, 1.12 should be sorted as stated here byt sorf possibly sortes it as: 1.1, 1.12, 1.2
-
Karel Koci authored
We can apply this patch to turris-os-packages directly now. This patch was also incorect because of rebase. It talks about Kernel 4.19 but change happened in this development branch and was not taied to Kernel 4.19 at all but rather applied to all versions.
-
Karel Koci authored
This is new version of patch pulled from v4.1 branch of turris-build.
-
Karel Koci authored
-
Karel Koci authored
Few optional features were set to OpenWrt default that is package it as package. This just adds those packages to system so behavior stays the same.
-
Karel Koci authored
BTRFS in default is not compiled in and we use it as root-FS so it should be.
-
Karel Koci authored
This should be something we are going to upstream rather then this.
-
Karel Koci authored
The device tree changed name.
-
Karel Koci authored
This now uses default profile and is just one of boards in mpc85xx. This should move Turris 1.x closer to upstream.
-
Karel Koci authored
These options are redundant as they are set because of appropriate target configuration few lines above.
-
Karel Koci authored
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.
-
Karel Koci authored
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.
-
Karel Koci authored
-
Karel Koci authored
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.
-
Karel Koci authored
There are suppose to be options required on top of already enabled one by docker.
-
Karel Koci authored
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.
-
Karel Koci authored
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.
-
Karel Koci authored
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).
-
- Feb 14, 2020
-
-
Karel Koci authored
This is refactored kernel config from master branch before more changes are applied.
-
- Feb 13, 2020
-
-
-
Need to fix dependencies because of upstream package split.
-
- Feb 12, 2020
-
-
Karel Koci authored
-
- Feb 11, 2020
-
-
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.
-
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
-
- Feb 09, 2020
-
-
Josef Schlehofer authored
-
Josef Schlehofer authored
-
- Feb 07, 2020
-
-
Josef Schlehofer authored
-
- Feb 06, 2020
-
-
Josef Schlehofer authored
-