linux-app
linux-app copied to clipboard
ProtonVPN
Publish on Flathub
I currently use ElementaryOS which is based on Ubuntu 18.04. It seems you are only support Ubuntu 20.04 for the debian packages. It would be nice if you could release the linux app as a Flatpak in Flathub (which allows me to use it in Elementary): https://github.com/flathub/flathub/wiki/App-Submission
Adding to Flathub requires you to create a manifest file similar to a CI build script: https://docs.flatpak.org/en/latest/
https://docs.flatpak.org/en/latest/
Hey @brodock
The linux app won't work on Ubuntu 18.04 bases but the CLI will.
Also atm there are no current plans to share it via flathub.
@calexandru2018 would you mind sharing what dependency doesn't work in Ubuntu 18.04? It seems the project is mostly python with https://github.com/ProtonVPN/protonvpn-nm-lib as dependency which is also python
@brodock when I mean the app I mainly mean the GUI. The library has no issues with Ubuntu 18.04. It's mostly the GUI that requires GTK 3.24, while Ubuntu 18.04 supports only up to GTK 3.22.
Yeah that was my thinking. So this is exactly where flatpak comes along. So you can bundle all dependencies in a single package. Think of it as a "portable" / containerized version.
If it's possible to package the ProtonVPN App/GUI into a Flatpak package, I think that would be great
I will try to have an unofficial Flatpak submited to Flathub next week. Then all thats left is ProtonMail's blessing to publish it.
@A6GibKm the community can definitely help and we appreciate it, really! But given that we don't officially support flatpack installations, we won't be able to provide support to our users, so it's worth to have that in consideration.
Yes, thats something that always has to be put into consideration. Right now I am not even sure if it is possible to run this sandboxed without upstream involvement, probably it is not (even with upstream involvement).
If anyone is interested in picking this up, here is a flatpak manifest that compiles, but won't run due to a library requiring hardcoded paths.
With the export app and the bridge this is not an issue, as the only noticeable differences would be the paths were data is located.
Yes, thats something that always has to be put into consideration. Right now I am not even sure if it is possible to run this sandboxed without upstream involvement, probably it is not (even with upstream involvement).
If anyone is interested in picking this up, here is a flatpak manifest that compiles, but won't run due to a library requiring hardcoded paths.
With the export app and the bridge this is not an issue, as the only noticeable differences would be the paths were data is located.
Data location should not be a problem as it's intended. I've built it and when it runs the error is about missing nmcli or other binaries. Do you find that an issue?
Yes, thats something that always has to be put into consideration. Right now I am not even sure if it is possible to run this sandboxed without upstream involvement, probably it is not (even with upstream involvement). If anyone is interested in picking this up, here is a flatpak manifest that compiles, but won't run due to a library requiring hardcoded paths. With the export app and the bridge this is not an issue, as the only noticeable differences would be the paths were data is located.
Data location should not be a problem as it's intended. I've built it and when it runs the error is about missing nmcli or other binaries. Do you find that an issue?
Well half of those binaries are indeed part of the runtime, so it is a problem that they are not found.
@A6GibKm I might be able to do the rest of the work. However, can you disclose how you generate the dependencies json? Seems not as simple as one line of https://github.com/flatpak/flatpak-builder-tools/tree/master/pip
@A6GibKm I might be able to do the rest of the work. However, can you disclose how you generate the dependencies json? Seems not as simple as one line of https://github.com/flatpak/flatpak-builder-tools/tree/master/pip
Using flatpak-pip-generator based on the different requirements.txt files (module by module) and manually filling the blank spots and removing duplicates. There is also a python module that depends on rust and that had to be made manually (copied from another manifest).
Just checking in for an update. The process of packaging the GUI is a mess and it'd be nice to have it containerized and isolated in a flatpak.
I mean no insults but there's no way to make the package meet the packaging quality requirements for several distributions, and it would be absurd to expect those distributions to change their quality requirements. This locks many users out of the ad blocking features of the service they pay for.
I've looked into packaging ProtonVPN Linux app in Flatpak. It mostly works, thanks to relying on NetworkManager, which is largely usable from within Flatpak sandbox.
However, there are some obstacles. Most notably it's relying on systemd for the "reconnector" service and using systemctl program to control it. There are two problems with it:
- Creating a systemd unit file at run time is possible, but whether the app is running in flatpak should be taken into account: the
Execline would be different for flatpak and non-flatpak builds - Controlling the service with
systemctlis also possible, but this means bundling the whole Systemd inside the flatpak app bundle; also I'm not sure if it's ok to use onesystemctlversion to control another systemd version on the host (probably not)
An alternative and sandbox-friendly approach would be using a dbus-activatable service for the reconnector, instead of a systemd service.
Also, ideally, the usage of nmcli utility should be replaced with pure NetworkManager DBus API, for the same reason as with systemctl: compatibility between different versions of nmcli and the NM daemon is unknown.
Not only would that be more
An alternative and sandbox-friendly approach would be using a dbus-activatable service for the reconnector, instead of a systemd service.
Not only would this be more sandbox friendly it would make packaging for non-systemd distributions much easier.
So, today's blog post last section ("What’s next for Proton VPN") made me bring this topic up again. I didn't knew about this GitHub repository, so I wrote to your support team first. So I guess I'll just repeat my today's request to support below:
Please create Flatpak version of the app and add it on Flathub. Right now I am unable to use ProtonVPN on my Fedora Silverblue machine because immutable Linux distribution like Fedora Silverblue, Fedora Kinoite, EndlessOS, carbonOS, openSUSE MicroOS, NixOS, etc. does not run anything but Flatpak and/or AppImage. Flatpak is also distribution independent so you won't have to maintain different Linux versions. I hope that you will consider adding this to your new platforms roadmap mentioned in today's blog post.
@Danik1601 Don't forget the Steam Deck! I know @calexandru2018 said there were no plans to publish on Flathub before but I also hope that sentiment has changed given the current state of things. If not, it would be great to at least know the reason.
I would like to be able to use ProtonVPN on the steam deck, so please consider supporting it.
