Package Details: tutanota-desktop-bin 251.241112.0-1

Git Clone URL: https://aur.archlinux.org/tutanota-desktop-bin.git (read-only, click to copy)
Package Base: tutanota-desktop-bin
Description: The desktop client for Tutanota, the secure e-mail service.
Upstream URL: https://tuta.com/secure-email
Licenses: GPL-3.0-or-later
Conflicts: tutanota-desktop, tutanota-desktop-linux
Provides: tutanota-desktop
Submitter: yochananmarqos
Maintainer: yochananmarqos (ajgraves)
Last Packager: yochananmarqos
Votes: 48
Popularity: 0.76
First Submitted: 2019-12-23 17:19 (UTC)
Last Updated: 2024-11-13 18:15 (UTC)

Latest Comments

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 Next › Last »

ajgraves commented on 2019-12-31 03:18 (UTC)

@yochananmarqos I can't believe I didn't check the file permissions... good grief!

yochananmarqos commented on 2019-12-23 17:24 (UTC)

I've gone ahead and created tutanota-desktop-bin and submitted the request to merge this package into it.

The reason why the AppRun was not executing was due to having the wrong permissions. It was 640 instead of 644.

ajgraves commented on 2019-12-23 17:24 (UTC)

@yochananmarqos would be glad to have the help. As you can tell, I've still got a lot to learn!

yochananmarqos commented on 2019-12-23 16:48 (UTC) (edited on 2019-12-23 17:27 (UTC) by yochananmarqos)

@arp12: I'd be happy to contribute.

@ajgraves:

I'll work on renaming the package as soon as I figure out the proper way to do so.

You would submit a new package called tutanota-desktop-bin, then submit a request to merge this one into it. See AUR Submission guidelines: Requests.

As for the depends, technically those aren't necessary anyways since all this is doing is running the AppImage.

That's true, I was making my own PKGBUILD attempting to run it unpacked when I was composing that.

As for not executing AppRun, I don't call that anywhere in any of the code used for the package. Not sure where you're seeing that commented out. Can you elaborate?

The commented out bits imply that's what would be happening. The only way to run it unpacked is with AppRun or using the system Electron to execute the app.asar, but neither work for some reason.

You can also add signature checking to the prepare() array, see How do I verify the signature of the desktop client?

    # Validate the signature against public key
    set -e
    openssl dgst -sha512 -verify tutao-pub.pem -signature linux-sig.bin "$pkgname-$pkgver.AppImage"
    set +e

agilob commented on 2019-12-23 12:26 (UTC) (edited on 2019-12-23 12:28 (UTC) by agilob)

The name is 'tutanota-desktop-linux' because it's the original name of the binary file Tutanota officially produces. I created this package because it didn't exist, but very quickly @ajgraves offered his support in managing it. He's the main contributor here.

If you @yochananmarqos would like to help fix the issues you highlighted, I would be happy to add you as a contributor.

I'm also happy to disown the package if someone with more time and experience would like to take it over for the greater good.

ajgraves commented on 2019-12-23 03:46 (UTC)

Hey @yochananmarqos, I'll try to address your points here.

Caveat: I took over maintainership of this package. Can't speak to how it was initially set up, I can only speak to the changes I've made since.

I'll work on renaming the package as soon as I figure out the proper way to do so. I've been playing around with building from source but haven't had much time to devote to doing so yet.

The desktop file was included in the package because several versions of the AppImage were not prompting to integrate with the system, so users were unable to launch from anything other than command line without it. Additionally, this solved the problem for first time users, having just installed the app, there still wasn't a menu item available. It appears Tutanota fixed this in a recent update so it at least prompts to integrate with the system, however there will still be no initial menu item unless the desktop file is included in the package. I've not had a chance yet to explore options on how to correct this condition if a user selects to integrate the AppImage with their system.

On symlinking the AppImage to /usr/bin, you are correct, and I missed that when I added a script to launch the application. I'll correct that.

As for the depends, technically those aren't necessary anyways since all this is doing is running the AppImage. They are there because I'm working on exploding the AppImage and running the extracted image. However, I've not been able to get that to work in a live system yet. It works if I do it under my individual user account, however not when installed as a package via pacman and then executed by an end user. It simply fails with no output at all. I have a few ideas but still working on testing them out. I'll correct what you've indicated, however.

As for not executing AppRun, I don't call that anywhere in any of the code used for the package. Not sure where you're seeing that commented out. Can you elaborate?

yochananmarqos commented on 2019-12-21 19:16 (UTC)

This should be submitted as tutanota-desktop-bin as it's a binary source. That way, someone can submit a package that builds from source. This should not include "linux" in the package name. Notice the desktop file and binary are named tutanota-desktop.

The desktop file is already included, no need to use a separate file. You can changed the Exec command via sed in the prepare() array (assuming you rename your binary to tutanota-desktop):

sed -i 's|Exec=AppRun|Exec=tutanota-desktop|g' squashfs-root/tutanota-desktop.desktop

You're symlinking the AppImage to /usr/bin/, then you're installing your included binary there that runs the AppImage with the same name overwriting it. That makes no sense, please remove the symlink.

This does not require gconf, it uses gsettings. These are the dependencies which are common for most Electron apps:

depends=('nss' 'libxss' 'libxtst' 'libappindicator-gtk3' 'libnotify')

This requires either zenity, kdialog or xdialog for dialogs. See /squashfs-root/AppRun.

optdepends=('zenity: for dialogs'
            'kdialog: for dialogs'
            'xdialog: for dialogs')

Any idea why this does not execute using AppRun? I see you have that bit commented out. It should, but there's no output at all when I tried it.

alleyoopster commented on 2019-10-31 13:42 (UTC) (edited on 2019-10-31 13:43 (UTC) by alleyoopster)

@ajgraves thanks for packaging and maintaining this :)

qq88 commented on 2019-08-28 06:39 (UTC)

@ajgraves, I installed it again and it worked now, thanks.

I guess the issue was me still having an appimage from the tuta website on the system.

ajgraves commented on 2019-08-27 17:52 (UTC) (edited on 2019-08-27 17:53 (UTC) by ajgraves)

@qq88, I'd first try to uninstall the package and re-install it. Did you get any error messages? Are you installing the latest version?

Edit: I'm also running on Manjaro, so I know it shouldn't have anything to do with that.