F-Droid meta data generation

Volker Krause vkrause at kde.org
Sat Dec 19 13:36:24 GMT 2020


This has been deployed, you can see the difference for anything having 
screenshots in their appstream file in the F-Droid app now. 

For cleaning up the old meta data code on the signing machine it would however 
require all apps to switch to the new mechanism. That doesn't require active 
work by apps, beyond actually building successfully once. There's however a 
bunch of apps with their last successful build being 8-12 month in the past:

- GCompris (linking/architecture issue with box2d)
- Konversation (use of KStatusNotifierItem)
- KStars (external project build of indi fails)
- all Maui apps

If nobody cared for that long, which of those are actually worth fixing and 
which should be just dropped from the nightly builds?

Regards,
Volker

On Sonntag, 25. Oktober 2020 14:26:57 CET Volker Krause wrote:
> Hi,
> 
> I've been looking into the F-Droid meta data generation a bit, now that I am
> able to run this locally and make changes to it.
> 
> The current system with generating the meta data from the final APK on the
> signing system is nice in that it is entirely transparent for the app, but
> it does have a few limitations:
> - it's happening late in the pipeline, which makes some information hard to
> access (such as the source code repository URL)
> - it's running on the signing system, which requires deploying updates
> manually, and presumably doing things like screenshot downloads on there
> isn't ideal either from a security POV either
> - it's not able to make use of manually provided parts for the meta data
> (e.g. the banner image which has no equivalent in appstream).
> - it's not accessible for F-Droid release builds, ie. builds running on
> their infrastructure
> 
> A possible way to address this could be to move meta data generation from
> repo generation to the build process, implemented as part of ECM. The
> resulting meta data would then need to be transferred alongside the APKs to
> the signing system for integration into the F-Droid repo, presumably this
> can be done by the same mechanism as the APKs are transferred.
> 
> I think this can be done in a similarly transparent way, while now also
> being able to implement merging existing meta data fragments from the
> source dir. By moving to ECM this also becomes independent of our CI
> tooling, which should help F-Droid release builds.
> 
> Thoughts?
> 
> @Nico: would that cover what F-Droid builds need?
> @Aleix: could you add a license/copyright to the generation script (or
> provide me with one) please, preferably with an ECM-compatible license?
> 
> Thanks,
> Volker






More information about the KDE-Android mailing list