feat: Flatpak support about viper

[0neGal]

So I can link it in the application PR, can you publicly confirm that I'm allowed to redistribute Viper via Flathub? ^^

I confirm :)

[0neGal]

I do think Flatpak is a thing that'd benefit Viper, however electron-builder doesn't support it (from what I know), so we'd have to have a separate build script for Flatpaks, I'll have a look at it at some point if nobody else can, but generally I'm open to supporting them.

As for the SteamDeck we still have to actually solve #38, which I plan on doing soon. Beyond that I have no clue how Viper will work on the SteamDeck considering the screen size and the fact that Viper currently doesn't allow for user resizable windows, even if I've tried to keep the UI mostly responsive between updates and simply disabled resizing, I'm not sure which parts aren't actually responsive in actuality.

Not to mention how we'd auto-fullscreen or whatever we may need to do when it is launched, I don't have a SteamDeck reserved, and likely won't have one any time soon, so if somebody does in fact have one when they become available it'd be amazing if said person could test Viper on it.

I'm not sure if we can deprecate other Linux formats in favour of Flatpak

Absolutely not, AppImage at the very least will remain a format, as I know many people who have a grudge against Flatpaks, but I also know many who have it against AppImages etc, since they handle sandboxing and alike differently. Also there's a major difference in app sizes, which deter some users from using Flatpaks and staying with AppImages.

There's many reasons to hate both formats, and the reasons above are the reason I much prefer AppImages, but I still wanna point out how I'm completely on board with still adding it as a format, as I see where it's useful.

[GeckoEidechse]

The biggest issue with Flatpak support is how we build it, as I've stated before, I've no clue how to do that

Last time I investigated this, I found a bunch of resources that might be of use to speed up researching ^^

• Official docs regarding Electron and Flatpak: https://docs.flatpak.org/en/latest/electron.html
• Electron to Flatpak converter: https://github.com/endlessm/electron-installer-flatpak
• Sample Electron Flatpak app: https://github.com/endlessm/electron-flatpak-base-app

[0neGal]

Regarding the package id, is com.github.OneGal.viper alright or do you want it changed (apart from limitations with digits in name)?

com.github.onegal.Viper seems the best, imo...

Honestly, I'm not quite sure... Starting viper after a clean build of 1.2.4 via Flatpak, pressing a few buttons and closing it again, gives this:

Additionally, trying to run it with --update-vp and then closing the window again after a bit gives this:

From what I know: APPIMAGE env is not defined, current application is not an AppImage is the reason it doesn't update :p, although I still think we need the argument/need to implement it not only in the settings but also in the actual update function, even if it fails in the end, no need to have useless errors if they can easily be ignored... :)

[MysteriousRSA]

This sounds like a really good idea, then all major Linux distros can simply get one package from one remote, be up to date and functional

[GeckoEidechse]

So looking at currently release material around steamdeck, flathub seems to be the source for flatpaks on steamdeck and flatpaks are installed via Discover and can be added as non-Steam games.
So publishing on Flathub together with fixing #38 would give us ootb Linux support :D

Bonus: Apparently Steamdeck runs Titanfall 2 quite well: https://twitter.com/killyourfm/status/1498385708100292608

[0neGal]

So publishing on Flathub together with fixing #38 would give us ootb Linux support :D

That issue is still annoying to solve, as there's no easy way to detect what Wine/Proton version to run with or its settings etc... Or just in general whether to even run it through that, overall, Linux launch support by itself is easy, making it work automatically and OOTB is not.

The biggest issue with Flatpak support is how we build it, as I've stated before, I've no clue how to do that, however if someone figures that out feel free to comment on it here... When I get the time I'll try researching it myself, but I can't give an ETA on that.

[GeckoEidechse]

Alternatively to building from source we could probably just pull the AppImage and place it inside the Flatpak runtime, similar to how popular proprietary apps on Flatpak do it. Examples here and here.

Once that is setup we can then try to figure out how to do it "properly" later :P

Only issue with the AppImage, is that we need to had some logic to make sure it has self-updating features disabled as that stuff should be handled by Flatpak.

[0neGal]

Only issue with the AppImage, is that we need to had some logic to make sure it has self-updating features disabled as that stuff should be handled by Flatpak.

Hm, there's likely some changes to the filesystem for Flatpaks that we can detect, unless it doesn't sandbox it like that? That or we can just have a build script that makes a file which when present will disable the auto update, then it'll remove it after the Flatpak is built?

Once that is setup we can then try to figure out how to do it "properly" later :P

If we can get all that to work, considering everything, there's not much reason to do it "properly", if it works it works, and there won't be a difference on the users end... (I Think?)

[GeckoEidechse]

Hm, there's likely some changes to the filesystem for Flatpaks that we can detect, unless it doesn't sandbox it like that? That or we can just have a build script that makes a file which when present will disable the auto update, then it'll remove it after the Flatpak is built?

