Skip to content
Snippets Groups Projects
  1. Mar 04, 2020
  2. Feb 24, 2020
  3. Feb 21, 2020
    • Karel Koci's avatar
      lists/luci: handle all luci-i18n-* packages centrally · cd151c81
      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.
      cd151c81
    • Karel Koci's avatar
      lists/foris: handle all Foris language packages centrally · a8a2c36e
      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.
      a8a2c36e
  4. Feb 20, 2020
  5. Feb 18, 2020
  6. Feb 17, 2020
    • Karel Koci's avatar
      2185a2de
    • Karel Koci's avatar
      README.adoc: change suggested sort to version sort · be49424d
      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
      be49424d
    • Karel Koci's avatar
      patches/turrispackages: apply this patch to turris-os-packages · df269171
      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.
      df269171
    • Karel Koci's avatar
      patches/openwrt: fix hotplug script patch · 30f22443
      Karel Koci authored
      This is new version of patch pulled from v4.1 branch of turris-build.
      30f22443
    • Karel Koci's avatar
      401d9c63
    • Karel Koci's avatar
      lists/kmod: add additional modules no longer compiled in · bdf333e2
      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.
      bdf333e2
    • Karel Koci's avatar
      patches/openwrt: modify generic config to compile in BTRFS · 784f2f60
      Karel Koci authored
      BTRFS in default is not compiled in and we use it as root-FS so it
      should be.
      784f2f60
    • Karel Koci's avatar
      patches/openwrt: drop kernel config tweak · 125544bc
      Karel Koci authored
      This should be something we are going to upstream rather then this.
      125544bc
    • Karel Koci's avatar
      patches/turrispackages: refresh Turris 1.x support patch · 5cb98bf2
      Karel Koci authored
      The device tree changed name.
      5cb98bf2
    • Karel Koci's avatar
      patches/openwrt: refactor Turris 1.x from profile to subtarget · fc311ee5
      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.
      fc311ee5
    • Karel Koci's avatar
      configs: drop redundant target configuration options · 37f494e6
      Karel Koci authored
      These options are redundant as they are set because of appropriate
      target configuration few lines above.
      37f494e6
    • Karel Koci's avatar
      configs: drop all kernel configs for direct configuration · cb3ce602
      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.
      cb3ce602
    • Karel Koci's avatar
      patches/openwrt: fix target compilation without config hack · a5699245
      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.
      a5699245
    • Karel Koci's avatar
    • Karel Koci's avatar
      compile_pkgs: drop kernel config push · 2bdb79f8
      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.
      2bdb79f8
    • Karel Koci's avatar
      configs/common/kernel: extend cgroups with docker required options · 46a0ad54
      Karel Koci authored
      There are suppose to be options required on top of already enabled one
      by docker.
      46a0ad54
    • Karel Koci's avatar
      configs/common/kernel: drop unused options · f22bfb74
      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.
      f22bfb74
    • Karel Koci's avatar
      patches/openwrt: drop some patches we do not need and move · 5114f07f
      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.
      5114f07f
    • Karel Koci's avatar
      configs: clean and rework · 4994f202
      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).
      4994f202
  7. Feb 14, 2020
  8. Feb 13, 2020
  9. Feb 12, 2020
  10. Feb 11, 2020
    • Karel Koci's avatar
      Revert "lists/migrate3x: Add provides and virtuals to pass migration" · c6b0420f
      Karel Koci authored and Karel Koci's avatar Karel Koci committed
      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.
      c6b0420f
    • Karel Koci's avatar
      lists/migrate3x: Add provides and virtuals to pass migration · eb11dbad
      Karel Koci authored and Karel Koci's avatar Karel Koci committed
      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
      eb11dbad
  11. Feb 09, 2020
  12. Feb 07, 2020
  13. Feb 06, 2020