Package the tool as .rpm, .deb, .pkg*, etc

[dreamer]

This depends on Steam adding support for compatibility tool lookup in system-wide locations. I created a feature request here: ValveSoftware/steam-for-linux#6310.

[TehFreek]

Fedora SRPM. Assumes /usr/share/Steam/compatibilitytools.d; edit spec file if the actual directory varies.

https://drive.google.com/open?id=1hR18fHD0NUd5ezxhkWoBPGE03X6vE2ET

[dreamer]

Hey, I am happy to include a spec file in repository, to make it easier for other distributions to pick it up - care to create a PR?

I need to retest with the latest version Steam client, but I presume feature request to Steam client is still valid, Steam does not look into this directory when looking for compatibility tools?

[TehFreek]

The thing is that there are two patches to the Makefile that I needed to apply, and there are also several Fedoraisms in the spec file so it isn't suitable for general consumption.

The Steam issue is still open, so we can reasonably assume that Steam doesn't look there yet; this was kind of a "preemptive strike".

[dreamer]

Cool, thanks :)

In the meantime, I will modify makefile and version.py, so no patches will be required.

[dreamer]

I made some changes to the makefile - one of patches can now be dropped from srpm (as of 0.3.1)

[TehFreek]

SRPM updated to 0.4.0. The patches have been dropped, but still not de-Fedora'd.

https://drive.google.com/open?id=1FvAhfXj72uMAICeyWQehAwfkXres443W

[dreamer]

I think %prep section can be dropped - version.py with expected content should be created as a result of %make_install prefix=/usr version="v%{version}-%{_dist}-rpm" (if it isn't, I would consider it a bug).

Is pathix.py necessary? I use the shebang I use, because I had some bad experiences with pointing directly to python3 interpreter in the past - if it works across the distros, I'll be happy to use direct path though.

[gasinvein]

@dreamer How about creating a flatpak and publishing on Flathub (for all distributions)? Steam flatpak now supports compatibility tool extensions (on the beta branch currently), which I believe should work out of the box.

[dreamer]

I am totally open to packaging using Flatpak. Providing tarball as a sole source of software is a pain point for the project. I have some tiny technical concerns, but they probably all can be addressed or I just don't know enough about Flatpak. @gasinvein what communication channel would be the easiest one to cooperate on this?

[gasinvein]

@dreamer I guess e-mail is the most the obvious, and addrees can be found in git repos.

[dreamer]

Heads up, Steam Beta now supports system-wide installation; I made some changes in Boxtron 0.5.3, which should make it easier to handle for packagers (version.py is no longer auto-generated, make install target works in line with GNU conventions and I prepared brief packaging guidelines: https://github.com/dreamer/boxtron/blob/master/PACKAGING.md).

@TehFreek are you still interested in packaging the tool as rpm?

@gasinvein I am a little bit lost when it comes to next steps for Flatpak release - what do we do now?

[gasinvein]

@dreamer If you are fine with my flatpak, we can just submit it to Flathub for review. It may require some updates and new testing, though, since I didn't touch it for some time now, but this can be done after submission.

[dreamer]

@gasinvein do you think it would be appropriate to bundle it with dosbox-staging instead of DOSBox SVN? Situation considerably changed since we last talked about this and dosbox-staging works a lot better than upstream version.

[gasinvein]

@dreamer Well, I'm not familiar with dosbox, but if it works better - I don't see any reason why not to bundle it.

[gasinvein]

@dreamer Oh, I've found an obstacle. Current Steam flatpak expects compatibility tool to be self-contained, i.e. placed in a single directory under compatibilitytoold.d. While your makefile now explicitly installs Boxtron itself to $prefix/share/boxtron, and it's manifest to $prefix/share/steam/compatibilitytoold.d/.

[dreamer]

I can prepare a separate target or option to Makefile to make installation self-contained; I didn't go this route for installations in /usr/*, because it would violate FHS - but Flatpaks do not have this limitation.

[gasinvein]

@dreamer Yes, an option for self-contained install would be nice. Flatpak generally follows FHS (just with uncommon prefix /app), the problem comes from the fact that a flatpak extension is mounted to a single directory in the sandbox. Steam flatpak changes pending: flathub/com.valvesoftware.Steam#491

[gasinvein]

@dreamer Steam flatpak changes merged, everything seems ready now. Should I submit Boxtron to Flathub?

[dreamer]

@gasinvein I still can't test it, but it seems to be a flatpak related issue on my system:

$ flatpak-builder test/ com.valvesoftware.Steam.CompatibilityTool.Boxtron.yml 

(flatpak-builder:831): Json-WARNING **: 15:52:41.753: Failed to deserialize "modules" property of type "gpointer" for an object of type "BuilderModule"
error: com.valvesoftware.Steam/x86_64/master not installed
Failed to init: Unable to find runtime com.valvesoftware.Steam version master

I do have Steam installed, but it doesn't start - sometimes giving me "missing libc.so.6" error (what?), but usually:

$ flatpak run com.valvesoftware.Steam 
bwrap: Can't make symlink at /home/dreamer_/Pictures: File exists

(I do use flatpak to install some apps on my machine and they work, e.g. RetroArch and Marker, so it seems like Steam package is triggering some flatpak bug)

Regardless, about the manifest file itself:

1) I don't see explicit reference to inotify-tools dependency - I presume it's part of a platform? 2) #TODO enable linting, requires shellcheck and pylint - well, even more packages are needed to enable linting, but I don't think this is necessary inside a package. If testing the package is not enforced via some Flathub convention, then this line can be simply dropped.

3. This line got me scratching my head a bit:

   • ln -sr ${FLATPAK_DEST}/share/steam/compatibilitytools.d/boxtron.vdf ${FLATPAK_DEST}/compatibilitytool.vdf

   because boxtron.vdf has an absolute path inside, derived from prefix=${FLATPAK_DEST} - so linking this is a tiny hack, but it should actually work.

Overall, if inotify-tools is provided by relevant flatpak Platform, then I'm ok with submitting it to Flathub.

[gasinvein]

I still can't test it, but it seems to be a flatpak related issue on my system: Failed to init: Unable to find runtime com.valvesoftware.Steam version master

For flatpak-builder the default branch is master, while Flathub's app builds are stable. To build the extension against Flathub-provided build, you'd have to explicitly set branch: and runtime-version: to stable in the Boxtron extension manifest (so that the app's branch matches extension's branch).

I don't see explicit reference to inotify-tools dependency - I presume it's part of a platform?

Does Boxtron need the binaries, e.g. inotifywait? If so, inotify-tools should be bundled indeed.

linking this is a tiny hack

It is. ${FLATPAK_DEST} here expands to /app/share/steam/compatibilitytools.d/Boxtron.

[dreamer]

Does Boxtron need the binaries, e.g. inotifywait

Yes, it does. It is used to block starting of a game until the process finalizing game installation finished: code (it's needed to simulate wineserver -w behaviour in Proton). At some point I plan to replace it with a python implementation, but it's a one-liner, so it's rather low priority for the project.

[gasinvein]

@dreamer Bundled inotify-tools.

[dreamer]

Looking forward to seeing it appear on Flathub then :)