New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support the Flatpak build officially? #7143
Comments
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. |
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. |
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 flathub/io.github.endless_sky.endless_sky#5, so the build on Flathub can update itself automatically when a new tarball is created here. |
Ah nice! Thanks!
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. |
FWIW the NC variants were removed as part of #6659 |
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. |
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. :) |
NO. |
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 |
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 |
Should be, yeah. |
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). |
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?
The text was updated successfully, but these errors were encountered: