I added 2.0.1, while 2.0 was already in the metadata and was build.
However, we are hitting a bug (or personnel issue) at our publishing
infrastructure. We upgraded to cope with Googles new “download
everything from gradle” world-order the other day, so there might
be bugs, but it looks like building itself is indeed working fine
for most apps…

I am just guessing as well, since I have no other information at hand.
So, nope, there isnt an ETA. I am very sorry for any inconveniences.

It seems there is again something wrong with the repo. Presumably sync between build and repo metadata / database is broken?

Last week I observed this: fdroid app on Android didn’t find anything new for 5 or 6 days until the weekend; https://f-droid.org/#h5o-4 didn’t show anything new (and that is still the case now).
I went to the wiki to check for recent build logs, and found the building processes seemed to be all right.

This time, the build log on wiki is still fine, while nothing new shows up in the repo.

My understanding is that after the APK is built, signing the APK requires the intervention of a living person who types the password to open the keystore (and possibly does some sort of verification of the build process before authorizing the signing). My guess is that very few people/possibly only one person knows this password and their schedule is busy so they only get around to it once a week or so.

Well, to what I see, it doesn’t seem to be good enough (or even necessary) for a repo.

Generally, a repo would be expected to have a huge amount of packages (apps). I think this is especially true for the official repo of F-Droid.
Therefore, it would be aware by the maintainers. If everything else is automated, there is no way people would accept this kind of slowness…

Though, I don’t have a better explanation… The sync process should have been established a long time ago and it shouldn’t go wrong unless there are some huge updates / changes to the fdroid server.

The builds are back to being daily. Anyone can also setup their own fdroid repository which can be updated as frequently as you’d like. This is also then a source for reproducible builds, so f-droid.org can reproduce your own builds, ensuring that both the developer and f-droid.org are running the exact same process. This is very effective in catching malware that inserts itself into the build process.

Anyone can also setup their own fdroid repository which can be updated as frequently as you’d like. This is also then a source for reproducible builds, so f-droid.org can reproduce your own builds, ensuring that both the developer and f-droid.org are running the exact same process.

That’s a good idea. I’ll probably set one up in the future. I would imagine that having different versions of the build chain will produce different binaries. So, for example, if I am running fdroid server from Debian testing and D-Froid.org is running the fdroid server (and associated build chain) from Debian stable, will the binary outputs be identical?

This is very effective in catching malware that inserts itself into the build process.

Anyone can also setup their own fdroid repository which can be updated as frequently as you’d like. This is also then a source for reproducible builds, so f-droid.org can reproduce your own builds, ensuring that both the developer and f-droid.org are running the exact same process.

That’s a good idea. I’ll probably set one up in the future. I would imagine that having different versions of the build chain will produce different binaries. So, for example, if I am running fdroid server from Debian testing and D-Froid.org is running the fdroid server (and associated build chain) from Debian stable, will the binary outputs be identical?

The version of fdroidserver won’t matter much, its mostly a matter of
having the Android SDK bits be the same.

This is very effective in catching malware that inserts itself into the build process.

Has that happened before?

Not with f-droid.org, but in other cases. The biggest and most famous
case of this kind of attack is XCodeGhost.

Is it possible, that the build system is broken again? It looks like there are no builds since about a week (for at least Termux, Nextcloud News and DAV Droid).
Is there something like a status page (like cachet) where outtages are reported?

@renyuneyun, App signing is indeed not part of the build process, but happens as a separate step afterward. In the design of the main F-Droid repository, it requires the manual intervention of a human beign, probably to type the password to unlock the wallet the contains the signing key. I presume it is designed this way to prevent a hacker who compromises the F-Droid infrastructure from gaining access to the F-Droid signing key.