One could probably detect or set (at build time) some at build time that indicates to the AppImage that it is being run inside a Flatpak environment.
(Though I couldn't figure out how to in my 5 minutes of google foo)

Personally I'd go for disabling the update check at build time by making a second AppImage target called viper-flatpak or something along the lines, though I have no idea how to do that / if it's even possible with electron builder. ^^

[0neGal]

Personally I'd go for disabling the update check at build time by making a second AppImage target called viper-flatpak or something along the lines

Perhaps there's a way to get the name of the AppImage file? Then we simply check for that, and disable auto updates accordingly...

... though I have no idea how to do that / if it's even possible with electron builder. ^^

We can just add it to the build.sh or add an extra build script like we already have for the various platforms (npm run build:linux or npm run build:windows)

[GeckoEidechse]

Apparently electron-builder has basic Flatpak support as a target (added via electron-userland/electron-builder#5711)

However I haven't managed to get it running inside the electron-builder Docker container:

root@bd070631ac8d:/project# npx electron-builder --linux flatpak
  • electron-builder  version=22.14.5 os=5.4.0-105-generic
  • loaded configuration  file=package.json ("build" field)
  • writing effective config  file=dist/builder-effective-config.yaml
  • packaging       platform=linux arch=x64 electron=16.0.5 appOutDir=dist/linux-unpacked
  • building        target=flatpak arch=x64 file=dist/Viper-1.2.5-x86_64.flatpak
  ⨯ spawn flatpak ENOENT  failedTask=build stackTrace=Error: spawn flatpak ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:269:19)
    at onErrorNT (internal/child_process.js:467:16)
    at processTicksAndRejections (internal/process/task_queues.js:82:21)
root@bd070631ac8d:/project#

Maybe you have more success when building natively / outside of Docker environment? ;)

[0neGal]

Maybe you have more success when building natively / outside of Docker environment? ;)

I got the same error, realized by "spawn" it means execute, i.e the command flatpak failed, then I installed the flatpak and flatpak-builder packages and I now get a completely different error. Keep in mind this is over a server environment (away from my desktop rn), even tho I doubt it, it might not like not having a GUI, idk...

  • electron-builder  version=22.14.5 os=5.16.13-arch1-1
  • loaded configuration  file=package.json ("build" field)
  • writing effective config  file=dist/builder-effective-config.yaml
  • packaging       platform=linux arch=x64 electron=16.1.0 appOutDir=dist/linux-unpacked
  • building        target=flatpak arch=x64 file=dist/Viper-1.2.5-x86_64.flatpak
  ⨯ flatpak failed with status code 1  failedTask=build stackTrace=Error: flatpak failed with status code 1
    at ChildProcess.<anonymous> (~/Gits/viper/node_modules/@malept/flatpak-bundler/index.js:71:16)
    at ChildProcess.emit (node:events:527:28)
    at maybeClose (node:internal/child_process:1090:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)

I'll try and see what I can do after fixing the Flatpak Steam issue...

[GeckoEidechse]

Alternatively to building from source we could probably just pull the AppImage and place it inside the Flatpak runtime, similar to how popular proprietary apps on Flatpak do it.

Seems like simply putting the AppImage inside a Flatpak container is not an option (due to AppImage using FUSE and such) but "converting" them should be an option according to this reddit thread.

[GeckoEidechse]

Searching for Flathub released Flatpaks I found one that unpacks an AppImages and uses only a small manifest.

I modified it a bit and managed to build and run Viper with it :D
Here's the current manifest I have:

app-id: com.github.OneGal.viper
base: org.electronjs.Electron2.BaseApp
base-version: '20.08'
runtime: org.freedesktop.Platform
runtime-version: '20.08'
sdk: org.freedesktop.Sdk
command: viper-run
separate-locales: false
tags: []
finish-args:
  - --socket=x11
  - --share=ipc
  - --share=network
  - --device=dri
  - --filesystem=host
modules:
  - name: unappimage
    buildsystem: simple
    build-commands:
      - make -C squashfs-tools -j ${FLATPAK_BUILDER_N_JOBS} install INSTALL_DIR=/app/bin
    sources:
      - type: git
        url: https://github.com/refi64/unappimage
        commit: d7f86f2a0d7ec3a69211125207d5f127386b849a

  - name: viper
    buildsystem: simple
    build-commands:
      - unappimage Viper-1.2.5.AppImage
      - rm Viper-1.2.5.AppImage
      - mv squashfs-root /app/bin/viper
      - install -D viper-run -t /app/bin

    sources:
      - type: script
        dest-filename: viper-run
        commands:
          - zypak-wrapper /app/bin/viper/viper "$@"
      - type: file
        filename: Viper-1.2.5.AppImage
        url: https://github.com/0neGal/viper/releases/download/v1.2.5/Viper-1.2.5.AppImage
        sha256: 21e1c2f456c7318256fb8bd15d229e50f8392f372c99c6bf3fd89bb5524c73f6
        size: 103176664

[GeckoEidechse]

Aight, I pushed up the proof-of-concept Flatpak that just takes the AppImage and unpacks it inside the Flatpak environment.
https://gitlab.com/GeckoEidechse/viper-flatpak

I still need to check permissions, .desktop entry, and Flathub support but this should give us at least some starting point.

