Arch Linux User Repository

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.

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

Just installed this on Manjaro but does not show up. Tried "/usr/bin/tutanota-desktop-linux" and got "No such file or directory ".

Any advice?

@arp12 unfortunately I tried the pre_upgrade() function already. The package breaks before pre_upgrade (or any of the .install scripts) are run, which is why unfortunately this is the route I took. I tried numerous different methods of trying to get it to work. There’s one additional thing that I just thought of that I may give a go right now.

Edit: that method didn't work. Due to the way the package was built before, to make this change is disruptive :(

@ajgraves wouldnt it be possible to revert/hold next upgrade, and make it in steps? one today, one next week to give people time to get this version?

Prepare script with pre_upgrade function that will remove it first then start install of the new version.

All, I'm pushing an update to version 3.57.3. The upgrade process is going to break, unfortunately. But it will only break this once. You'll need to run (as root) "rm /usr/bin/tutanota-desktop-linux" and then try the upgrade again. The PKGBUILD will output a message stating this as well, so hopefully this is clear. Unfortunately there doesn't appear to be a way that I can force this to be done from the PKGBUILD without it failing anyways. This change is being done to incorporate better things for this package in the future.

Also, it is no longer necessary as of this release to perform a "clean build" of the package. You should be able to update it as normal using whatever AUR helper you wish (or manually using makepkg)

@a098247, if you're using pamac, the build directory is defined in the file /etc/pamac.conf. By default, it's /var/tmp, so if you go to /var/tmp/pamac-build-<your user ID> you'll see a directory called tutanota-desktop-linux in there. Remove that directory (or run pamac clean -b).

Alternatively, I'm going to push an update that should force a new download as a .2 release, so hopefully that'll resolve your problem.