Publish releases on Snap or Flatpak

[Jacalz]

It would be wonderful if you could set this up as a snap or a flatpak application. It would help with making it easier to test and use on different distributions on Linux. Really great looking project btw 👍

[kivutar]

I've merged 2 PRs that should help with linux packaging in general, allowing to set important paths.

[RobLoach]

For Flatpak, I've worked on org.libretro.RetroArch. Could use that as a frame of reference.

[ShubhamKJha]

Hi! Can I take up this issue.

[kivutar]

Yes

[predr]

@kivutar I have a working snap but I run into an issue with $HOME path. Snaps rewrite $HOME internally to separate and restrict environment (confinement good because roms). Problem is path to settings always resolves to /home/user/.ludo no matter what $HOME is set to and that is not accessible to ludo from snap. So I need to change path resolving to respect $HOME env.

@RobLoach Is this a problem for flatpak also?

[RobLoach]

That's by-design for both flatpak and snap. It tries to protect the home directory by pseudo-sandboxing the environments. For Flatpak, we added --filesystem=host to the flatpak definition file, for snapcraft, I think you use - home plug?

See https://github.com/libretro/retroarch-snap for some inspiration.

Strange that while the environment setting is overwriten, it's still forced to /home/user/.ludo. Do you have any idea why that is? snap/flatpak do a pretty good job overwriting those, so I'm rather surprised.

[predr]

It's because usr.HomeDir pulls from /etc/passwd and completely ignores $HOME. os.UserHomeDir() might be a solution, or just using os.Getenv('HOME') and if empty fallback to usr.HomeDir for other systems. Working on it.

Snap is working and runs roms manually but unable to load/save anything in .ludo because of $HOME issue.

[kivutar]

OK I've merged your PR

[predr]

Nice. I'm waiting on snapcrafters to grant auto-connections for ludo snap (joystick and reading access for usb drives and $HOME/.ludo). Snap is made from Ludo's latest Github release so I'm also waiting for next release. I can change it to build from source but if I do that it will build with different core versions #108. After that I'll share it for people to test.

[predr]

Cleared on snapcraft side, waiting for 0.10.5 release. Please test snap and report issues.

[kivutar]

I made a new release @predr

[predr]

@kivutar v0.11.0 snap is released. Works great except for new snap related issues with paths in settings.toml, now visible. Fixable in snap, no changes to ludo code needed.

[pdureau]

That's great snap-side. What about Flatpak?

[predr]

Fixed remaining issues, next step is changing snap visibility from unlisted to public. Before I do that @kivutar do you want snap ownership transferred to your name?

Edit: Switched to public because there is high demand for games right now. Let me know if you want ownership when you can.

[pdureau]

Hi all, I have initiated a flatpak manifest file which works well so far: https://github.com/pdureau/flatpak-manifests

I will use it as my main ludo instance next days. What would be the next steps?

[kivutar]

Cool, so we have both snap and flatpack working if I understand well?

[predr]

Snap is done. https://snapcraft.io/ludo

Flatpak still needs to be put in store. https://flathub.org/apps/search/ludo @RobLoach can help with that.

[pdureau]

Hello,

I am using my flatpak package for a few weeks and it seems to work well. However, he can't be submitted to Flathub yet because it miss some requirements:.

I will fix soon the easy ones:

• Manifests should therefore refer to tarballs or git tags and not the tip of a branch.
• Flathub always builds in the flatpak branchname "stable"
• Unnecessary files should be added to cleanup, in order to ensure smaller package sizes.
• Applications must provide appstream data
• Applications must provide application icons in at least 64×64px and 128×128px sizes. > I am providing only a 128x128px SVG
• If an application hardcodes a path in $HOME and you don’t grant home access you can use --persist.

However, one looks problematic:

• "Accessing the network is not allowed during the build process, to download extra files, everything that an app requires must be included within the manifest." > Ludo download some stuff during the building.

Source: https://github.com/flathub/flathub/wiki/App-Requirements

[kivutar]

Thanks a lot guys for taking care of this.

@pdureau What about using the binary releases here? They are tarballs https://github.com/libretro/ludo/releases and already include all the files. Or flathub really insists on building from source?

[RobLoach]

Nice work, all! Looks like a solid manifest. Is there a way to use the manifest without having to publish to flathub? Their workflow is pretty strict, and could hold us back on release cycles.

[pdureau]

@kivutar : I will check what is possible with binary releases.

@RobLoach : I already use the manifest locally publishing the flatpak in my local repo. As a first step, ludo code base may need to add the desktop & appdata files to its codebase.

[kivutar]

As a first step, ludo code base may need to add the desktop & appdata files to its codebase.

I'm OK to merge a PR that adds this

[kivutar]

Hi @pdureau Are you still interested in sending your flatpak to flathub?

[pdureau]

Hi @kivutar Sure I am. I hope I will less busy late summer to work on it.

[kivutar]

I added support for XDG, I hope it can help.

[johnnyq]

@pdureau Flatpak support would be fantastic!

[dhitchcock]

was hoping to try this on my steam deck, need that flatpak!