Email or username:

Password:

Forgot your password?
Top-level
Eugen Rochko

@fdroidorg We did not leave the F-Droid Reproducible Builds project, because we never entered it in the first place. It was not an active decision by us; F-Droid manages their own app repository and decides which apps go in and how they are built. Our development process results in two artifacts, a AAB build for the Play Store, and an APK build that is published on GitHub, both of which are made from the same 100% open-source, GPL code.

4 comments
Eugen Rochko

@fdroidorg F-Droid representatives asked us to start maintaining yet another build specifically for them; this was not communicated to us as an advance requirement for being on the F-Droid repository. Since the majority of our users are not on F-Droid, and our means are limited, we did not wish to spend engineer time on this, but F-Droid maintainers can maintain such a build on their own.

Ethan Black

@Gargron
@fdroidorg I was thinking about why this post showed up in my timeline. Did you boost your own reply? Then I remembered that if someone I follow replies to someone else I follow, I see the post. Now I've learned something new about that #Mastodon design decision: it is a good way to broudcast something to a particular group, without making *all* your followers have to see it. And all while staying algorithm-free. Cool!

Sylvia

@Gargron @fdroidorg That is incorrect and the GitHub issue shows it. The F-Droid team asked for .apk files of the Google Play build as it was compliant with F-Droid policy. Not a new flavor.

Mastodon made a change to the version they provided to F-Droid (the GitHub version) that broke policy. F-Droid even went out of their way to tweak policy in Mastodon'a favour to not require complete removal of the in-app updater, just a good explanation.

Go Up