In the past I saw some effort by Proton to have the official proton python client packaged in Fedora repositories, but then the effort was dropped because it is expected that a new proton python library will be released, deprecating the old one.
The fact is that it is not known when this new library will be released and made available to public (they claim it is internally developed from over an year now).
I therefore decided to package the necessary bits for having protonVPN working on my system. Indeed there is a Proton repository which should provide both proton-gui and proton-cli with all the bits needed, but I’ve found that the default installation isn’t working (it misses at least a dependency, so the vpn connection can’t be established.
I have created a COPR repo and I wonder if it is worth to submit those packages to the official repository.
We currently have protonvpn-cli in Fedora repositories which is based to an old, unmaintained community fork (cc @jflory7 which is the primary maintainer).
To have protonvpn-gui approved in Fedora repositories there’s still some work to do: packaging guidelines requires appstream metadata to be added.
So, is there any interest by someone to co-maintain those packages if I submit them for approval? At least, until upstream release the new client/cli/app to the world.
Hi @mattia, I am happy to support you in packaging the existing bits for ProtonVPN into Fedora. We could coordinate this to officially sunset the deprecated community client[1] that exists in my package today.
It is worth noting that there is a Proton SIG packaging group (here is our mailing list). This package group was meant to be a catch-all for anyone wanting to help package the Proton bits for Fedora. I was working with Alexandru Cheltuitor from the ProtonVPN team for a time on launching that, but I got busy and he is focused on the pending Python library rewrite that you mentioned above.
I don’t have a ton of time to package new things, but I could probably help as a reviewer and to include any Proton packages as under the Proton SIG packager group. I could also try and make connections to the Proton team so their developers are aware of this work and could participate if they wished.
What I am packaging now was the official client for a good amount of time, but things changed fast and I wasn’t able to keep up my package with the new client. I also attempted to package the ProtonMail Bridge too. ↩︎
Hello Justin, as a fellow Proton* user it’s nice to know about the existence of a Proton-SIG… it gives me hope in future to have their software working out of the box in Fedora.
The current status of packages in my COPR repo is that they’re (should be) mostly ready for official submission to Fedora. The only things to fix are:
protonvpn (the GUI package) needs an appstream file - which should not be too hard
both protonvpn and protonvpn-cli errors out when you try to generate logs - I can look at and would be nice fixing this downstream, if upstream doesn’t have interest in it.
I’ll announce in the proton-sig mailing list my willing to submit those packages to official repository and, if Proton guys don’t raise objections or say that the new clients will be available in the next few months, I’ll proceed with package reviews.
Hi @jflory7 and @mattia, it would be really nice to have these proton clients available in the Fedora repos. I think I currently have them installed from the proton repo in a f37 toolbox because they weren’t available for f38 yet.
I would be up for helping out to maintain these packages - new to fedora packaging but comfortable enough with python.
I really hope they bring out some kind of linux client for protondrive - automated backups to proton drive would be great!
I am optimistic too. I believe that upstream is committed to co-owning the downstream packaging work for Fedora. I understand the hesitation about ugly upgrade paths that could be avoided by waiting.
Per the discussion in the Bugzilla ticket, I think the right course of action for now is to use the COPR as the intermediary for making the packages more widely available to Fedora users.
Although I do hope that we could see proper Fedora packages land by the time F40 releases in April/May 2024. This would mean the Proton packages would be available on Day 1 for downstream version 10 of EPEL, CentOS Stream, RHEL, and several other of the EL clones/rebuilds.
I know we figured this out in Bugzilla, but I should add you to this list anyways. It is a closed list because it can receive security vulnerability disclosures, but right now, there is not regular list traffic anyways. Might as well bring folks interested in Proton software closer together.
Great. I could also add you to the Proton-SIG mailing list. I will use the emails that you and @mattia have in your FAS accounts unless you prefer a different email for the list.
I keep thinking that showing up in GNOME Online Accounts (and similar features in other desktops) would be a huge win. It would be amazing if I could add my Proton email, calendar, contacts, and drive and have my login integrate with the desktop environment.
It is almost the exact same as what you can already do with a Google account in most cases anyways.
I’ve requested subscription a couple of days ago, so it should be there waiting approval. But, yes, it’s the same email provided in FAS.
This is something I’d like Proton to work out, too: a unified login.
I’ve raised an idea in Proton uservoice about having a unique login for all proton apps in Android instead of having to login every single app. But the same would apply to desktop - gnome AND kde (I’m a KDE user )
Yeah, currently I’ve just the protondrive app installed on my smartphone, but I never used it. Without any kind of automatic sync I think it’s useless.
I think it’s time for Proton to stop pushing out new apps/services and just focus on getting those already available into an usable shape, otherwise this kind of strategy will soon show it’s drawbacks.
I was doing some reading across the Proton github and reddit - It looks like the new linux desktop client is pretty close[1] so that may be a better target for F40?
)