Add RustDesk Client (software ID 13) to dietpi-software

[Copilot]

• Add RustDesk Client (ID 13) install/uninstall block in dietpi/dietpi-software
• Add software metadata (category, deps, docs link, arch restrictions)
• Add dietpi-survey_report entry for ID 13
• Add update_urls.bash entry for ID 13
• Add dietpi-software.bash CI test entry for ID 13
• Fix indentation of 'rustdesk' entry in dietpi/dietpi-services (spaces → tabs, per @MichaIng review)

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Joulinar]

@StephanStS FYI, I changed branch to dev

[Joulinar]

we really need to train Copilot to not forget dietpi-software.bash, update_urls.bash, dietpi-survey_report, dietpi-services, CHANGELOG.txt and README.md when implementing new software options 🤣

[StephanStS]

Test conducted:

• I tested the installation on a nearly bare DietPi installation (I just executed dietpi-software install 13).
  This automatically installs an X11 desktop and queries for a desktop type (LXQt, XFCE,...) as the dependency for the RustDesk Client.
• I also tested the uninstall and afterwards found no RustDesk remains (e.g. find /usr -name *rustdesk*)

[StephanStS]

we really need to train Copilot to not forget dietpi-software.bash, update_urls.bash, dietpi-survey_report, dietpi-services, CHANGELOG.txt and README.md when implementing new software options 🤣

• I have added changes in CHANGELOG.txt, README.md and dietpi-services

We also should note this in our DietPi Wiki instruction page "How to add a new software title".

[StephanStS]

@copilot : Please add the new RustDesk Client installation to https://raw.githubusercontent.com/MichaIng/DietPi/refs/heads/master/.meta/dietpi-survey_report

[Copilot]

@copilot : Please add the new RustDesk Client installation to https://raw.githubusercontent.com/MichaIng/DietPi/refs/heads/master/.meta/dietpi-survey_report

Added RustDesk Client (ID 13) to .meta/dietpi-survey_report in the aSOFTWARE_NAME10_2 block (v10.2), and also added a corresponding entry to .github/workflows/update_urls.bash for automatic URL tracking. Commit: 4996de8

[StephanStS]

@MichaIng :

Q1: What about this input from ChatGPT (we looked at this last week):

    API_URL="https://api.github.com/repos/rustdesk/rustdesk/releases/latest"
    fallback_url="https://github.com/rustdesk/rustdesk/releases/latest/download/rustdesk-${ARCH_PATTERN}"

    Download_Install="$(curl -s "${API_URL}" \
        | mawk -F'"' "/browser_download_url/ && /${ARCH_PATTERN}/{print \$4; exit}")"

    [[ -z "${Download_Install}" ]] && Download_Install="${fallback_url}"

    if ! G_CHECK_URL "${Download_Install}"; then
        G_DIETPI-NOTIFY 1 "No RustDesk build available for ${ARCH}"
        return 1
    fi

This then would be an option which can be added to other installations within dietpi-software.

Q2: Can you review all changes in detail?
Especially, the changes in dietpi-survey_report, update_urls.bash etc. I am not able to check it.

[StephanStS]

@copilot : Please check https://raw.githubusercontent.com/MichaIng/DietPi/refs/heads/dev/.github/workflows/dietpi-software.bash for needed changes.

[Copilot]

@copilot : Please check https://raw.githubusercontent.com/MichaIng/DietPi/refs/heads/dev/.github/workflows/dietpi-software.bash for needed changes.

Added 13) aCOMMANDS[i]='rustdesk --version';; to the Process_Software switch case in .github/workflows/dietpi-software.bash (right after the ID 12 RustDesk Server entry). No QEMU workaround is needed since RustDesk Client doesn't create a systemd service. The desktop dependency is resolved automatically by the main dietpi-software install script. Commit: 2cff5a2

[Joulinar]

When selecting Rust Desk Client, should we perhaps check whether a desktop is already installed? And if not, should we explicitly inform the user that this is essential? This is to avoid any misunderstanding and prevent users from believing that it would also work on the CLI only. Just a thought. 🤔

[Joulinar]

