I was wondering if there is a general problem with the F-Droid build process that is holding up new releases of apps. If so, is there an ETA for when it will be fixed?
I ask because I am the developer of Privacy Browser and have been asked by users why the latest (two) versions are not available on F-Droid.
The following are indications that it may be a general build problem.
The wiki page for my app shows that it was last updated on 2017-02-12.
The wiki page also says the build for the latest version (version code 19) failed. However, following the link shows that the build actually succeeded on 2017-03-18.
My F-Droid client shows the most recently updated apps were on 2017-03-17, indicating the problem is probably system wide and not simply with Privacy Browser.
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.
That’s OK. I know how much effort has to go in behind the scenes for projects like this to run smoothly, and companies like Google don’t always make life easy.
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; F-Droid - Free and Open Source Android App Repository 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.
From the current status, I bet it can be inferred that the signing process is fully automatic, because apps are keeping built/updated although the (repo) index is not.
…Unless signing is not during (the last step of) building, which means my understanding towards Android apps’s building process is wrong
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?
I don’t receive updates since 6 days on 2 different devices, but it seems that packages are built (there are fresh build logs). Probably the issue is later in the chain.
@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.
It looks like the build process is stalled again. I updated Privacy Browser to 2.7 on November 7, but as of November 10 F-Droid has not noticed the Git tag.
.