Please feature luci-proto-uqmi package: https://openwrt.org/packages/pkgdata/luci-proto-qmi in the next relase.
Hah, they must read this forum:
Yes, we’re reading the forum, but the update for Nextcloud was planned as we’re cooperating with them. Currently, it is updated only in our Nightly branch as we wants to test it and add some tweaks. The thing is that we included Nextcloud update to version 13.0.6 in Turris OS 3.10.6, which we released 11 days ago.
From what we know, Nextcloud developers recommends to update to 14 from 13.0.6 and form this version the update should went very well as it is tested, but from earlier versions, there might be some issues.
Would it be possible to add s3fs-fuse to the packages?
I’d like to be able to use the Omnia as an edge cache to Wasabi S3 storage, thanks.
I have LXC v3.1 compiling OK on an OpenWrt Buildroot.
As yet, it doesn’t work - is there any appetite for taking this on?
I would like to have gcc and build utilities for openwrt . It is available here https://downloads.openwrt.org/releases/packages-18.06/powerpc_8540/packages/gcc_5.4.0-3_powerpc_8540.ipk
but I had no luck to install it - different architecture. With 64GB SDCARD It will be nice to have it to play with compiling directly under for openwrt
That’s would be a quite challenging for me as it’s not available in OpenWRT. I was able to find some article from 2009, where someone was able to make it.
I’m sorry, however, we won’t be able to look at it in near future. Once someone would look at it and would upstream it to OpenWRT, we’ll have it. Also, don’t forget that if we or somebody else will upstream it to OpenWRT, who will need to maintain it and fix issues if they would appear.
Maybe things can change, if we’d be interested in the package even it might sound interesting as we are quite overloaded.
If you want to use s3fs-fuse, it should be possible to use it in LXC container.
Thanks for taking the time to research it! I’ll see if I can install it otherwise, I have rclone running - they have a simple arm7 version that worked first off, it’s not as slick as s3fs but is evolving and has a mount option that works.
Hi, gcc should be available for TurrisOS 4.0. (The build is passing in our test version. )
Impossible to install LUCI NGINX package due to missing dependency uwsgi-cgi. Is it possible to add into repository dependency package ?
- satisfy_dependencies_for: Cannot satisfy the following dependencies for nginx-mod-luci:
- uwsgi-cgi * uwsgi-cgi-luci-support *
- opkg_install_cmd: Cannot install package nginx-mod-luci.
There is a new version of nextcloud, 15. TOS still has 14, can the new version be packaged?
Nextcloud can be installed into lxc container and self-updated after that.
Sure I know, but it’s convenient that it’s packaged inside TOS and even maintained therein.
- wpad / hostapd packages: upstream available wpad is version 2018-05-21-62566bc2-5 whereas the TO has only version 2016-12-19-8 available.
- Implemention of patches to hostapd and mac80211 are needed to support 160MHz width channels as well as DFS scanning for it. See this topic for more information. @Jan.H stated in this thread that the Turris team has WLE1216V5-20 cards available and tested them, so I assume you also looked for getting wave2 up and running in its completeness.
Just to be clear, why we are reluctant to do it. There are configuration changes in hostapd and to support them we would also have to pull latest netifd and because of that latest luci and latest dependencies of those packages. The format of those packages with Lede project were changed so they are incompatible. This pretty much is not pull two packages but pull around few hundreds of them and rewrite their makefiles while breaking rest of the system. Pretty much impossible. The way we are currently approaching it is to have 4.0 ready as soon as possible instead of sinking hundreds of hours in to the dying fork. I am not saying that I am happy that we have old packages in our repository but we have to see bigger picture.
Understood. But just to be clear about the user story (although that doesn’t change anything from your point of view): it’s not just about updating old packages (like you stated on gitlab) but about missing functionality and security fixes!
That is all well and appreciated but the issue is only that TOS4.x is repeatedly cited/advertised as being the cure whilst it is still in the alpha stage and there are only vague hints that it may arrive production ready till end of this year, implying uncertainty that this will be achieved.
Almost 1 year ago it was stated that TOS4.x would be eventually in beta by end of 2018.
Certainly the dev team is doing as best as they can but that developers have departed and not being replaced, plus at the same time adding the MOX workload, in all likelihood has not aided the pace of development and the consequence is that users ultimately paying the price as being a in limbo between out of date core components with the LEDE repo and some alpha state that is still facing all king of issues on its own in the TOS4.x trunk.
Have some developers left the team?