Flatpak distribution about quakespasm HOT 5 CLOSED

Hello again!

Hey!

does not ship with libopusfile installed which the binary Quakespasm builds require.

QS does not require libopusfile by default though.

I've put together a Flatpak build for Quakespasm
[...]
The build I've put together is a mostly default Quakespasm build with the exception of building SDL2 instead of 1.2

That's good

[...]
and XMP (which I could easily switch to Mikmod if you'd prefer this)

No, libxmp is good and should be preferred over libmikmod

As with Hammer of Thyrion, I'll be happy to take care of maintenance of these builds and reproducing any issues users report with the Flatpak builds; and as with HoT Flathub's submission requirements need me to ask for permission from you to distribute Quakespasm this way - is this okay with you?

Yes. Thanks!

from quakespasm.

QS does not require libopusfile by default though.

Oh, I may be getting things confused with Quakespasm-spiked which does. I couldn't get the regular QS binary builds running without package modifications for some reason... libmad perhaps (which also isn't installed on SteamOS by default)?

PR submitted to Flathub, as seen above :)

from quakespasm.

without package modifications for some reason... libmad perhaps (which also isn't installed on SteamOS by default)?

Don't know. However, if you want mp3 support you can use mpg123 (libmpg123) instead of libmad by adding MP3LIB=mpg123 to your make command line.

PR submitted to Flathub, as seen above :)

OK.
Is there anything that needs adding at QS side?

from quakespasm.

Flathub have requested the appstream metadata be stored upstream; however with QS that's going to be a little more complicated than with Hammer of Thyrion as QS is still quite regularly getting new releases and the metadata includes a mandatory <releases> element.

I'll put together a GitHub workflow that'll run when a new release is created which'll update the .xml file with the tag version and a link to the release changelog page and then updates the tag to that commit - for a start I'll just create a PR for the appdata.xml file with the workflow to follow if that's okay?

Just realised that that's a minor issue because it'd result in a drift between the Sourceforge and Github versions of the repo. I'll check whether the releases element is actually necessary in terms of upkeep or if its contents are optional...

from quakespasm.

I guess this can be closed after #87

from quakespasm.