The same happened to My Expenses, where tag r301 has not been taken up yet: https://f-droid.org/wiki/page/org.totschnig.myexpenses
It looks like there was a batch released on November 7 and another on November 13.
Perhaps F-Droid only pulls from Git after finishing a batch, and for some reason batches are taking a while to process.
It looks like another batch went through on November 14.
I updated Privacy Browser to version 2.7.2 early on November 22. A couple of build cycles have run since then, but F-Droid has not yet noticed the updated tag and attempted to build 2.7.2. On November 23, F-Droid attempted to build 2.7.1 again. This leads me to believe that the metadata is not updated (or at least not updated successfully) with each build cycle.
A week without any repo updates is just an inconvenience. A week with no updates, no explanation, no acknowledgement, and no ETA is simply unacceptable. Is the repo dead? Is the project finished? Should users move back to Google Play for updates? Not everybody understands that this is a volunteer effort, and a full week without any outward sign of life looks really, really bad.
A concise status page/bar would go a long way to avert frustration - even a one-liner explanation. Anything is better than silence.
Failed to install the following SDK components:
[Android SDK Platform 27]
Please install the missing components using the SDK manager in Android Studio.
Few weeks ago, I needed to move on SDK 27 due to weird bugs. But no release has been published since. Some users start to go back on Google
Any help would be greatly appreciated. Thanks.
has been updated. Just noticing - I have no further insight.
Syncthing is also not getting updated. Which sucks even more because for some reason F-Droid released a beta version as stable.
I agree that this situation sucks. We’re aware of missing platform-27 and gradle-4.3.x; this has been fixed weeks ago. We’re waiting for @ciaran to redeploy the buildserver image.
The simple answer is that building thousands of apps from sources is a
complicated and error prone process. A few of us have recently been
working to work out the worst delays. You can follow the tests here:
We’ve gotten up to 350 APKs built in a single session before hanging.
We recently fixed a number of issues that cause the whole buildserver to
hang until manual intervention:
We have also addressed somethings that slow the process down:
Thanks hans. It is nice to have some insights into what is going on. I appreciate the difficulty of getting something with so many moving parts to work well. For those who have never worked on automating a project like this, it can be much more difficult than initially appears.
@ciaran updated the buildserver. This version includes fixes that made fdroidserver faster and more robust. Currently it’s working hard to process a huge backlog. Things are going fine, most of build failures are resolved.
@relan Thatnks for the update. In general, how often does F-Droid have a queue that takes longer than 1 day to process? From what I have read there have been issues in the past where the build system halts waiting for manual intervention before continuing, which caused things to back up. Assuming all those issues are now resolved, is it possible for the F-Droid server to process 100 or even 1,000 updates per day?
Sometimes, when fdroidserver builds huge apps like Fennec or VLC (multiplied by the number of architectures). This takes many hours.
It was one Git-related issue that’s fixed now.
We never had 100 pending builds. Also remember there’s singing step that still requires manual intervention.
Would it make sense to get a second build server to help with that? I would certainly donate toward that if you deem it useful.
Help with new builds availability delays? There are a lot of factors here, and hardware isn’t that important IMHO. Anyway, I’m not the right person to discuss this with.
Unfortunately we are still seeing hanging buildservers.
We definitely need to implement some sort of timeout for every build. But this is not trivial to fit into the current architecture.
Right now this would unfortunately not solve anything. The whole process is architectured around one server running all pending builds in a loop in a VM instance that is reset after very app. After that is complete it proceeds to sign and then build and publish the index update. Signing the apps and then again signing the index is apparently done on a separate offline machine.
I think this whole architecture needs to be rethought and having a build master/slave system would be the way to go. But this would basically require rewriting most/all of the current build related scripts in fdroidserver. So I don’t think we’ll be there anytime soon.
Until this we are trying to fix those hanging issues and introduce timeouts for all builds and maybe have a certain 24 time limit after that an index getting published no matter if there are still apps in the backlog. But this is all very much future work right now.