[idea] Publish a flatpak on Flathub

[denilsonsa]

Flatpak is a distribution-agnostic package system where the application is shipped with all the dependencies and runs inside some kind of sandbox. It's relatively new, and is gaining quite a lot of popularity.

Additionally, Valve's Steam Deck supports Flathub out-of-the-box. In fact, its main OS is mounted read-only, so people must either use flatpak or manually install it themselves in their home directory. The easiest way to run anything on Steam Deck is through Flathub. (Well, the easiest is actually through Steam store itself.)

[shlomif]

hi,

I suggest installing librinutils from its tarball: https://github.com/shlomif/rinutils/tags

@shlomif

========================================================================
Building module fc-solve in /home/ssokolow/src/PySolFC_flatpak/.flatpak-builder/build/fc-solve-16
========================================================================
-- The C compiler identification is GNU 12.1.0
-- The CXX compiler identification is GNU 12.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Perl: /usr/bin/perl (found version "5.36.0") 
Cloning into 'rinutils'...
fatal: unable to access 'https://github.com/shlomif/rinutils.git/': Could not resolve host: github.com
CMake Error at cmake/rinutils_bootstrap.cmake:24 (MESSAGE):
  Could not find rinutils anywhere - it should have been bundled in the
  releases' source tarball.

  You can try installing it from a source release or from its repository:
  https://github.com/shlomif/rinutils

  Also see: https://github.com/shlomif/fortune-mod/issues/44
Call Stack (most recent call first):
  CMakeLists.txt:222 (RINUTILS_SET_UP_FLAGS)

Looks like https://fc-solve.shlomifish.org/downloads/fc-solve/freecell-solver-6.6.0.tar.xz has the same problem I was having to hack around with the git repositories. For reasons of reproducibility, flatpak-builder separates the build process into distinct download and build phases and no custom code is allowed during the download phase.

...and I can't just pull in rinutils manually, because that's what I've been trying to do and what's been ignoring my -DCMAKE_MODULE_PATH=/app/lib/cmake and pitching a fit because flatpak-builder doesn't let me install things to /usr/share/cmake/Modules/Shlomif_Common.cmake.

@joeraz How would you feel about releasing a Flatpak without the solvers initially, to not delay the release, then adding the solvers later once this mess gets resolved somehow? ...because aside from those solvers, what I've pushed does produce a build that's fully functional under every test I tried and meets or exceeds every goal I'd set myself for a release-ready Flatpak package.

You could add a note about the solvers to the description that gets displayed on Flathub. I've seen other packages do that to communicate differences between the Flathub release and other releases.

[ssokolow]

@shlomif Ahh. I missed that it had separate release tarballs, since the README didn't mention it and there was no site link.

I've now got the solvers building and working and I'm just trying to figure out why a regex isn't matching for the x-checker-data on rinutils before I push the changes.

The solvers' Perl deps don't have x-checker-data entries because flatpak-cpan-generator.pl doesn't have an option to emit them but, to be honest, I'm so tired of working on the solvers that I'll leave it to someone else to decide whether they want automatic notification and PR generation for updates to the solvers' Perl dependencies badly enough to hand-write the x-checker-data entries rather than just brute-forcing the problem by periodically running the command documented in NOTE_TO_MAINTAINERS.md to regenerate solvers_extra_deps.json.