@copilot are you able to update TCP and UPD ports used by Rust Desk Client on our Wiki? https://github.com/MichaIng/DietPi/wiki/DietPi-TCP-UDP-port-usage-list

[Copilot]

@copilot are you able to update TCP and UPD ports used by Rust Desk Client on our Wiki? https://github.com/MichaIng/DietPi/wiki/DietPi-TCP-UDP-port-usage-list

Unfortunately I'm unable to edit the GitHub wiki — it's a separate repository and I don't have push access to it. Someone with repo write access will need to add the RustDesk Client entry there.

For reference, RustDesk Client connects outbound to the server ports (TCP 21115–21119, UDP 21116), but does not listen on fixed local ports of its own; P2P and relay connections use ephemeral/dynamic ports.

[MichaIng]

Test installs: https://github.com/MichaIng/DietPi/actions/runs/22543514720
Those should include the Python workaround.

[MichaIng]

Oh, grep fails if it does not match anything. So a simple symlink is not enough, it needs to mock a version string.

[StephanStS]

The last commit did not fix the problem of dietpi-software install 13 on a fresh DietPi system.

Setting up rustdesk (1.4.5) ...
dpkg: error processing package rustdesk (--configure):
 installed rustdesk package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.41-12+deb13u1) ...
Errors were encountered while processing:
 rustdesk

[MichaIng]

Now it works: https://github.com/MichaIng/DietPi/actions/runs/22543514720
Okay, it did not here, wait 😄.

EDIT: Ohh, execute permissions 🙄. But not only that. As fast as I add a which python3 to the script, to check whether it sees the new executable, it succeeds ... No idea why it does not see it in the first place.

Crazy, even that there are several seconds and a bunch of installed packages between the /usr/local/bin/python3 creation and the postinst, it fails to execute it on first attempt. Rust a retry solves it. Running python3 in any other bash directly after creating (and giving execute permissions to) that script, works immediately.

[StephanStS]

Now it works: https://github.com/MichaIng/DietPi/actions/runs/22543514720 Okay, it did not here, wait 😄.

EDIT: Ohh, execute permissions 🙄. But not only that. As fast as I add a which python3 to the script, to check whether it sees the new executable, it succeeds ... No idea why it does not see it in the first place.

Also at my VM missing x flags:

ls -l /usr/local/bin/python3
-rw-r--r-- 1 root root 30  1. Mär 14:33 /usr/local/bin/python3

Before I can do another install test, I have to execute apt remove rustdesk, otherwise the next install test will always fail.

[MichaIng]

Execute bit is there now, but it does still not work on first attempt. A retry works, an dpkg --configure -a works. Weird.

Also if you do now remove the rustdesk package, and reinstall it, it will work. It only fails on the very first attempt, before the system somehow somewhere remembers that there is an executable now ... This makes local tests basically impossible without resetting the whole VM to an earlier snapshot. But on GitHub it can be tested: https://github.com/MichaIng/DietPi/actions/runs/22543514720/attempts/5

There is another issue: The packages depend on libgtk-3-0 instead of libgtk-3-0t64 etc, which means they cannot be installed on Trixie on ARMv7. For Bookworm only, no point to add it now. Hence, when using their packages, we need to remove ARMv7 support.

[StephanStS]

Execute bit is there now, but it does still not work on first attempt. A retry works, an dpkg --configure -a works. Weird.

Also if you do now remove the rustdesk package, and reinstall it, it will work. It only fails on the very first attempt, before the system somehow somewhere remembers that there is an executable now ... This makes local tests basically impossible without resetting the whole VM to an earlier snapshot. But on GitHub it can be tested: https://github.com/MichaIng/DietPi/actions/runs/22543514720/attempts/5

I can acknowledge this on my system. But: If the installation executes correct, it is unusable because no desktop is present.
I did this:

1. Bare DietPi system
2. dietpi-software install 13
3. dpkg --configure -a
4. (Installation went good)
5. startx (to be able to run rustdesk)

It ends up with an X11 installation without desktop, so I assume this is useless for me:

[MichaIng]

Try this:

startx /usr/bin/rustdesk

or as root

xinit /usr/bin/rustdesk

[StephanStS]

Try this:

startx /usr/bin/rustdesk

or as root

