Arch Linux User Repository

@cirlo I contacted their support when I had trouble running pCloud in Sway with GDK_BACKEND=wayland (without ",x11"). Their response was: "Unfortunately, we are having troubles updating the app to the latest electron versions because of inside security libraries that we are using. Our devs know about this issue and electron version update is already planed."

suspend solution here: https://bbs.archlinux.org/viewtopic.php?id=305971

and for popup for now I just created a kwin rule to keep it in the back

On a fresh install of Arch, after installing pCloud, every time I click on the pCloud tray icon in KDE Plasma, a window pops up that says:

remote control requested an application requested access to: input devices it's this bug here https://bugs.kde.org/show_bug.cgi?id=490666

more importantly pCloud is blocking suspend for me. it just freezes the whole machine have to sysrq reboot. When I killall pCloud before sleep there are no issues whatsoever. Any ideas how to fix?

@rew1red

@rew1red

Thanks again for the follow-up!

Edit: I just saw your patch from a few hours ago and it's basically exactly what I suggested regarding the autostart. The issue with the duplicate desktop entries as described below still remains, as you said, which is fine for me.

Regarding the DESKTOPINTEGRATION=false, I couldn't really find any information on it's usage at all. From what I can tell, it's a flag used by "AppImageKit", but even on their GitHub there's nothing documented about it. (More about that below.)

Regarding the issue of the autostart breaking upon updates: I was able to confirm, that pCloud literally just creates an autostart entry based on the binary's filename.

So to avoid breaking the autostart the solution seems to be to install the AppImage in /opt/pcloud/pcloud-drive.AppImage without version information in the filename, so that it can remain unchanged across updates.

What I've done in my tests: - deactivated all existing pcloud related desktop files by moving them to *.desktop.bak files (including the one in ~/.config/autostart/) - confirmed they disappeared from the GNOME launcher - moved /usr/bin/pcloud to /usr/bin/pcloud.bak (the one that was symlinked /opt/pcloud/pcloud-drive-1.14.12-1.AppImage) - moved the "full-name" binary in /opt/pcloud/pcloud-drive-1.14.12-1.AppImage to a *.bak file, to make sure it's not being used by anything accidentally - copied that file to a "short-name": /opt/pcloud/pcloud-drive.AppImage - created a new symlink in /usr/bin/pcloud -> /opt/pcloud/pcloud-drive.AppImage - activated the /usr/share/applications/pcloud.desktop file again (the one that this AUR package created, referencing /usr/bin/pcloud in Exec) - started pcloud through GNOME launcher - disabled autostart in preferences, applied, enabled autostart again, applied - ~/.config/autostart/pcloud-drive.AppImage.desktop got created by the application - restarted my system - the autostart did indeed lead to a new ~/.local/share/applications/appimagekit-pcloud.desktop file being created, which shoes up as an additional "pcloud" (lower-case 'c') in GNOME launcher because the ~/.config/autostart/pcloud-drive.AppImage.desktop file doesn't include the env DESKTOPINTEGRATION=false flag

So if I did everything correctly, that would be one possible solution to at least avoid the autostart from breaking.

As for the duplicate desktop entry: since the AppImageKit creates the file in ~/.local/share/applications/appimagekit-pcloud.desktop maybe the solution for this PKGBUILD is to simply put the desktop file there as well upon installation instead of in /usr/share/applications/pcloud.desktop. That should also make the sed patches to the desktop file pretty much obsolete and we could instead just replace AppRun with the Exec command that otherwise would also be generated by the AppImageKit, namely "/opt/pcloud/pcloud-drive.AppImage" %U (after my file name change of the binary). I'm not sure about best practices for AUR packages, so I would totally understand, if you'd rather not touch anything in the user's %HOME.

The duplicate desktop entry doesn't bother me much, the autostart issue is more important to me.

I hope my tests help you out a bit. Thanks for your time!

@PhiLinux --

I think you're very close in what you assume is happening. The critical thing is that the Desktop file this PKGBUILD installs is patched to include DESKTOPINTEGRATION=false in the environment when starting pCloud, to prevent the double-menu entry that results from both the system AND the AppImage trying to add their .desktop file to the menu.

