F-Droid meta data generation

[Volker Krause]

On Samstag, 19. Dezember 2020 14:36:24 CET Volker Krause wrote:
> 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?

With nothing changed and no objections either AFAICS, here is the MR removing 
all of those builds:
https://invent.kde.org/sysadmin/binary-factory-tooling/-/merge_requests/143

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-android/attachments/20210116/82f277b6/attachment.sig>