Arch Linux User Repository

@jstitch fakeroot is part of base-devel which is a prerequisite for building packages.

xdotool is already an explicit dependency of this package, so you shouldn't need to install it manually (as long as you pass the -s option to makepkg).

https://wiki.archlinux.org/title/Arch_User_Repository#Installing_and_upgrading_packages :)

I get several dependencies errors that got fixed by installing fakeroot and xdotool

are you also getting a 'Unsupported display server tty, x11 expected' error message? If yes, found any workaround? (xfce4, xfwm4)

@JoaoMachado install file doesn't look right with those restarts outside of functions. I solved this problem long ago. See my install file in rustdesk.

@JoaoMachado: Thanks, I'll retest the behavior. I was under the impression that the connection wasn't killed while doing the update and new connections were still possible even without restarting the service. If rustdesk break during/after the update, I'll force the restart.

About automatically starting the service during the install, this is a big no. It's against the simplicity principle of Arch Linux (and may be unwanted by the system administrator): https://wiki.archlinux.org/title/Arch_Linux#Simplicity

if the user opens Rustdesk in user space before enabling the systemd service, Rustdesk will generate a different ID number than when the systemd service is enabled.

This is a bug of RunDesk, but it's very minor IMO. Without the service running, no password is generated, so the ID is useless anyway. Once you start the service, the proper ID is generated and displayed.

You can report the bug upstream if you want. The easiest fix will probably to hide the ID if the service is not running.

PS: Your changes in your .install file are incorrect; you execute commands outside of the functions, this is unsupported by pacman.

Greetings, I use this build package to build my own signed package for my niche Distro. But I have found a flaw with it's operation out in the wild and I would like to share it with you.

If a user updates a machine remotely using Rustdesk, the machine then becomes unusable remotely because the RustDesk service was not restarted after the update process.

I would also recommend restarting the service after the initial install, if the user opens Rustdesk in user space before enabling the systemd service, Rustdesk will generate a different ID number than when the systemd service is enabled. This can cause much confusion.

I changed my .install file to this to fix this issue, I tested a remote update, and the session was restored and I could access the system remotely again, the operations functions just like the windows version.

# Colored makepkg-like functions
_all_off="$(tput sgr0)"
_bold="${_all_off}$(tput bold)"
_blue="${_bold}$(tput setaf 4)"
_yellow="${_bold}$(tput setaf 3)"
note() {
    printf "${_blue}==>${_yellow} NOTE:${_bold} %s${_all_off}\n" "$1"
}

post_install() {
    note "The RustDesk daemon must be started for RustDesk to work."
    note "To start it automatically on boot, run 'sudo systemctl enable --now rustdesk' in a terminal."
}

systemctl restart rustdesk

post_upgrade() {
    # Display instructions to enable the RustDesk service if it's not enabled
    systemctl -q is-enabled rustdesk.service || post_install
}

systemctl restart rustdesk

pre_remove() {
    if systemctl -q is-active rustdesk.service; then
        note "The RustDesk service may still be running after removing the package, allowing remote access to this system."
        note "To ensure that RustDesk isn't running anymore on your system, run 'sudo systemctl stop rustdesk' in a terminal."
    fi
}

Not sure if this has been discussed but I required package xdg-user-dirs to see my recent connections.

@Zoddo version 1.3.3-1 won't len me connect, when I get to the screen where the password should be typed, it either crashes or most of the time freezes. When I start it from CLI, nothing useful seems to be logged. I have reverted to 1.3.2-1 and all works fine.

Thanks a lot, @void09! I've included your suggested changes in the PKGBUILD :)

(No pkgrel bump because the commit only adds support for aarch64. The resulting package for x86_64 doesn't change so a rebuild for these users isn't required.)