(Conversely, if you find you're getting too many notifications about updates to Python dependencies, you can run the flatpak-pip-generator command from NOTE_TO_MAINTAINERS.md without the --checker-data argument to regenerate the relevant portion of the manifest without the x-checker-data entries and then just periodically re-run it to pull in any updates that have been released in the interim.)

[ssokolow]

Done. I've pushed the updated files to https://github.com/ssokolow/PySolFC_flatpak and they should be ready to go.

That's the limit of my expertise regarding Flatpak and Flathub but, if my own experience is any indication, whoever reviews your submission will point out any little things I've overlooked before creating the repo under the flathub GitHub organization and giving you access.

Again, the submission guidelines are at https://github.com/flathub/flathub/wiki/App-Submission and you just need to remember to either uncheck "Fork only master" or manually use the GitHub interface to add the new_pr branch to your fork so you can follow their instructions for creating a new branch from it.

Just remember that the screenshots folder and the proof-of-concept take_screenshot.py were intended for you and should be filtered out from what gets included in the submission.

I may come back to complete take_screenshot.py into a full-blown screenshot-taking automation and check off some of those "nice to have" entries after I've done some of the other Flatpak manifests that I'd expected to be starting on weeks ago.

[shlomif]

@ssokolow : hi. Thanks for your work, your patience, and your perseverance:

https://www.shlomifish.org/links.html#motivational_videos

[joeraz]

@ssokolow Thanks. So to summarize, once I've tested myself, I just have to PR the files from your repo as they are against the flathub repo, minus the .md and screenshots files. Then, the flathub maintainers will review and add the app, correct?

[ssokolow]

I just have to PR the files from your repo as they are against the flathub repo, minus the .md and screenshots files.

Do follow their instructions but, yes. Basically that. I'd try to keep the NOTE_TO_MAINTAINERS.md file in some form though. (eg. pruning it down to the first three points under "Regarding io.sourceforge.pysolfc.PySolFC.json") It'll help to raise the bus factor.

Then, the flathub maintainers will review and add the app, correct?

Yeah. Someone will look through your submission, possibly propose a few changes (eg. I'd forgotten to use install instead of cp for copying certain files into place that weren't covered by I Have No Tomatoes's Makefile, and they corrected that), and then invite you to a new repo under the flatpak organization containing your submission.

From that point onward, you'll be directly maintaining the Flathub release by using that repo to control their build farm.

Any PR or push/merge to main will trigger a build, with PRs producing test builds and pushes/merge to main triggering release builds that then go live about three hours later. (A grace period to allow you to catch any mistakes and push corrections.)

The intended workflow is that, whenever it's time to push a change to Flathub, you make a PR, test the build the bot makes using the flatpak install command it'll post in a comment and, once it looks good, merge it to main and let their infrastructure handle the rest.

[joeraz]

@ssokolow Preparing the PR, I noticed two things, and have a couple final questions:

• Should I merge the 0001-allow-app-paths.patch patch into the main codebase, or are you looking for a better fix?
• When doing some final testing, I noticed I wasn't getting music when I tried to run the app through the icon after installing with the flatpak builder, though it played fine when I started it through the console. Did you encounter this, or might it just be something off on my environment?

[ssokolow]

Should I merge the 0001-allow-app-paths.patch patch into the main codebase, or are you looking for a better fix?

You can merge it if you want.

The solution I'd like to keep on the TODO list is for the code to do something like walking up the filesystem from __file__ until it's seen a site-packages inside a python*.* inside a lib and then use the parent of lib as the install prefix to construct $PREFIX/share.

Apparently there's no more proper way to retrieve the install prefix that flatpak-builder feeds to pip3 install.

When doing some final testing, I noticed I wasn't getting music when I tried to run the app through the icon after installing with the flatpak builder, though it played fine when I started it through the console. Did you encounter this, or might it just be something off on my environment?

I overlooked that. It's because I forgot to patch the .desktop file to use the pysol wrapper that I added to set LD_LIBRARY_PATH so it'll find /app/lib/libmodplug.so*.

When flatpak-builder rewrites the .desktop file to indirect through flatpak run, it converts the pysol.py it finds into a --command=pysol.py which bypasses the pysol wrapper.

The command-line works because I did set "command": "pysol" in the .json, which is what flatpak run uses if you don't pass --command=....

(I didn't want to just use --env in finish-args to set LD_LIBRARY_PATH because a user could click the wrong delete button in Flatseal or pass the wrong flatpak override option and unset the LD_LIBRARY_PATH customization, which would be confusing to diagnose.)

I'll try to get to it tomorrow if you haven't already.

[joeraz]

I merged the patched change in. It sounds like Flathub wants patches merged into the main code unless there's a reason not to.

I think all that's left is handling the desktop file.

[ssokolow]

There you go. Changes have been pushed to my repo.

Sorry for the delay for something so minor. Yesterday and today were unexpectedly messy.

I also separated the top-level PySolFC version bump (ssokolow/PySolFC_flatpak@e576247d27d0f5f24793b66d3b675b6062b1533a) and the portmidi version bump (ssokolow/PySolFC_flatpak@fcba929b23a7325ae5fda82291f522c9a8d0f8d0) to provide cleaner demonstrations of how to do a manual version bump if you're not delegating it to the bot.

[joeraz]

Done. Created https://github.com/flathub/flathub/pull/3571

[joeraz]

We're live on Flathub - https://flathub.org/apps/details/io.sourceforge.pysolfc.PySolFC - I'll post a notice on the main site a little later.

Thanks for everything!