Package Details: electronmail-bin 4.8.0-1

Git Clone URL: https://aur.archlinux.org/electronmail-bin.git (read-only, click to copy)
Package Base: electronmail-bin
Description: Unofficial ProtonMail Desktop App
Upstream URL: https://github.com/vladimiry/ElectronMail
Keywords: electron electron-mail electronmail email email-securely-app encryption mail privacy protonmail tutanota
Licenses: MIT
Conflicts: electronmail
Provides: electronmail
Submitter: joshirio
Maintainer: joshirio
Last Packager: joshirio
Votes: 16
Popularity: 1.10
First Submitted: 2019-03-13 16:13
Last Updated: 2020-08-01 06:39

Required by (0)

Sources (2)

Pinned Comments

joshirio commented on 2019-03-13 16:17

On KDE plasma if you have issues with the tray icon, make sure to change the .desktop launch command to:

XDG_CURRENT_DESKTOP=Unity "/opt/ElectronMail/electron-mail" %U

Latest Comments

1 2 Next › Last »

galvez_65 commented on 2020-10-16 20:53

Just discovered this after protonmail-desktop stopped working for some reason. First thank you for putting this in the AUR, however, looking over your PKGBUILD and install files I do have some concerns. Please take this simply as ways to improve and simplify your package and in no way meant as criticism.

First, you are using the install file to create a softlink in bin. This should be done within the PKGBUILD file so that pacman can keep track of it. Doing it the way you are doing is not good practice.

Second, you should not be fixing the sandbox permissions within the install file, you should copy them with the --no-preserve=ownership option. Also with arch unless this is a special build of electron, you should probably just add electron as a dependency and only copy the resource folder. you will have to edit the desktop file to reflect that.

Third, no need to update the mime and desktop databases like you have to do with deb, pacman will take care of that.

Last, are you sure gconf is a dependency, it is being sunset in favor of dconf. I removed it as a dependency and did not have an issue installing, although I did modify your PKGBUILD file to reflect my suggestions.

joshirio commented on 2020-01-26 19:06

gnome-keyring became an optional dependency alongside org.freedesktop.secrets. Now users are free to choose the password storage backend.

joshirio commented on 2019-12-24 09:40

I'm reverting the libsecret change since it causes issues, see https://github.com/vladimiry/ElectronMail/issues/57

joshirio commented on 2019-12-23 14:04

@stevendoesstuffs OK, I'll give it a try, please report any issues, if any.

stevendoesstuffs commented on 2019-12-23 06:35

@joshirio please replace the gnome-keyring dependency with libsecret. I've tested it and it does work.

stevendoesstuffs commented on 2019-05-16 05:54

@joshirio just tested without gnome keyring (using the new keepassxc integration with libsecret, not kwallet) and it works! The only change is to replace the gnome-keyring dependency with libsecret.

joshirio commented on 2019-04-30 19:50

setuid error has been fixed, https://github.com/vladimiry/ElectronMail/issues/135

joshirio commented on 2019-04-30 16:21

@ajgraves yes, please report it upstream since it's the same upstream pacman package

ajgraves commented on 2019-04-30 16:18

Latest update introduces some problems. I get this error when running:

[17738:0430/094522.380764:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /opt/ElectronMail/chrome-sandbox is owned by root and has mode 4755. zsh: trace trap (core dumped) electron-mail

I got it to run by setting mode 4755 (setuid root) on chrome-sandbox, but the package should probably be fixed to either do that on install/update, or if there's a better way of resolving this. I'll post this to the upstream as well; I recall seeing something in the release notes about upgrading Electron versions so could be related?

joshirio commented on 2019-04-28 17:11

@stevendoesstuffs I belive those are upstream deps, see https://github.com/vladimiry/ElectronMail/issues/104 and https://github.com/vladimiry/ElectronMail/issues/57#issuecomment-432201465

I'm not sure it would work, can you eventually do some tests? As I don't have a system without gnome-keyring at hand. Does the "keep me signed-in" feature (master password) work without gnome-keyring (by using libsecret)? And then there's the issue with KDE where kwallet/ksecretservice has not a libsecret API (never implemented AFAIK), so that the KDE user must install gnome-keyring anyway...