search

vassalengine / vassal

VASSAL, the open-source boardgame engine
https://vassalengine.org
GNU Lesser General Public License v2.1
403 stars 96 forks source link

Flatpak release for Linux #11853

Open 12people opened 1 year ago

12people commented 1 year ago

It'd be great if Vassal could offer Flatpak releases for Linux.

Flatpak is an increasingly popular sandboxed and distro-independent way of packaging apps for Linux. It's bundled with a large number of distros, from Fedora to Pop! OS to Linux Mint, and is the only way to install apps on immutable operating systems like Steam OS or Fedora Silverblue.

Here's the documentation for building Flatpaks. And here's an example of a Java app's Flatpak.

As a Flatpak, Vassal could then be released on Flathub, the most popular repository of Flatpak apps.

uckelman commented 1 year ago

I'd be willing to review it were you to submit a PR.

BrentEaston commented 1 year ago

Hi @12people, Sounds like a great idea, but we have limited resources to do this at the moment. Do you have the tech skills to set this up?

12people commented 1 year ago

Hi @BrentEaston, I've been a bit short on time lately, but I can take a look at it when I find the time to.

lmcx commented 1 year ago

Hi,

I had the same need so I made a very simple flatpak manifest for VASSAL. It can be found here : https://github.com/lmcx/org.vassalengine.vassal

@uckelman I would recommend to create a new repo for that and not push it to the source one.

This simple flatpak manifest has been tested on Fedora Silverblue 37 with VASL 6.6.5.1. It installs VASSAL with Flatpak, creates a .desktop file and makes it visible with its .svg icon. Modules loading and online games seem to work fine.

It can be tested with :

$ flatpak-builder --user --install --force-clean build org.vassalengine.vassal.yml
$ flatpak run org.vassalengine.vassal

The second command is not mandatory since Vassal should be available in the user's softwares list after the first one.

You can then uninstall it with : $ flatpak uninstall org.vassalengine.vassal

Feel free to take the code and use it at your convenience. Though, I'd be happy to help to get it to Flathub if needed.

lmcx commented 1 year ago

Quick update : I modified the manifest so it builds from source instead of downloading the binary. This would allow to implement portals through a patch, instead of giving direct access to the user's home folder.

I am not a good enough java dev to implement that by myself though, if that seems like something Vassal's devs would like to see I could help with the "Flatpak part" but might need to be guided through the code.

12people commented 1 year ago

Thanks for the Flatpak! I created a similar one, just didn't have time to test it.

As for portals, it should be possible to implement those via Gnome's "Zenity" shell program — see this Reddit thread for info.

Unfortunately, I still don't have time to work on this, though.

I would recommend keeping this issue focused on the Flatpak and creating a separate issue for the portals.

lmcx commented 1 year ago

Portals are highly recommended in Flathub publishing requirements so I don't know if it is such a good idea to separate the two subjects.

ATLauncher's FileChooserDialog could be a better source of inspiration for portals.

I guess most of the work could be done in FileChooser.java with a DBusFileChooser class extending FileChooser and instantiated in createFileChooser() if "/.flatpak-info" exists on the system.

This could be done with a patch in the Flatpak manifest instead of the main source code, if that is not something Vassal devs want to keep in their releases.

I have been trying to implement this class, but due to my lack of experience with Java it has been a quite painful task so far. This might require an actual Java dev to be implemented properly.

Even with this class done, there is still a solution to find for the $HOME/.VASSAL/ directory and its content, which are not accessed via FileChooser. Probably with the Documents portal.

12people commented 1 year ago

@lmcx

As long as there is a contributor willing to implement it, I'm all for it. If not, though, I'm worried the Flatpak will never be released.

If there isn't anyone here actively working on it, I still think it would be better to do this piecemeal and release the Flatpak first, then make file portal changes.

lmcx commented 1 year ago

@12people I just upgraded to 3.6.17, would you have time to check if you see anything weird in the manifest and patch, and try and play with the flatpak a little before I submit a PR to Flathub ?

12people commented 1 year ago

Unfortunately, I've been finding it hard to find free time lately. :(

So I unfortunately don't have time to test this.

However, I did quickly look at the files in your repo:

The Desktop file

The appdata file

The Flatpak manifest

lmcx commented 1 year ago

@12people

Unfortunately, I've been finding it hard to find free time lately. :(

So I unfortunately don't have time to test this.