Of course, optimal version would be to just use electron-builder with Flatpak target but support doesn't seem to be quite there yet, sadly :/

[GeckoEidechse]

Aight looks like can now consistently build a Flatpak version from the AppImage. Currently this pulls the AppImage from the Github release page so not really helpful for adding it as a target on github release but perfect for releasing on Flathub :P

We probably wanna look into adding it a package there soon: https://github.com/flathub/flathub/blob/master/CONTRIBUTING.md

Also before you say anything, the reason the package id is com.github.OneGal.viper (letter O) and not com.github.0neGal.viper (zero) is due to (parts of) the id not being allowed to start with a number ¯\_(ツ)_/¯

[0neGal]

Currently this pulls the AppImage from the Github release page

Any way to add variables or similar as to not change the same number multiple places just to update the version?

Also before you say anything, the reason the package id is com.github.OneGal.viper (letter O) and not com.github.0neGal.viper (zero) is due to (parts of) the id not being allowed to start with a number ¯_(ツ)_/¯

That seems rather dumb, and like a useless limitation.

[GeckoEidechse]

Any way to add variables or similar as to not change the same number multiple places just to update the version?

Not that I'm aware of. My solution would have been a small Bash or Python script that just regex replaces the version numbers and updates file hash and size. Commit that and push it to the repo under Flathub org and flathub-bot takes care of building and publishing. Would have to do that on any new Viper release of course but once things are set up we probably wanna look into automating that any way.

Regarding the package id, is com.github.OneGal.viper alright or do you want it changed (apart from limitations with digits in name)? That's one of the few things set in stone after the successfully publishing on Flathub, so I wanna be sure it's set correctly. ^^

[GeckoEidechse]

Also while within Flatpak environment the auto-update part of the AppImage fails somehow anyway and therefore prevents updates other than Flatpak, I think it would probably make sense to add a --skip-viper-update-check cli arg, to make sure that Flatpak updates only arrive via remote Flatpak repository (e.g. Flathub).

[0neGal]

Also while within Flatpak environment the auto-update part of the AppImage fails somehow anyway

In what way does it fail? Does it spit anything out on in the logs?

I think it would probably make sense to add a --skip-viper-update-check cli arg, to make sure that Flatpak updates only arrive via remote Flatpak repository

Agreed.

[GeckoEidechse]

Also while within Flatpak environment the auto-update part of the AppImage fails somehow anyway

In what way does it fail? Does it spit anything out on in the logs?

Honestly, I'm not quite sure... Starting viper after a clean build of 1.2.4 via Flatpak, pressing a few buttons and closing it again, gives this:

$ flatpak run com.github.OneGal.viper 
[3 zypak-helper] Portal v4 is not available
Gtk-Message: 14:26:03.930: Failed to load module "canberra-gtk-module"
Gtk-Message: 14:26:03.930: Failed to load module "canberra-gtk-module"
[3:0324/142603.980692:ERROR:bus.cc(393)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
APPIMAGE env is not defined, current application is not an AppImage
Checking for Northstar updates...
No Northstar update available.
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[35:0324/142604.152489:ERROR:sandbox_linux.cc(376)] InitializeSandbox() called with multiple threads in process gpu-process.
APPIMAGE env is not defined, current application is not an AppImage
Checking for updates...
Latest version (v1.5.1) is already installed, skipping update.
APPIMAGE env is not defined, current application is not an AppImage
APPIMAGE env is not defined, current application is not an AppImage
[11 zypak-sandbox] Dropping 0x55c674b4b290 (3) because of connection closed
[11 zypak-sandbox] Host is gone, preparing to exit...
[11 zypak-sandbox] Quitting Zygote...

Additionally, trying to run it with --update-vp and then closing the window again after a bit gives this:

$ flatpak run com.github.OneGal.viper --update-vp
[3 zypak-helper] Portal v4 is not available
Gtk-Message: 14:27:04.154: Failed to load module "canberra-gtk-module"
Gtk-Message: 14:27:04.154: Failed to load module "canberra-gtk-module"
[3:0324/142704.205613:ERROR:bus.cc(393)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
APPIMAGE env is not defined, current application is not an AppImage
Checking for Northstar updates...
No Northstar update available.
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[35:0324/142704.435952:ERROR:sandbox_linux.cc(376)] InitializeSandbox() called with multiple threads in process gpu-process.
APPIMAGE env is not defined, current application is not an AppImage
[11 zypak-sandbox] Dropping 0x55b8610d3290 (3) because of connection closed
[11 zypak-sandbox] Host is gone, preparing to exit...
[11 zypak-sandbox] Quitting Zygote...

[GeckoEidechse]

So I can link it in the application PR, can you publicly confirm that I'm allowed to redistribute Viper via Flathub? ^^

[GeckoEidechse]

Submission for Flathub has been accepted :D

The created repo can be found here: https://github.com/flathub/com.github._0negal.Viper

Once published (there's a default 3 hour delay between build and publish on Flathub), it can be found here: https://flathub.org/apps/details/com.github._0negal.Viper