I see that the .desktop file that is being added by the autostart setting doesn't include any of these patched changes, which likely results in the double menu entry the patched desktop file tried to avoid.

Unfortunately since pCloud is directly creating this file I'm not entirely sure what this package can do about it.

Open to thoughts and opinions of course, but for now I'll patch what I can.

@rew1red

Thanks for your reply! I just took another look at it and saw some things that made me a bit confused.

If I understand the PKGBUILD correctly...:

1.) ... the *.desktop file should already be installed using the _shortname, which doesn't include the version numbers.

2.) ... the Exec command should already reference the symlink that is created in /usr/bin/pcloud which points to the binary with the long name including version number in /opt/pcloud/

Aside from that I've also found my system (GNOME 48) detects 2 different pcloud desktop files (display names pcloud vs. pCloud). I think what might have happened is, that pcloud implemented a way to update the AppImage through the running application, bypassing the package manager. IIRC I was curious when I saw the option and tried it out last time. So this might be the culprit that broke the "infrastructure" that the PKGBUILD sets up and shifted things to whatever pcloud does "natively" now.

The desktop file in ~/.local/share/applications/appimagekit-pcloud.desktop apparently got generated by AppImageKit and even contains this line:

X-AppImage-Comment=Generated by /tmp/.mount_pcloud0cNg4j/AppRun

For some reason that file got (re-)created today after booting my machine, even though there wasn't any update at all.

That file also points to the actual binary, instead of the symlink at /usr/bin/pcloud:

Exec="/opt/pcloud/pcloud-drive-1.14.12-1.AppImage" %U

I'll keep an eye on it when the next update is available. Sorry if that caused even more confusion...

@PhiLinux --

Thank you for breaking all of that down. I noticed that I had a ~/.config/autostart/pCloud.desktop file present without any versioning. However, when I disabled and re-enabled the autostart feature in pCloud's settings, I did in fact see a ~/.config/autostart/pcloud-drive-1.14.12-1.AppImage.desktop file get created.

This would lead me to believe that they changed the behavior of how this autostart file is named somewhere down the line (my autostart file is dated 2022).

I'll implement a solution in the next version, but unfortunately we will probably have a state where some users have an existing, versioned autostart file that might need to be removed by hand. I'm not comfortable having the PKGBUILD interfere with a user's .config folder.

Thanks again for doing this legwork!

I prefer having pcloud autostart on boot, via the option in the application. For me the autostart broke upon updating to version 1.14.12.

I'm not exactly sure about the reason, but I'll try to keep track of it next time pcloud releases a new version.

The autostart mechanic that pcloud uses is to create a desktop file in ~/.config/autostart/ and I think it uses the AppImage's filename for that, as in my case the old file that still existed was named pcloud-drive-1.14.11-1.AppImage.desktop and it (naturally) referenced the old binary: Exec=/opt/pcloud/pcloud-drive-1.14.11-1.AppImage

So since this AUR package installs the AppImage with a filename that includes the version, this is probably breaking on every update.

I fixed it quite easily manually for now by removing the old desktop file and going to the pcloud options > disabled autostart > apply > enabled autostart again > apply. This created the new desktop file in the autostart directory: pcloud-drive-1.14.12-1.AppImage.desktop which references the new AppImage Exec=/opt/pcloud/pcloud-drive-1.14.12-1.AppImage

So I think it would be nice if the PKGBUILD would either:

Option 1:

Put the AppImage into a generically named binary without the version in the filename, e.g. /opt/pcloud/pcloud-drive.AppImage. That way the desktop files in the autostart directory could remain unchanged across updates.

Option 2:

Another solution would be to have some kind of "post-installation hook" (sorry for potentially poor terminology, I don't know enough about PKGBUILD yet), that checks for the existence of an old pcloud desktop file in the ~/.config/autostart directory and creates a new one that references the new version.

I think option 1 would be a lot more trivial and "fail safe", but I'm not sure about potential downsides of not having the version in the binary's filename anymore.

I get the same error as @HaxNet

everytime i boot up (running i3wm), I get an error popping up saying "Unknown Error during the update process" something along that line, I just press okay and everything is working.