endless-sky
endless-sky copied to clipboard
Support the Flatpak build officially?
Currently there's a Flatpak for ES, but it is currently unofficial, as in it is provided by others (thanks for that!).
I think it makes sense to provide the Flatpak officially, so that we can for example automatically publish a new release on Flathub using our release CI workflow.
Thoughts?
Tagging @Pointedstick cause he might be interested as well?
Definitely interested. :)
Currently the way for Flatbub to get your package requires it to be submitted and updated there, on their infrastructure. You don't build it here and then submit it there. So if folks here want to take part in maintaining the Flathub package, you would contact the Flathub folks, mention that you're developers of the upstream project, and request commit access to the packaging repo for Endless Sky. I could do that too.
Automated updates are actually already possible without manual intervention, but you need to set it up in the manifest file. I see in https://github.com/flathub/io.github.endless_sky.endless_sky/blob/master/io.github.endless_sky.endless_sky.json that it hasn't been implemented for ES yet. It might be a good first PR.
Currently the way for Flatbub to get your package requires it to be submitted and updated there, on their infrastructure. You don't build it here and then submit it there.
I found a Github action that builds and deploys using CI. So it seems like it's possible?
Also I just noticed that there's an ARM64 build of ES too; pretty cool.
I found a Github action that builds and deploys using CI. So it seems like it's possible?
That'll build a Flatpak here, in this repo. Which is fine. But it won't do anything for the build on flathub.org.
For that, I've added automatic checking in https://github.com/flathub/io.github.endless_sky.endless_sky/pull/5, so the build on Flathub can update itself automatically when a new tarball is created here.
Ah nice! Thanks!
But it won't do anything for the build on flathub.org.
Isn't it possible using the deploy section in that action? I mean, unless I'm misunderstanding this I'm very new to flatpak. OBS also seems to do it: https://github.com/obsproject/obs-studio/blob/master/.github/workflows/flatpak.yml#L96
Interesting, I wasn't aware that was possible yet. If it is, then yeah, let's use it. We'll probably have to talk with some Flathub people to transition the existing build there from being generated locally there to being generated by us here.
The license information in the ES of the flathub is not correct because ES 0.9.14 also has artworks published by CC-BY-4.0 and CC-BY-NC-3.0. Would you correct it when you would make it official? The future version of ES will have more various licenses.
FWIW the NC variants were removed as part of #6659
#6663 removed NC variants and added artworks published by CC-BY-2.0 and Pixabay License after releasing 0.9.14. README.md was updated by #7033.
I can correct it now on the flathub build. What would be the correct thing?
I wrote a script that scrapes the copyright file and this is the output (for 0.9.14):
{'GPL-3+', 'CC-BY-NC-3.0', 'CC-BY-4.0', 'public-domain', 'CC-BY-SA-4.0', 'CC-BY-3.0', 'CC-BY-SA-3.0'}
Looks like that change actually needs to be made here in the app's appdata file, which FlatHub pulls info from.
Note that the CC-BY-NC-3.0 is not a free software license and will cause the game to get flagged as "non-free" or "proprietary" in various contexts, so we may want to re-think the licensing of that content or replace it with a free license.
so we may want to re-think the licensing of that content or replace it with a free license.
Yes that has already happened, and 0.9.15 is going to release soon so.
So... it's only an issue in the 0.9.14 release but not the upcoming 0.9.15 release?
Correct.
Let's let the issue get solved automatically by a new release, then. :)
so we may want to re-think the licensing of that content or replace it with a free license.
Yes that has already happened, and 0.9.15 is going to release soon so.
NO. Pixabay License is non-free in GNU standard. According to README.md, MZ and devs didn't care ES artworks are free or non-free in GNU standard. I thought we agreed it...
Good call, I'd forgotten about that. Ref #6961, in case anyone else lost track of that
Hmm, that's not ideal. How many Pixabay assets do we have?
#7202 replaces the offending images. If that is merged we'll only have CC licensed assets.
@Pointedstick do I understand correctly that Anitya will automatically update the flatpak?
It will indeed, once https://release-monitoring.org/project/10359/ sees the new release. It doesn't yet.
How can the flathub entry be updated? It still refers to 0.9.14 https://flathub.org/apps/details/io.github.endless_sky.endless_sky
Oh, it's because we haven't added the new release data to our appdata file here in this repo. The latest one in there is 0.9.14
. Flathub pulls release numbers from that, as do many other Linux things, so we're currently misleading everyone! We need to make sure to add a new release in the appdata file when we make a release, before finalizing the tarball for that release.
We need to make sure to add a new release in the appdata file when we make a release, before finalizing the tarball for that release.
Ok this was done in 0.9.16.1, so it should show the latest version correctly now. https://flathub.org/apps/details/io.github.endless_sky.endless_sky It still shows 0.9.14, but I'm assuming it will update in the coming days?
Should be, yeah.
Interesting, I wasn't aware that was possible yet. If it is, then yeah, let's use it. We'll probably have to talk with some Flathub people to transition the existing build there from being generated locally there to being generated by us here.
Is there any advantage to doing it here instead of on the dedicated repo on flathub (the one we currently have)? I have finished setting it up so that it builds the flatpaks using GitHub Actions, but the ARM build needs to be emulated which makes it veeeerrryyy sloooooww (a bit less than 2 hours).
While it takes a while for the auto-updater to notice new releases, it doesn't take long. Building it here would cut that time to only a couple of minutes (or hours for the ARM build). Another thing we can do is similar to Steam: Have the unstable releases published on the 'beta' branch of FlatHub instead of the 'stable' one. I do not know if that is possible to do with the existing process?
So thoughts?
On the beta FlatHub site there's also the possibility to verify apps. @Pointedstick would that be something you are able to do? (only people with commit rights to the repo can do it).