Package Details: rustdesk-bin 1.3.1-3

Git Clone URL: https://aur.archlinux.org/rustdesk-bin.git (read-only, click to copy)
Package Base: rustdesk-bin
Description: Yet another remote desktop software, written in Rust. Works out of the box, no configuration required.
Upstream URL: https://github.com/rustdesk/rustdesk
Keywords: desktop remote rustdesk
Licenses: AGPL-3.0
Conflicts: rustdesk
Provides: rustdesk
Submitter: taotieren
Maintainer: kuhtoxo (Zoddo)
Last Packager: Zoddo
Votes: 85
Popularity: 6.19
First Submitted: 2021-06-27 05:16 (UTC)
Last Updated: 2024-09-23 15:44 (UTC)

Latest Comments

1 2 3 4 5 6 7 Next › Last »

Zoddo commented on 2024-09-23 15:49 (UTC)

Thanks @anasgets111 for your help in email to debug this issue. Fix is released in 1.3.1-3 :)

kuhtoxo commented on 2024-09-23 15:34 (UTC)

@Zoddo, thank you for your corrections and updates. I appreciate the work you've done.

Zoddo commented on 2024-09-23 12:58 (UTC) (edited on 2024-09-23 15:55 (UTC) by Zoddo)

Edit: Please disregard this comment. After some more information from anasgets111 in email, I misunderstood the issue. On Gnome, if you pin the app to the dash, window will not be attached to the pinned icon, but a new (duplicate) one will appear.

---

@anasgets111: Yeah, sorry this is a side effect of the fix for the file conflicts reported by joanmanel (I had to rename the .desktop file). The only other solution would be to ask everyone to uninstall the package and reinstall the latest version (or to delete conflicting files manually), which is less than ideal.

You will need to unpin and repin the RustDesk to fix this issue.

anasgets111 commented on 2024-09-23 12:47 (UTC) (edited on 2024-09-23 12:47 (UTC) by anasgets111)

1.3.1-2 the app will show a new icon when opened while pinned to the dash, I believe the .desktop needs to be setup correctly ?

Zoddo commented on 2024-09-23 11:48 (UTC)

@joanmanel: Can you retry with 1.3.1-2? I've pushed an update that should fix these conflicts.

joanmanel commented on 2024-09-23 08:11 (UTC) (edited on 2024-09-23 08:11 (UTC) by joanmanel)

Dear all, I am getting the following error:

error: failed to commit transaction (conflicting files)

rustdesk-bin: /usr/share/applications/rustdesk-link.desktop exists in filesystem

rustdesk-bin: /usr/share/applications/rustdesk.desktop exists in filesystem

Errors occurred, no packages were upgraded.

-> error installing: [/home/juanma/.cache/yay/rustdesk-bin/rustdesk-bin-1.3.1-1-x86_64.pkg.tar.zst] - exit status 1

Zoddo commented on 2024-09-22 19:30 (UTC)

Thanks for the update @kuhtoxo. A bit of cleaning will be needing with the pre-upgrade hook to cleanup files that were copied manually (like /etc/systemd/system/rustdesk.service).

Yes, you can add me as a co-maintainer if you want :)

PS : Can you send me an e-mail (it's available on my aur profile), so I can have yours to discuss without spamming this comment section? :)

kuhtoxo commented on 2024-09-22 19:22 (UTC)

Thank @Zoddo for your suggestions and comments.

I tried to apply them when updating the package.

Do you want/can become a co-maintainer of this package?

Zoddo commented on 2024-09-22 11:51 (UTC) (edited on 2024-09-22 11:58 (UTC) by Zoddo)

Thanks kuhtoxo for taking the maintenance of the package! :)
I just want to make a few remarks, as the recent update made this package divert from arch packaging guidelines and best practices:

  • Files get copied in place using the .INSTALL script instead of doing that during the packaging (PKGBUILD's package() function). This prevents pacman from properly tracking files installed by the package, thus breaking things like file conflicts handling, or querying which package owns a file (eg., pacman -Qo /usr/share/applications/rustdesk.desktop returns that no packages own this file). You should always install files in the definitive location during package() unless you have a solid reason not to.

  • According to the wiki (and more generally to man 7 file-hierarchy), units provided by packages should be installed in /usr/lib/systemd/system/. This allows the administrator to override (or mask) the unit file using /etc/systemd/system/ if needed.

  • You should not stop a service pre-upgrade, especially for a remote control tool (what if I run the upgrade while I'm connected remotely to the computer?). Doing that is the responsibility of the administrator, automating it goes against the principle of simplicity of Arch. More generally speaking, you shouldn't interact with systemctl in packages; starting/stopping/enabling/disabling services is outside the scope of the package maintainer.
    ​
    If you deem it's absolutely necessary to restart the service (eg. because the application breaks when its files are updated while running), you can use a pacman hook that will restart the service using /usr/share/libalpm/scripts/systemd-hook reload rustdesk.service (that script makes sure we aren't in a chroot before invoking systemctl; it will do a restart when the unit doesn't support reload).
    ​

  • Not an issue itself (it's more like to keep things clean), but you only need to conflict against rustdesk. Other packages you added to the list already provides rustdesk, so they will correctly conflict with your package without explicitly listing them :)

dantob commented on 2024-09-11 08:58 (UTC)

Look like it might be resolved with 1.3.0, I get just a warning now rustdesk[114703]: Cannot load libcuda.so.1. But the service does start.

1 2 3 4 5 6 7 Next › Last »