Skip to content

[BUG] Rustdesk on arm64 #1415

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
StrangeRanger opened this issue Apr 22, 2025 · 4 comments · May be fixed by #1416 or #1417
Open

[BUG] Rustdesk on arm64 #1415

StrangeRanger opened this issue Apr 22, 2025 · 4 comments · May be fixed by #1416 or #1417

Comments

@StrangeRanger
Copy link

StrangeRanger commented Apr 22, 2025

On the latest version of deb-get (0.4.5), I'm informed that rustdesk is not supported on arm64, but it is.

Image

Image


EDIT

After further investigation, it looks like the problem comes from this line. For some reason, when I run dpkg --print-architecture on my Raspberry Pi (running Ubuntu 24.04), it outputs arm64, which isn't specified in the ARCHS_SUPPORTED variable.

@silentJET85 silentJET85 linked a pull request Apr 22, 2025 that will close this issue
@silentJET85
Copy link
Contributor

Yeah, the package's ARCHS_SUPPORTED line is supposed to use the HOST_ARCH values ( amd64, armhf, arm64) rather than the HOST_CPU ones (x86_64, armv7, aarch64).
It was also grepping for the HOST_ARCH value when their filenames contain the other.

@StrangeRanger
Copy link
Author

@silentJET85 Didn't notice your PR before I already made mine. The only problem I see with yours is that it doesn't fix the problem with the armv7 architecture. RustDesk's always releases armv7 as armv7-sciter.deb, which the current grep command doesn't account for.

@silentJET85
Copy link
Contributor

URL="$(sort "${CACHE_FILE}" | grep -m 1 "browser_download_url.*${HOST_CPU}.*\.deb\"" | cut -d '"' -f 4)"

I think the .* after ${HOST_CPU} should take care of it. Instead of searching for exactly "armv7.deb", I'm essentially searching for "armv7( ANYTHING ).deb"
Hopefully, this will be more resilient against potential future filename changes.

@StrangeRanger
Copy link
Author

Oh, must have not seen that part. Yea, I think that should handle it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants