Arch Linux User Repository

Hmm I expected the migration to be smoother for users and not require manual actions. I'm getting this today which means user experience is broken and trust lost because of simple package rename:

:: Searching AUR for updates... -> Missing AUR Packages: tutanota-desktop-linux there is nothing to do

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

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.

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

@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

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.

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?

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.

@ajgraves thanks for packaging and maintaining this :)

@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.