ArtistGui
ArtistGui copied to clipboard
Project-ARTist
F-Droid app store
Hi, I recently browsed through the FOSS app store called F-Droid [0] and I noticed that the ArtistGui app isn't available for download on there. F-Droid is an alternative app store for people that do not use Google and/or the Playstore, so it would be really cool to see your app there.
As F-Droid focuses on FOSS app, they have strict rules of what an app is allowed to do and what not [1], but I believe that the ArtistGui should be fine (but I haven't looked at your source code tbh).
To submit the app to the central F-Droid repo, the fastest way is to clone the metadata repository and create a PR with the new metadata-text file. [2]
Best regards, gehaxelt
[0] https://f-droid.org/en/ [1] https://f-droid.org/en/docs/Inclusion_Policy/ [2] https://gitlab.com/fdroid/fdroiddata/blob/master/CONTRIBUTING.md
Thanks for sharing this, I pretty much like the idea to have ArtistGui in an app store, but I assume our kind of unique setup will create some issues...
Citing from [0]
The software should not download additional executable binary files (e.g. non-free addons, auto-updates, etc).
#66 might be a problem here...
Yes, we build the ARTist libraries from scratch and all the involved AOSP stuff is free as well, but as we do not have automatic builds right now, it is hard to automatically build all parts of ARTist together with ArtistGui.
Eventually, we want to have this, in particular since we should have CI in all the subparts of ARTist, but for now we cannot do this yet.
Do you have any experience with submitting to F-Droid? Maybe we should just ask them how to handle such a case...
[0] https://f-droid.org/en/docs/Inclusion_Policy/
Good idea and I think we can also realize it. I have the docker images in place, that could get used.
- We would only have to replace travis-ci and invest <=8h in the setup.
This means, we just have to wait a few weeks or months until we find some time :D
Yeah time is the problem yet again... Anyway, you are referring to the docker images to build the different AOSP versions, right? We do not have any CI or similar for art/ARTist yet, so using those docker images for building these repos would be a first step AND we can immediately use it for CI.
Yes there are no art & ARTist builds running. I meant travis as CI solution for Project-ARTist in general, because their custom docker image support is existing, but it's not very good :/
https://docs.travis-ci.com/user/docker/#Using-a-Docker-Image-from-a-Repository-in-a-Build
Btw I started a thread in the F-Droid forum asking for experiences and opinions on the topic:
https://forum.f-droid.org/t/question-about-inclusion-of-foss-app-with-complicated-dependencies/3290
Following up this answer in the F-droid forum:
It seems that besides being included in the official f-droid.org repo, it is also possible to create a completely own repository that can be imported into the F-droid app. For that repository, the problematic rules we stated above don't seem to apply. So this might be a first step towards getting ARTist into the official f-droid.org repo.
Sorry for not following up with your questions...
The app that was included in the F-Droid repo was just a minor "toy" app for a side-project of mine and it was a couple of years ago, so I don't know if the same procedure and rules still apply.
But I think that hosting an own F-Droid repo would be a really good alternative and starting point. I totally forgot about that option, but in essence you setup a webserver and then simply put your app into a local fdroid repository. Within the repository you then use the fdroidserver [0,1] tools to sign the APK (again) and generate the necessary xml files before uploading them to the webserver.
[0] https://gitlab.com/fdroid/fdroidserver [1] https://f-droid.org/docs/Setup_an_F-Droid_App_Repo/
Well I don't see a reason why we should not do this? Maybe we can set this up to automatically pull GitHub releases, re-sign them and provide them through our f-droid repo :grin: