#5 Consider uploading to Flathub
Recently, I noticed that a lot of the classic "distro repo games" like Frozen Bubble, Rocks'n'Diamonds, and Enigma have been added to Flathub and, as someone who enjoys Hex-a-hop, I'd really like to see it on there too, both for the convenience and the chance to get found by new players.
(If you're not familiar with Flathub, it's the main package repository for Flatpak, which is the effort to provide a modern cross-distro package manager with Android/iOS-like sandboxing that's being taken up by basically all distros except Ubuntu, who are staying true to form and trying to get people to adopt a competing solution (with a more fundamentally flawed design but a bigger PR budget) that they control named Snap... though I can confirm Flatpak works perfectly on Ubuntu-family distros if you follow the quick install instruction on Flathub.)
If you're interested, I'd be willing to put together a set of the requisite metadata files analogous to the debian folder in your repo. It's just that their submission guide says they just want people to ask upstream to do the submitting if possible. (If you need an example of the relevant metadata, here's a set of such files that I put together for the e-mail I sent to the author of I Have No Tomatoes yesterday. The only file in that repo that isn't a "Useful for everyone. Upstream it if possible." file is the flatpak-builder JSON file itself.)
Also, I forgot to mention, but it's likely the reason such games have been showing up on Flathub lately is that, by default, the Steam Deck comes with a read-only OS partition and Flathub support, so uploading to Flathub is sort of like submitting to F-Droid, but for the Steam Deck.
Thanks for the suggestion and sorry for the delay in responding.
I agree that it would be useful for Hex-a-Hop to be available on Flathub for folks who use immutable systems like Fedora Silverblue or SteamOS.
Since Flatpak is a packaging system I think that the packaging files should be maintained separately to the upstream project. The appropriate location would be where separate Flatpak packaging is often stored. For Flathub that seems to be in a git repository in the @flathub organisation on GitHub.
Personally I prefer packaging systems with more fine-grained dependencies such as Debian packages, so I don't intend to work on a Flathub submission myself and would prefer that someone else submit and maintain the package.
If you decide to submit Hex-a-Hop to the Flathub GitHub organisation, please @pabs3 in your submission so I get a notification and I can then review what you submitted.
Please note that some of the audio included in Hex-a-Hop git master is licensed under non-free licenses, so if Flathub requires licenses to be free, then you may need to strip those files out. If you are interested in helping replace them, contributions are welcome of course.
Please also forward and bugs reported, workarounds found or patches written etc back to this upstream project for Hex-a-Hop. Unfortunately that hasn't happened for other projects I am upstream for like Chromium BSU.
https://github.com/flathub/net.sourceforge.chromium-bsu/
I also think that the Debian packaging should be maintained within Debian, so probably the
debian/directory will get removed at some point, since the Debian games team are already maintaining Debian packaging for Hex-a-Hop.I can't find your ticket in the Tomatoes project, but I think the same reasoning as above applies to it too.
https://sourceforge.net/projects/tomatoes/
No problem.
Yeah. They have a couple of bots tied into it for automatic "bump dependencies" PRs if you define how to check for updates, test builds of PRs, and automatic deployment to Flathub.
No problem. As long as you're OK with it, I'd be willing to put together a build manifest and Appstream XML for it. (Once I finish resolving the remaining blockers on the PySolFC manifest I'm currently working on.)
My main issue with maintainership in general is limited tolerance for new obligations showing up out of the blue and, with
flatpak-external-data-checkerhandling version bumps and the game itself seeing minimal change meriting new releases, that shouldn't be a problem.Would you prefer I put something up on my personal GitHub account for you to review before I do the "fork
new-pronflathub, put your submission in it, open a PR, and let them review it" dance and involve a submission reviewer from Flathub?Flathub is OK with non-free licenses. As I understand it, that's why Fedora Silverblue doesn't enable it as a source by default.
The submission guidelines say:
...so it should be fine.
I'll have to ask them if they'd be willing to turn off the issue tracker on the GitHub repo and let you @ssokolow me when I'm relevant.
I e-mailed Mika Halttunen directly because the state of the SourceForge project didn't give me much confidence that I'd get a response there. I already got the "I don't have time to do this, but go ahead" and I'm now maintaining a FlatHub release of it:
https://flathub.org/apps/details/net.sourceforge.tomatoes.IHaveNoTomatoes
Last edit: Stephan Sokolow 2022-09-19
On Mon, 2022-09-19 at 06:58 +0000, Stephan Sokolow wrote:
Please do. There is an Appstream XML file in the upstream git repo
already, hopefully it is suitable for Flathub too.
That seems reasonable to me, if you want to go that way.
I am also fine just commenting on your initial submission too.
Sounds like Fedora might change that at some point.
https://lwn.net/Articles/897793/
That seems OK too, if you prefer it instead of forwarding issues.
Yeah, I got access to the Tomatoes project too but never got around to
modernising the project with a VCS/etc.
Great, thanks for that.
--
bye,
pabs
https://bonedaddy.net/pabs3/
It's a bit incomplete. Aside from me being a completionist and a perfectionist, I'm not sure it'll pass validation, since I think the validator wants at least one
<release>element so it can surface them in the upcoming UI redesign being demo'd at beta.flatpak.org (beta.flathub.org).(I've fired off a request to relicense the release text from Tomatoes to improve its entry on that front.)
You'll probably see me offering up a patch to expand your Appstream XML out to something like this.
Thanks for that. I really need to get back to reading LWN consistently again.
Speaking of which, would you like me to add a
<url type="bugtracker">https://sourceforge.net/p/tomatoes/_list/tickets</url>element to the Appstream XML for Tomatoes when I add thex-checker-datadefinitions I forgot to add for Tomatoes itself?Also, if you ever do get around to it, let me know in case I have time to write a patch to add native joystick/gamepad support for people like Steam Deck users.
On Tue, 2022-09-20 at 00:43 +0000, Stephan Sokolow wrote:
Is there a command-line validator tool for the format I should use?
Great, thanks.
Sounds good.
OK, will do.
--
bye,
pabs
https://bonedaddy.net/pabs3/
Yes, but the upstream maintainership situation is... less than satisfactory and it's no longer in sync with the published spec. (eg. It'll reject valid
<description>markup with confusing error messages and reject valid<url>types, among other things.)The fork you're supposed to use is available as:
EDIT: They also want the
.desktopfile to passdesktop-file-validate <FILENAME>(available indesktop-file-utilson Debian-family distros) if you're not already using that.Last edit: Stephan Sokolow 2022-09-20