F-Droid meta data generation

[Johnny Jazeix]

Hi,

for GCompris, we're trying to be directly in F-Droid main repository:
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/7745 and only
for stable builds (we don't necessary need a nightly on android).

I can still take a look to fix the current build.

There is also ktrip that is trying to be updated:
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/7736 but it
takes some time from F-Droid team to integrate them (there are a lot
of open MRs).

I'm not sure on the process, but if we could have a build server to
directly target the fdroid repo, it could ease the process and allow
us to add more softwares.

Johnny

Le sam. 19 déc. 2020 à 14:39, Volker Krause <vkrause at kde.org> a écrit :
>
> 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
>
>
>
>