Arch Linux User Repository

When using kwallet as provider for org.freedesktop.secrets and pass for key backend for the bridge, I've needed to add a delay before starting the systemd unit after login.

systemctl --user edit --full bridge.service

...
[Service]
...
ExecStartPre=/bin/sleep 30
...

Else the starting of the bridge might fail because kwallet isn't unlocked instantly after login and the GPG key for the pass repo thus is locked (Editing the systemd unit file will skip the need for manual input of the passphrase for the GPG key)

hakayova and grimfrenzy: I managed to solve the issue of "no account found" by providing the correct PASSWORD_STORE_DIR to the systemd service.

In my case I provided: Environment="PASSWORD_STORE_DIR=/home/mclancy/.local/share/pass"

Hope this helps!

Minimal fork of https://aur.archlinux.org/packages/protonmail-bridge/

Compiled with 'nogui' option

Included is a user systemd service. Try: systemctl status --user bridge.service

1. You can login and register accounts using the interactive cli: protonmail-bridge --cli
2. Once you have everything configured and automated. You can enable and use bridge.service to run bridge in background.

The following is an alternative way to run the bridge in interactive cli mode encapsulated within a named screen session. Can be added to bridge.service

ExecStart=/usr/bin/screen -Dm -S bridgedaemon sh -c "sleep 5; protonmail-bridge -c"
ExecStop=/usr/bin/screen -X -S bridgedaemon quit

@hakayova: Have you tried adding the environment variable to your profile/env file? For example I have "export PASSWORD_STORE_DIR=/pathto/password-store" in "$HOME/.zshenv".

Thank you mclancy for your suggestion. I tried adding the Environment statement under Service section of bridge.service pointing to the root of password store (/home/hakayova/.password-store in my case) but unfortunately it didn't change the behavior. I still need to restart the service to be able to start using the bridge after a reboot. $ systemctl --user restart bridge.service

Thanks for posting a solution. I guess, I couldn't recreate the problem since I have that environment variable set in my *env/profile file.

I have pinned your comment for future readers. ;)

hakayova and grimfrenzy: I managed to solve the issue of "no account found" by providing the correct PASSWORD_STORE_DIR to the systemd service.

In my case I provided: Environment="PASSWORD_STORE_DIR=/home/mclancy/.local/share/pass"

Hope this helps!

@kausban, a manual reinstall with -Rs and -Syu fixed it.

Probably some bad cache either from makepkg or yay. I know it wasn't a one-off because that happened in 3 different arch systems that I manage.

Probably a yay issue, the latest change to pkgver induced some kind of buggy non-standard behavior.

sommerfeld: Thanks for reporting your issue. I had only tried the build using makepkg. I just tried yay -Syu and I am unable to replicate your experience or the bug.

Can you try doing a clean build again?

I changed pkgver, so that this package pulls the newest release on the proton-bridge github page. Previously it was building off the git master branch.

I don't understand why, but it seems like your recent change to how pkgver is done in 155147d2a09d commit broke version checking:

-pkgver=1.2.7
+
+_pkgver=1.2.7
+_rev="live.1"
+_srcver="$_pkgver"-"$_rev"
+_srcname=proton-bridge-"$_srcver"
+
+pkgver="$_pkgver"."$_rev"

When upgrading with yay -Syu, this package will be reinstalled every time I use that command.

The curious part is this one:

Package (1)              Old Version     New Version     Net Change

protonmail-bridge-nogui  1.2.7.live.1-3  1.2.7.live.1-3    0.00 MiB

It seems that the pkgver is being correctly generated but for some reason there seems to be a mismatch on a lower level. Is this a makepkg bug? A yay bug? Or is there something truly wrong with the latest PKGBUILD commit?

Anyway, can pkgver be reverted back to the previous non buggy format?

I use pass as well and i get the prompt for my gpg passphrase when I start the bridge.service as user.

I will try debug this over the weekend to see if I can recreate what you are seeing. Alternatively, consider using the alternative method to run in the bridge in its interactive mode within a screen session as mentioned in the pinned comment.

Little bit of an update to the previous comment.

I'm using pass as my password manager and a dialog will pop up requesting my password when an application tries to use it. This works as expected when I'm launching protonmail-bridge directly (with -c or --noninteractive flags) but never appears anywhere I can see when I use the user service.

So I can get the same behavior (no user found and no reported error) by not unlocking my pass store. I think the issue is providing pass access to the bridge service.

I'm having a similar issue to @hakayova. When using the bridge.service mbsync reports that my email address cannot be found. If I run 'protonmail-bridge -c' or 'protonmail-bridge --noninteractive' directly from the shell then mail is retrieved and sent as usual.

This seems to be consistent as far as I can tell. If I stop the bridge.service and launch the protonmail-bridge from the shell -- it works. If I kill protonmail-bridge and start the bridge.service again -- it doesn't.

My understanding of systemd falls short of suggesting what the difference would be between a service file launched application and one launched manually here. Any ideas on troubleshooting this?