Support flatpak #537

kees-closed commented 2023年07月21日 08:20:46 +02:00 (Migrated from github.com)

According to PEP508, you need to specify version numbers in the ./docs/requirements.txt file. I need this information to create a Flatpak with req2flatpak or flatpak-pip-generator. Building VPN apps seems doable within Flatpak.

Edit: it may be a bug in req2flatpak, since this requirements.txt seems to work fine with a Flatpak build. They probably don't use that tool but something else. I'll check the docs and issues with req2flatpak a bit better.

According to [PEP508](https://peps.python.org/pep-0508/), you need to specify version numbers in the `./docs/requirements.txt` file. I need this information to create a Flatpak with [req2flatpak](https://pypi.org/project/req2flatpak/) or [flatpak-pip-generator](https://docs.flatpak.org/en/latest/python.html). Building [VPN apps](https://github.com/flathub/com.protonvpn.www/blob/master/com.protonvpn.www.yml) seems doable within Flatpak. Edit: it may be a bug in req2flatpak, since [this requirements.txt](https://github.com/ProtonMail/proton-python-client/blob/master/requirements.txt) seems to work fine with a Flatpak build. They probably don't use that tool but something else. I'll check the docs and issues with req2flatpak a bit better.

jwijenbergh commented 2023年08月07日 11:44:16 +02:00 (Migrated from github.com)

It is indeed good practice to do this, but it's weird that this does not seem to work. I think a flatpak is really useful as it will allow us to move to gtk4 sooner. I will make a pr soon that has sensible defaults for this file.

Building VPN apps seems doable within Flatpak.

I have seen this before, still looks like quite a big hassle to me. A contribution would be highly appreciated though so thanks for looking at this!

It is indeed good practice to do this, but it's weird that this does not seem to work. I think a flatpak is really useful as it will allow us to move to gtk4 sooner. I will make a pr soon that has sensible defaults for this file. > Building [VPN apps](https://github.com/flathub/com.protonvpn.www/blob/master/com.protonvpn.www.yml) seems doable within Flatpak. I have seen this before, still looks like quite a big hassle to me. A contribution would be highly appreciated though so thanks for looking at this!

kees-closed commented 2023年08月08日 23:19:19 +02:00 (Migrated from github.com)

It's very easy, it's just a different way of doing things: https://github.com/kees-closed/flathub/tree/org.eduvpn.www

I'm abroad now without my laptop. I'll have a look at it later this month. This already creates a workable Flatpak. But I have to review the permissions better and create a manifest.

Then I have to check how to create an automated build, test and deploy pipeline. Feel free to help out!

It's very easy, it's just a different way of doing things: https://github.com/kees-closed/flathub/tree/org.eduvpn.www I'm abroad now without my laptop. I'll have a look at it later this month. This already creates a workable Flatpak. But I have to review the permissions better and create a manifest. Then I have to check how to create an automated build, test and deploy pipeline. Feel free to help out!

jwijenbergh commented 2023年08月18日 15:27:51 +02:00 (Migrated from github.com)

It's very easy

The only downside I can see with this approach now as that we're still relying on pip. Ideally I would want to have everything reproducible in the package. So also e.g. build eduvpn-common in there, but I guess that's something for later. The reason for this is that building pip packages is a nightmare, especially if you have compiled dependencies (like the go eduvpn-common dependency), as you might see it works but it requires some stupid building steps (like using https://github.com/pypa/manylinux)

I had a quick test and first needed to install the flatpak for gnome sdk & gnome platform. Are those also required when someone installs it off flathub later? Or are we missing some requires in the spec file?

After that the client installed fine but running it with flatpak run org.eduvpn.www (I tried a debian 11 vm) made it fail here: github.com/eduvpn/python-eduvpn-client@53525b0ae0/eduvpn/utils.py (L67)

Did you observe this as well and if not am I doing something wrong? Thanks for your time on this

> It's very easy The only downside I can see with this approach now as that we're still relying on pip. Ideally I would want to have everything reproducible in the package. So also e.g. build eduvpn-common in there, but I guess that's something for later. The reason for this is that building pip packages is a nightmare, especially if you have compiled dependencies (like the go eduvpn-common dependency), as you might see it works but it requires some stupid building steps (like using https://github.com/pypa/manylinux) I had a quick test and first needed to install the flatpak for gnome sdk & gnome platform. Are those also required when someone installs it off flathub later? Or are we missing some requires in the spec file? After that the client installed fine but running it with `flatpak run org.eduvpn.www` (I tried a debian 11 vm) made it fail here: https://github.com/eduvpn/python-eduvpn-client/blob/53525b0ae0f49901f3bd432b465f0820c58dc7db/eduvpn/utils.py#L67 Did you observe this as well and if not am I doing something wrong? Thanks for your time on this

kees-closed commented 2023年08月23日 08:51:52 +02:00 (Migrated from github.com)

Hi @jwijenbergh, sorry for the delayed response. I was on holiday. Yes, this is an expected error that threw me off in the beginning as well. Other Flatpaks also don't start from the command line like this. But they do appear just fine in the GNOME apps listing and launch without issues. I've been using the Flatpak version of EduVPN now this week and it seems to work fine. I don't have the RPM installed anymore.

Things that still need to be done is:

1. https://flatpak-docs.readthedocs.io/en/latest/repositories.html#flatpakref-files
2. https://github.com/flathub/flathub/wiki/App-Submission
3. Of which I made a minimal start here https://github.com/kees-closed/flathub/tree/org.eduvpn.www

Then it's also possible to create automatic build and test pipelines. At least that's what I heard from the Signal Flatpak developer I talked to about a year ago. But if you have more time for this, then please jump in and help out. I can't fully prioritize and commit to this. But I aim to finish it by the end of this year. But then I'll probably stick to a pip install since that makes it easier for me. But if you can make a full build work in Flatpak then the Linux maintenance has become much easier.

Hi @jwijenbergh, sorry for the delayed response. I was on holiday. Yes, this is an expected error that threw me off in the beginning as well. Other Flatpaks also don't start from the command line like this. But they do appear just fine in the GNOME apps listing and launch without issues. I've been using the Flatpak version of EduVPN now this week and it seems to work fine. I don't have the RPM installed anymore. Things that still need to be done is: 1. https://flatpak-docs.readthedocs.io/en/latest/repositories.html#flatpakref-files 2. https://github.com/flathub/flathub/wiki/App-Submission 3. Of which I made a minimal start here https://github.com/kees-closed/flathub/tree/org.eduvpn.www Then it's also possible to create automatic build and test pipelines. At least that's what I heard from the Signal Flatpak developer I talked to about a year ago. But if you have more time for this, then please jump in and help out. I can't fully prioritize and commit to this. But I aim to finish it by the end of this year. But then I'll probably stick to a pip install since that makes it easier for me. But if you can make a full build work in Flatpak then the Linux maintenance has become much easier.

jwijenbergh commented 2023年08月23日 15:51:38 +02:00 (Migrated from github.com)

Hi @jwijenbergh, sorry for the delayed response.

Tbh it was pretty quick, my response wasn't exactly quick either :)

I was on holiday

Hope you had a good holiday!

Yes, this is an expected error that threw me off in the beginning as well. Other Flatpaks also don't start from the command line like this. But they do appear just fine in the GNOME apps listing and launch without issues. I've been using the Flatpak version of EduVPN now this week and it seems to work fine. I don't have the RPM installed anymore.

Interesting, for me it doesn't even seem to generate a desktop file in the usual location. What is the contents of your desktop file? Maybe I am missing some commands. Anyways I patched the client's sources to use the flatpak prefix:

diff --git a/eduvpn/utils.py b/eduvpn/utils.py
index 3c63bd2..c3b7025 100644
--- a/eduvpn/utils.py
+++ b/eduvpn/utils.py
@@ -59,7 +59,7 @@ def get_prefix() -> str:
 """
 target = "share/eduvpn/builder/mainwindow.ui"
 local = path.dirname(path.dirname(path.abspath(__file__)))
- options = [local, path.expanduser("~/.local"), "/usr/local", prefix]
+ options = [local, path.expanduser("~/.local"), "/usr/local", prefix, "/app"]
 for option in options:
 logger.debug(f"looking for '{target}' in '{option}'")
 if path.isfile(path.join(option, target)):

Then I build this new client using python3 bdist_wheel, replaced the flatpak specification to use this path to the wheel instead of the pythonhosted URL. And I am still getting various errors that it cannot find networkmanager. I had to patch the whole flatpak specification to the following (note mostly copied from ProtonVPN):

diff --git a/eduvpn_client-4.1.1-py2.py3-none-any.whl b/eduvpn_client-4.1.1-py2.py3-none-any.whl
index d34dd13..88ca1aa 100644
Binary files a/eduvpn_client-4.1.1-py2.py3-none-any.whl and b/eduvpn_client-4.1.1-py2.py3-none-any.whl differ
diff --git a/org.eduvpn.www.yaml b/org.eduvpn.www.yaml
index c0e9c1c..858fdfe 100644
--- a/org.eduvpn.www.yaml
+++ b/org.eduvpn.www.yaml
@@ -9,6 +9,7 @@ finish-args:
 - --share=network
 - --socket=wayland
 - --socket=fallback-x11
+ - --socket=session-bus
 # To store credentials
 - --talk-name=org.freedesktop.secrets
 - --talk-name=org.gtk.vfs.*
@@ -30,8 +31,113 @@ modules:
 --prefix=${FLATPAK_DEST} "eduvpn-client" --no-build-isolation
 sources:
 - type: file
- url: https://files.pythonhosted.org/packages/20/ba/2353b67996f18af557c6c8f2d9fb04db4dc2d1c487129fa1567317366c51/eduvpn_client-4.1.1-py2.py3-none-any.whl
- sha256: e89f0d5ad19488a7923b4b2e5d7936371b6a72dc825fb8fbdba684ab46f0257b
+ # patched eduvpn client for now to include /app prefix
+ path: eduvpn_client-4.1.1-py2.py3-none-any.whl
 - type: file
 url: https://files.pythonhosted.org/packages/52/13/aba67ef397a97b6f671f5361bc14a5fbd68492cdec83f56ce2ad34737154/eduvpn_common-1.1.0-py3-none-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_28_x86_64.whl
 sha256: fa4d14d1602e4bfc89de0369ff423ca3fa7980eb628efa20d6ee1e0a45a4fa1c
+
+ - name: libndp
+ buildsystem: autotools
+ cleanup:
+ - /bin
+ - /include
+ - /lib/pkgconfig
+ - /share/man
+ sources:
+ - type: archive
+ url: https://github.com/jpirko/libndp/archive/v1.8.tar.gz
+ sha256: c3ea76e253def89869651686a827da75b56896fe94fabd87d8c14b1d4588fd05
+ x-checker-data:
+ type: anitya
+ project-id: 14944
+ stable-only: true
+ url-template: https://github.com/jpirko/libndp/archive/v$version.tar.gz
+
+ # https://github.com/flathub/org.gnome.NetworkDisplays/blob/5a3369d04e32ccd092e42463de5171f473a8601d/org.gnome.NetworkDisplays.json#LL177C11-L230C11
+ - name: NetworkManager
+ buildsystem: meson
+ build-options:
+ cflags: -ltinfo
+ cxxflags: -ltinfo
+ config-opts:
+ - -Dsystemdsystemunitdir=no
+ - -Ddbus_conf_dir=/app/etc/dbus-1/system.d
+ - -Diptables=/usr/bin/true
+ - -Ddnsmasq=/usr/bin/true
+ - -Dsession_tracking=no
+ - -Dselinux=false
+ - -Dsystemd_journal=false
+ - -Dlibaudit=no
+ - -Dwext=false
+ - -Dwifi=false
+ - -Dppp=false
+ - -Dmodem_manager=false
+ - -Dovs=false
+ - -Dnmcli=true
+ - -Dnmtui=false
+ # We need introspection
+ - -Dintrospection=true
+ - -Dvapi=false
+ - -Ddocs=false
+ - -Dtests=no
+ - -Dfirewalld_zone=false
+ - -Dlibpsl=false
+ - -Dqt=false
+ cleanup:
+ - /sbin
+ - /etc
+ - /include
+ - /lib/pkgconfig
+ - /libexec
+ - /var
+ - /share/bash-completion
+ - /share/doc
+ sources:
+ - type: git
+ url: https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
+ tag: 1.40.18
+ commit: 2db3748ec8162ce948ba52f71b42a258ff8d64ba
+ x-checker-data:
+ type: anitya
+ project-id: 21197
+ stable-only: true
+ tag-template: $version
+ versions:
+ # Breaking change in 1.42.x: `dns` will be replaced by `dns-data`, which is incompatible with older NetworkManager on the host system
+ <: 1.42.0
+
+ # https://github.com/flathub/com.github.jkotra.eovpn/blob/670f19e2aee1c9559fbe4eed904e35500843ae88/com.github.jkotra.eovpn.yml#L133C17-L151
+ - name: libnma
+ buildsystem: meson
+ config-opts:
+ - -Dmobile_broadband_provider_info=false
+ - -Dgtk_doc=false
+ - -Dintrospection=false
+ - -Dvapi=false
+ cleanup:
+ - '*'
+ sources:
+ - type: git
+ url: https://gitlab.gnome.org/GNOME/libnma.git
+ tag: 1.10.6
+ commit: 3e324b69d0d74c8693fb58b9ee66efe0bad6cb34
+ x-checker-data:
+ type: anitya
+ project-id: 230112
+ stable-only: true
+ tag-template: $version
+
+ - name: NetworkManager-openvpn
+ buildsystem: autotools
+ sources:
+ - type: git
+ url: https://github.com/NetworkManager/NetworkManager-openvpn.git
+ tag: 1.10.2
+ commit: ae9575dd07cc2d2d51ec8d0297823e07017cb6e6
+ x-checker-data:
+ type: anitya
+ project-id: 69977
+ stable-only: true
+ tag-template: $version
+

And now it runs in the terminal. WireGuard works but OpenVPN is still broken. Anyways I can try to figure this out, just wondering if I am doing something wrong here. Thanks for the effort so far

> Hi @jwijenbergh, sorry for the delayed response. Tbh it was pretty quick, my response wasn't exactly quick either :) > I was on holiday Hope you had a good holiday! > Yes, this is an expected error that threw me off in the beginning as well. Other Flatpaks also don't start from the command line like this. But they do appear just fine in the GNOME apps listing and launch without issues. I've been using the Flatpak version of EduVPN now this week and it seems to work fine. I don't have the RPM installed anymore. Interesting, for me it doesn't even seem to generate a desktop file in the usual location. What is the contents of your desktop file? Maybe I am missing some commands. Anyways I patched the client's sources to use the flatpak prefix: ```diff diff --git a/eduvpn/utils.py b/eduvpn/utils.py index 3c63bd2..c3b7025 100644 --- a/eduvpn/utils.py +++ b/eduvpn/utils.py @@ -59,7 +59,7 @@ def get_prefix() -> str: """ target = "share/eduvpn/builder/mainwindow.ui" local = path.dirname(path.dirname(path.abspath(__file__))) - options = [local, path.expanduser("~/.local"), "/usr/local", prefix] + options = [local, path.expanduser("~/.local"), "/usr/local", prefix, "/app"] for option in options: logger.debug(f"looking for '{target}' in '{option}'") if path.isfile(path.join(option, target)): ``` Then I build this new client using `python3 bdist_wheel`, replaced the flatpak specification to use this path to the wheel instead of the pythonhosted URL. And I am still getting various errors that it cannot find networkmanager. I had to patch the whole flatpak specification to the following (note mostly copied from ProtonVPN): ```diff diff --git a/eduvpn_client-4.1.1-py2.py3-none-any.whl b/eduvpn_client-4.1.1-py2.py3-none-any.whl index d34dd13..88ca1aa 100644 Binary files a/eduvpn_client-4.1.1-py2.py3-none-any.whl and b/eduvpn_client-4.1.1-py2.py3-none-any.whl differ diff --git a/org.eduvpn.www.yaml b/org.eduvpn.www.yaml index c0e9c1c..858fdfe 100644 --- a/org.eduvpn.www.yaml +++ b/org.eduvpn.www.yaml @@ -9,6 +9,7 @@ finish-args: - --share=network - --socket=wayland - --socket=fallback-x11 + - --socket=session-bus # To store credentials - --talk-name=org.freedesktop.secrets - --talk-name=org.gtk.vfs.* @@ -30,8 +31,113 @@ modules: --prefix=${FLATPAK_DEST} "eduvpn-client" --no-build-isolation sources: - type: file - url: https://files.pythonhosted.org/packages/20/ba/2353b67996f18af557c6c8f2d9fb04db4dc2d1c487129fa1567317366c51/eduvpn_client-4.1.1-py2.py3-none-any.whl - sha256: e89f0d5ad19488a7923b4b2e5d7936371b6a72dc825fb8fbdba684ab46f0257b + # patched eduvpn client for now to include /app prefix + path: eduvpn_client-4.1.1-py2.py3-none-any.whl - type: file url: https://files.pythonhosted.org/packages/52/13/aba67ef397a97b6f671f5361bc14a5fbd68492cdec83f56ce2ad34737154/eduvpn_common-1.1.0-py3-none-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_28_x86_64.whl sha256: fa4d14d1602e4bfc89de0369ff423ca3fa7980eb628efa20d6ee1e0a45a4fa1c + + - name: libndp + buildsystem: autotools + cleanup: + - /bin + - /include + - /lib/pkgconfig + - /share/man + sources: + - type: archive + url: https://github.com/jpirko/libndp/archive/v1.8.tar.gz + sha256: c3ea76e253def89869651686a827da75b56896fe94fabd87d8c14b1d4588fd05 + x-checker-data: + type: anitya + project-id: 14944 + stable-only: true + url-template: https://github.com/jpirko/libndp/archive/v$version.tar.gz + + # https://github.com/flathub/org.gnome.NetworkDisplays/blob/5a3369d04e32ccd092e42463de5171f473a8601d/org.gnome.NetworkDisplays.json#LL177C11-L230C11 + - name: NetworkManager + buildsystem: meson + build-options: + cflags: -ltinfo + cxxflags: -ltinfo + config-opts: + - -Dsystemdsystemunitdir=no + - -Ddbus_conf_dir=/app/etc/dbus-1/system.d + - -Diptables=/usr/bin/true + - -Ddnsmasq=/usr/bin/true + - -Dsession_tracking=no + - -Dselinux=false + - -Dsystemd_journal=false + - -Dlibaudit=no + - -Dwext=false + - -Dwifi=false + - -Dppp=false + - -Dmodem_manager=false + - -Dovs=false + - -Dnmcli=true + - -Dnmtui=false + # We need introspection + - -Dintrospection=true + - -Dvapi=false + - -Ddocs=false + - -Dtests=no + - -Dfirewalld_zone=false + - -Dlibpsl=false + - -Dqt=false + cleanup: + - /sbin + - /etc + - /include + - /lib/pkgconfig + - /libexec + - /var + - /share/bash-completion + - /share/doc + sources: + - type: git + url: https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git + tag: 1.40.18 + commit: 2db3748ec8162ce948ba52f71b42a258ff8d64ba + x-checker-data: + type: anitya + project-id: 21197 + stable-only: true + tag-template: $version + versions: + # Breaking change in 1.42.x: `dns` will be replaced by `dns-data`, which is incompatible with older NetworkManager on the host system + <: 1.42.0 + + # https://github.com/flathub/com.github.jkotra.eovpn/blob/670f19e2aee1c9559fbe4eed904e35500843ae88/com.github.jkotra.eovpn.yml#L133C17-L151 + - name: libnma + buildsystem: meson + config-opts: + - -Dmobile_broadband_provider_info=false + - -Dgtk_doc=false + - -Dintrospection=false + - -Dvapi=false + cleanup: + - '*' + sources: + - type: git + url: https://gitlab.gnome.org/GNOME/libnma.git + tag: 1.10.6 + commit: 3e324b69d0d74c8693fb58b9ee66efe0bad6cb34 + x-checker-data: + type: anitya + project-id: 230112 + stable-only: true + tag-template: $version + + - name: NetworkManager-openvpn + buildsystem: autotools + sources: + - type: git + url: https://github.com/NetworkManager/NetworkManager-openvpn.git + tag: 1.10.2 + commit: ae9575dd07cc2d2d51ec8d0297823e07017cb6e6 + x-checker-data: + type: anitya + project-id: 69977 + stable-only: true + tag-template: $version + ``` And now it runs in the terminal. WireGuard works but OpenVPN is still broken. Anyways I can try to figure this out, just wondering if I am doing something wrong here. Thanks for the effort so far

kees-closed commented 2023年08月23日 17:42:32 +02:00 (Migrated from github.com)

Hi @jwijenbergh, I see that I made an oopsie. The RPM was for sure removed on my laptop, however, there was still a lingering pip install of EduVPN. I probably messed up something while troubleshooting and confused that install with the Flatpak. So I did not use the Flatpak after all.

In that case more dependencies are likely needed and extra fine tuning. The GNOME runtime includes a lot of common dependencies and is based on the Freedesktop one. But maybe these additions you mention in this diff are still needed. There are also some shared modules you can use (note that some of those like libsecret are already included in the GNOME runtime).

Sorry for making it sound easier than it is. Probably some more work is needed to make it work properly.

Maybe this example of another VPN tool can offer some more insight as well.

Hi @jwijenbergh, I see that I made an oopsie. The RPM was for sure removed on my laptop, however, there was still a lingering pip install of EduVPN. I probably messed up something while troubleshooting and confused that install with the Flatpak. So I did not use the Flatpak after all. In that case more dependencies are likely needed and extra fine tuning. The [GNOME runtime](https://docs.flatpak.org/en/latest/available-runtimes.html#gnome) includes a lot of common dependencies and is based on the [Freedesktop](https://docs.flatpak.org/en/latest/available-runtimes.html#freedesktop) one. But maybe these additions you mention in this diff are still needed. There are also some [shared modules](https://github.com/flathub/shared-modules) you can use (note that some of those like libsecret are already included in the GNOME runtime). Sorry for making it sound easier than it is. Probably some more work is needed to make it work properly. Maybe [this example of another VPN tool](https://github.com/flathub/com.protonvpn.www/blob/master/com.protonvpn.www.yml) can offer some more insight as well.

jwijenbergh commented 2023年08月23日 17:47:48 +02:00 (Migrated from github.com)

Hi @jwijenbergh, I see that I made an oopsie. The RPM was for sure removed on my laptop, however, there was still a lingering pip install of EduVPN. I probably messed up something while troubleshooting and confused that install with the Flatpak. So I did not use the Flatpak after all.

No worries, tracking every dependency on your machine can be tricky. Especially python dependencies are a nightmare.

In that case more dependencies are likely needed and extra fine tuning. The GNOME runtime includes a lot of common dependencies and is based on the Freedesktop one. But maybe these additions you mention in this diff are still needed. There are also some shared modules you can use (note that some of those like libsecret are already included in the GNOME runtime).

Thanks for the links I will look at these.

Sorry for making it sound easier than it is. Probably some more work is needed to make it work properly.

No worries! You gave me a good start. It's definitely doable, just not super trivial as flatpak still doesn't have that many VPN software packaged. Protonvpn is a good resource but it's still not that trivial. But I think it might be worth it

Maybe this example of another VPN tool can offer some more insight as well.

This is indeed where I got most dependencies from as protonvpn also uses networkmanager/dbus.

> Hi @jwijenbergh, I see that I made an oopsie. The RPM was for sure removed on my laptop, however, there was still a lingering pip install of EduVPN. I probably messed up something while troubleshooting and confused that install with the Flatpak. So I did not use the Flatpak after all. No worries, tracking every dependency on your machine can be tricky. Especially python dependencies are a nightmare. > In that case more dependencies are likely needed and extra fine tuning. The [GNOME runtime](https://docs.flatpak.org/en/latest/available-runtimes.html#gnome) includes a lot of common dependencies and is based on the [Freedesktop](https://docs.flatpak.org/en/latest/available-runtimes.html#freedesktop) one. But maybe these additions you mention in this diff are still needed. There are also some [shared modules](https://github.com/flathub/shared-modules) you can use (note that some of those like libsecret are already included in the GNOME runtime). Thanks for the links I will look at these. > Sorry for making it sound easier than it is. Probably some more work is needed to make it work properly. No worries! You gave me a good start. It's definitely doable, just not super trivial as flatpak still doesn't have that many VPN software packaged. Protonvpn is a good resource but it's still not that trivial. But I think it might be worth it > Maybe [this example of another VPN tool](https://github.com/flathub/com.protonvpn.www/blob/master/com.protonvpn.www.yml) can offer some more insight as well. This is indeed where I got most dependencies from as protonvpn also uses networkmanager/dbus.

jwijenbergh commented 2023年08月30日 17:37:05 +02:00 (Migrated from github.com)

Not sure if I want to add flatpak support as it's another component I would have to maintain, supporting the fedora and deb packages + pip is already enough on my plate. But I can see a benefit in flatpaks for sure. So if someone wants to pick this up then I am 100% willing to document it and help in making the building of it easier with e.g. patches

Not sure if I want to add flatpak support as it's another component I would have to maintain, supporting the fedora and deb packages + pip is already enough on my plate. But I can see a benefit in flatpaks for sure. So if someone wants to pick this up then I am 100% willing to document it and help in making the building of it easier with e.g. patches

kees-closed commented 2023年08月31日 09:09:03 +02:00 (Migrated from github.com)

In theory the Flatpak would be able to replace all of them for all Linux systems. Linux desktops are also moving towards the immutable model, where the OS itself is read-only and apps are installed via Flatpak. So it would also make it future proof.

In theory the Flatpak would be able to replace all of them for all Linux systems. Linux desktops are also moving towards the immutable model, where the OS itself is read-only and apps are installed via Flatpak. So it would also make it future proof.

jwijenbergh commented 2023年08月31日 09:36:56 +02:00 (Migrated from github.com)

In theory the Flatpak would be able to replace all of them for all Linux systems. Linux desktops are also moving towards the immutable model, where the OS itself is read-only and apps are installed via Flatpak. So it would also make it future proof.

I do not want to remove the current packages as that would mean leaving the current users in the dark.

Linux desktops are also moving towards the immutable model, where the OS itself is read-only and apps are installed via Flatpak

If that is the case then debian/ubuntu/fedora would not recommend making deb/rpm packages

> In theory the Flatpak would be able to replace all of them for all Linux systems. Linux desktops are also moving towards the immutable model, where the OS itself is read-only and apps are installed via Flatpak. So it would also make it future proof. I do not want to remove the current packages as that would mean leaving the current users in the dark. > Linux desktops are also moving towards the immutable model, where the OS itself is read-only and apps are installed via Flatpak If that is the case then debian/ubuntu/fedora would not recommend making deb/rpm packages

martijnkruiten commented 2023年09月04日 11:18:55 +02:00 (Migrated from github.com)

If that is the case then debian/ubuntu/fedora would not recommend making deb/rpm packages

Currently, the immutable versions of the operating systems, like Fedora Silverblue and OpenSUSE MicroOS, are separate from the main ones, but there's definitely a movement in that direction. As a Silverblue user, I would definitely use the flatpak instead of the rpm (even if it's an unofficial release), but I agree that you can't just stop maintaining the deb/rpm packages, as that would leave a lot of user installations without updates.

> If that is the case then debian/ubuntu/fedora would not recommend making deb/rpm packages Currently, the immutable versions of the operating systems, like Fedora Silverblue and OpenSUSE MicroOS, are separate from the main ones, but there's definitely a movement in that direction. As a Silverblue user, I would definitely use the flatpak instead of the rpm (even if it's an unofficial release), but I agree that you can't just stop maintaining the deb/rpm packages, as that would leave a lot of user installations without updates.

jwijenbergh commented 2023年09月04日 12:10:04 +02:00 (Migrated from github.com)

I would definitely use the flatpak instead of the rpm (even if it's an unofficial release)

I see the point if you're using a distribution that focuses on flatpaks. I think as of right now our support is pretty good. We support the most popular distros + others with pip packages. Arch has updates pretty regularly as well through an unofficial package. There's so many distros it's not really possible to support everything unfortunately. Silverblue and microOS you mentioned are cool projects but are nowhere near the top used distros.

The problem with flatpaks is that the sandbox is essentially useless for VPN software. Also adding additional components such as WireGuard over TCP (with e.g. a proxy) would then also need changes inside the flatpak. If someone wants to support a flatpak I'm all for it but I don't have enough time to maintain everything unfortunately :).

The flatpak with the diff I posted should give you a good start as it already works for WireGuard, OpenVPN probably needs access to the certificate path.

I agree that you can't just stop maintaining the deb/rpm packages, as that would leave a lot of user installations without updates.

Yes indeed, if I could drop support for these packages I would do it, but it's still the easiest way on these distros to obtain software. It's still officially supported and it won't go anywhere soon. Official support in the debian/fedora repos would of course be the best but that takes a lot of time

> I would definitely use the flatpak instead of the rpm (even if it's an unofficial release) I see the point if you're using a distribution that focuses on flatpaks. I think as of right now our support is pretty good. We support the most popular distros + others with pip packages. Arch has updates pretty regularly as well through an unofficial package. There's so many distros it's not really possible to support everything unfortunately. Silverblue and microOS you mentioned are cool projects but are nowhere near the top used distros. The problem with flatpaks is that the sandbox is essentially *useless* for VPN software. Also adding additional components such as WireGuard over TCP (with e.g. a proxy) would then also need changes inside the flatpak. If someone wants to support a flatpak I'm all for it but I don't have enough time to maintain everything unfortunately :). The flatpak with the diff I posted should give you a good start as it already works for WireGuard, OpenVPN probably needs access to the certificate path. > I agree that you can't just stop maintaining the deb/rpm packages, as that would leave a lot of user installations without updates. Yes indeed, if I could drop support for these packages I would do it, but it's still the easiest way on these distros to obtain software. It's still officially supported and it won't go anywhere soon. Official support in the debian/fedora repos would of course be the best but that takes a lot of time

jwijenbergh commented 2023年10月20日 14:51:16 +02:00 (Migrated from github.com)

If someone would like to pick this up, please re-open

If someone would like to pick this up, please re-open