That might be better to wait for someone else to test it before submitting a PR. I am not really comfortable with the idea of releasing without properly testing.

However, I did quickly look at the files in your repo: [...]

Great suggestions, thanks. I fixed all that.

The Flatpak manifest

* I don't think Flathub maintainers will allow you to have extra files in the repo reserved for the manifest. I think you'll need to create a PR for those files here so that they're bundled along with the source code. That would mean you'd only have the git repo in sources and would need to change your build commands to reflect that.

I am not sure to completely understand what you are talking about. If you have the org.vassalengine.vassal.desktop file in mind, it seems to be quite common to provide it that way (e.g.: https://github.com/flathub/com.google.ChromeDev).

If you are talking about the vassal shell script, I guess it could be done with a patch on https://github.com/vassalengine/vassal/blob/master/dist/VASSAL.sh instead, and then would not need to push the file anywhere.

* Flathub definitely doesn't allow access to the network during the build process. So you'll need to remove `build-args: - --share=network`. Do you need it, though?

Sadly, when disabling it Maven gets really grumpy :

patching file Makefile
Running: make release-linux
./mvnw versions:set -DnewVersion=3.6.17 -DgenerateBackupPoms=false
Exception in thread "main" java.net.UnknownHostException: repo.maven.apache.org
    at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:567)
    at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
    at java.base/java.net.Socket.connect(Socket.java:633)
    at java.base/sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:304)
    at java.base/sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:174)
    at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:183)
    at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:531)
    at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:636)
    at java.base/sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:266)
    at java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380)
    at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:193)
    at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242)
    at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128)
    at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:179)
    at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665)
    at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589)
    at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:224)
    at org.apache.maven.wrapper.DefaultDownloader.downloadInternal(DefaultDownloader.java:95)
    at org.apache.maven.wrapper.DefaultDownloader.download(DefaultDownloader.java:85)
    at org.apache.maven.wrapper.Installer.createDist(Installer.java:84)
    at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:160)
    at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:73)
make: *** [Makefile:101: version-set] Error 1
Error: module vassal: Child process exited with code 2

I checked and you are right: network is disabled by Flathub during build. So there might be another way to bring these dependencies to the build process, but as previously said I am not a Java dev (and, to be completely honest, don't plan on becoming one) and am clearly juggling in the dark with that part.

As long as nobody with strong enough Java/Maven/... skills is OK to provide some help, I won't invest more time in that, sorry.

uckelman commented 1 year ago

One of Maven's jobs is to fetch dependencies. You're going to have a hard time doing that without internet access. Are there any Flatpack releases of other projects which use a dependency manager? A lot of Python projects use pip or poetry, and most Rust projects use cargo. Those also fetch dependencies. Could you check how they handle it?

I see people commenting on this in various places:

https://github.com/flatpak/flatpak-builder/issues/211 https://github.com/flatpak/flatpak-builder/issues/58 https://discourse.flathub.org/t/is-building-via-maven-gradle-with-depedency-fetch-from-mavencentral-currently-supported/3918/4

12people commented 1 year ago

@uckelman The way this is done is to download the dependencies straight from source, not via a dependency manager.

@lcmx I guess I don't see the reason why the app should be compiled via Flatpak. Unlike native apps, Java apps run in the Java Virtual Machine and therefore don't need to be compiled for a specific architecture. Can't you just ship the precompiled release package like you did in your initial Flatpak proposal?

As for the other files in your repository, I have first-hand experience of my first proposed app to Flathub being rejected for exactly this reason. It's true that there are indeed some apps on Flathub that have a few other files than the manifest in their repo. However, I've been told that this is done only for those apps where the upstream doesn't want to collaborate on an official Flatpak and thus won't include Flatpak-specific files in their repo. (Such as Google Chrome.)

lmcx commented 5 months ago

@uckelman @12people There is a PoC on my repo, using the maven-dependencies.yml file to pre-fetch everything before the build.

@12people Those three subjects are actually linked to a single question : is vassalengine team planning to incorporate Flatpak's specific stuff in their code ? I'm not trying to rebuild VASSAL based on a misunderstanding about Java, but on the hypothesis that the answer to this question might be "no".

We obviously could ship the precompiled package, but I don't think we should without integrating portals so ... same question.

But if the answer is yes, and someone is ready to :

Then yes, we should definitely ship the official release and not rebuild everything, and everything that's not the manifest and flathub metadata could then be removed.

Until then, my repo remains open for whomever is willing to try and implement those things.