xinit /usr/bin/rustdesk

That starts it, but RustDesk gives a message:

Additionally, I cannot enter any credentials via keyboard.
If I then install e.g. lxde, nothing is improved. I had to activate lightdm to be able to use RustDesk Client as wanted.

Can we say that this (minimal) installation is useful if users install their own desktop manager? Would therefore the Dependency DEPS=desktop also detect a different desktop like e.g. Cinnamon, Budgie, Trinity?
As far as I understand, this minimal installation (i.e. without a desktop) is problematic for 99 % of our users, therefore I vote for DEPS='desktop'.

[MichaIng]

Did you start it via xinit or startx? The second adds a bunch of variables and setup steps common for real X11 sessions. xinit is called by startx after everything else, but is minimal, not suited if clients that expect certain session variables and stuff.

And no, the desktop dependency does not detect custom desktop environments. Another good reason to keep X11 as dependency only.

[StephanStS]

Did you start it via xinit or startx? The second adds a bunch of variables and setup steps common for real X11 sessions. xinit is called by startx after everything else, but is minimal, not suited if clients that expect certain session variables and stuff.

Both, startx and xinit lead to a running RustDesk Client programm, which is not usable due to missing keyboard entry possibilities. As a result you cannot set/enter any credentials of client machines.

The installation now runs without an error. Also the error message shown above Nicht unterstützter Anzeigegeserver tty, X11 erwartet is not present any more.
(we could investigate it live on my VM)

But generally, we could finalize the actual PR now. In the documentation and optionally at the end of the RustDesk Client installation we should point out that an X11 desktop is needed (x.g. XFCE, LXQt) to be able to use the program.

[MichaIng]

Finally the installation goes through reliably without python3. Even if starting it from console outside of a true desktop session turns out to be difficult: Users who install a remote desktop client will usually install a desktop environment anyway. Otherwise one needs to know how to execute X11 applications from plain Linux console.

One thing I could find out already, is that it expects a DBus session. So this makes the "unsupported display" error disappear:

dbus-run-session startx /usr/bin/rustdesk

I still cannot input a password, but I can authorize the connection from the system that is connected to. The password field is grayed out as if this was expected. Does this behave differently when starting it from within a desktop session?

[StephanStS]

One thing I could find out already, is that it expects a DBus session. So this makes the "unsupported display" error disappear:

I can acknowledge this:

• Installation runs smoothly
• Acknowledge option by the other client works

But: The message regarding "... tty, X11..." now appears with this behaviour:

• The message appears in RustDesk Client if I execute dbus-run-session startx /usr/bin/rustdesk in the console where X11 then appears.
• The message does not appear in RustDesk Client if I execute dbus-run-session startx /usr/bin/rustdesk in a different ssh terminal, then X11 appears on the console without the error message.

[StephanStS]

I still cannot input a password, but I can authorize the connection from the system that is connected to. The password field is grayed out as if this was expected. Does this behave differently when starting it from within a desktop session?

This greyed field is normal:

On other systems I can enter credentials in the greyed field.
On the RustDesk Client minimal installation system I cannot enter any values (therefore I needed to install a desktop). So anything prevents to forward keypresses to the "minimal installation RustDesk Client instance".

[MichaIng]

Yeah, not sure what prevents this. Input works for entering the remote ID, just not for the password. But the remote system can accept the request, so no password is needed.

I had issues testing whether keypresses work in the actual remote desktop session, since the screen resolution on the VM is much smaller than on the remote host, and it cannot be easily changed with startx without really creating session scripts. Whenever the mouse enters the VM screen with the remote session open, it jumps back to the host, impossible to do test any keypresses in between 😄.

So while it is possible to install a desktop manually or create own session scripts for all the common setup, this is at least nothing we can or should document anywhere. The RustDesk client requires a desktop environment to start from properly, and the minimal dependency is only to support custom desktops, or for users who want to tinker.

Question is if we need to assume that users select that one only, without also selecting a desktop environment for install. I cannot imagine that someone is thinking: "Ay I want to do remote desktop maintenance with this DietPi system, helping my mom if she has problems with her computer again." without having any desktop environment on that DietPi system. If users really run into these false expectations, we can reconsider.