Originally created by @Technetium1 on GitHub (Nov 12, 2022). **Describe the bug you encountered:** - Rustdesk fails to compile **How did you install `RustDesk`?** - https://aur.archlinux.org/packages/rustdesk --- **Version and environment** - Rustdesk 1.1.9 - Arch Linux - Clean chroot **Log:** [rustdesk.log](https://builds.garudalinux.org/repos/chaotic-aur/logs/rustdesk.log)

deekerman

2026-02-20 23:15:28 -05:00

closed this issue
added the
bug
label

deekerman commented

2026-02-20 23:15:32 -05:00

Author

Owner

@rustdesk commented on GitHub (Nov 12, 2022):

#763

@rustdesk commented on GitHub (Nov 12, 2022): #763

deekerman commented

2026-02-20 23:15:32 -05:00

Author

Owner

@Rojikku commented on GitHub (Nov 13, 2022):

@rustdesk That's the maintainer for chaotic AUR, and my co-maintainer for the AUR.
I'm the maintainer for the AUR.
https://aur.archlinux.org/packages/rustdesk

I asked him to submit a bug report, because your code has a bug.

If a team of five maintainers can't figure out the issue, it's because the issue is your code.

Oh look! A merged PR that fixes this exact issue.

#1900 There. There's the issue.

It won't compile because you never release bugfixes. You write them. You just don't release them.
Release bugfixes and you won't get complaints. The same code doesn't keep compiling for six months, or at least, your code definitely doesn't.

Also, this package isn't the -git version that builds off your major repo. It's not the -bin version that uses your compiled binary. It's the version that takes a stable, tagged version of your package, and users run my PKGBUILD, and it compiles an arch package for the users. Those are the restraints I'm working with, I can't switch teams. I'm also not manually patching your code because you can't release versions.
Normally, these faults are covered up by the chaotic AUR, which shows people what they've compiled, and lets people get a prebuilt version. However, they had to rebuild everything after a database rebuild (as I understand), and despite using the exact same PKGBUILD instructions as before, your package doesn't build anymore.

The advantage to my package existing, is users (usually) can't mess it up, it builds in a clean environment off of specific instructions. Unless the maintainer's instructions are shit, or the code is shit, it should build every time. If you think my PKGBUILD is crap, you're more than welcome to become the maintainer of the package, just say the word and I'll disown it for you. Otherwise, please re-consider your official release schedule, and take advantage of the bugfix section of semantic versioning.
Which you are also not doing correctly.
Do you require a separate issue for that?

@Rojikku commented on GitHub (Nov 13, 2022): @rustdesk That's the maintainer for chaotic AUR, and my co-maintainer for the AUR. I'm the maintainer for the AUR. https://aur.archlinux.org/packages/rustdesk I asked him to submit a bug report, because your code _has a bug_. If a team of five maintainers can't figure out the issue, it's because the issue is your code. Oh look! A merged PR that fixes this exact issue. #1900 There. There's the issue. It won't compile because you never release bugfixes. You write them. You just don't release them. Release bugfixes and you won't get complaints. The same code doesn't keep compiling for six months, or at least, your code definitely doesn't. Also, this package isn't the -git version that builds off your major repo. It's not the -bin version that uses your compiled binary. It's the version that takes a stable, tagged version of your package, and users run my PKGBUILD, and it compiles an arch package for the users. Those are the restraints I'm working with, I can't switch teams. I'm also not manually patching your code because you can't release versions. Normally, these faults are covered up by the chaotic AUR, which shows people what they've compiled, and lets people get a prebuilt version. However, they had to rebuild everything after a database rebuild (as I understand), and despite using the exact same PKGBUILD instructions as before, your package doesn't build anymore. The advantage to my package existing, is users (usually) can't mess it up, it builds in a clean environment off of specific instructions. Unless the maintainer's instructions are shit, or the code is shit, it should build every time. If you think my PKGBUILD is crap, you're _more than welcome_ to become the maintainer of the package, just say the word and I'll disown it for you. Otherwise, please re-consider your official release schedule, and take advantage of the bugfix section of [semantic versioning](https://semver.org/). _Which you are also not doing correctly._ Do you require a separate issue for that?

deekerman commented

2026-02-20 23:15:32 -05:00

Author

Owner

@rustdesk commented on GitHub (Nov 13, 2022):

Sorry, i understand your anger, i saw too many compilation related issues, so i treated yours as the others.

But honestly, we are not ready to support official aur, could you remove it if you do not wanna maintain it?

@rustdesk commented on GitHub (Nov 13, 2022): Sorry, i understand your anger, i saw too many compilation related issues, so i treated yours as the others. But honestly, we are not ready to support official aur, could you remove it if you do not wanna maintain it?

deekerman commented

2026-02-20 23:15:32 -05:00

Author

Owner

@Rojikku commented on GitHub (Nov 13, 2022):

Removing it isn't an option I have in the UI.
The only options I have are leaving it abandoned, or maintaining it.
Currently, there's nothing I can do to fix the package unless you release a bugfix, so my job just consists of ignoring the constant complaints about said lack of a bugfix.

Supporting the AUR isn't difficult. I just need actual bugfixes released regularly. For 80% of updates, all I have to do is bump the version number in the PKGBUILD and it builds the next version fine, unless you add/change dependencies (Which is presumably in patchnotes).

The code is already being written and committed to your repository, can you adjust your workflow slightly so that you release tags with the bugfixes?

@Rojikku commented on GitHub (Nov 13, 2022): Removing it isn't an option I have in the UI. The only options I have are leaving it abandoned, or maintaining it. Currently, there's nothing I can do to fix the package unless you release a bugfix, so my job just consists of ignoring the constant complaints about said lack of a bugfix. Supporting the AUR isn't difficult. I just need actual bugfixes released regularly. For 80% of updates, all I have to do is bump the version number in the PKGBUILD and it builds the next version fine, unless you add/change dependencies (Which is presumably in patchnotes). The code is already being written and committed to your repository, can you adjust your workflow slightly so that you release tags with the bugfixes?

deekerman commented

2026-02-20 23:15:32 -05:00

Author

Owner

@Rojikku commented on GitHub (Feb 24, 2023):

@rustdesk Still not completed because you still haven't tagged a release with the fix.

@Rojikku commented on GitHub (Feb 24, 2023): @rustdesk Still not completed because you still haven't tagged a release with the fix.

deekerman commented

2026-02-20 23:15:32 -05:00

Author

Owner

@daiaji commented on GitHub (Jun 26, 2023):

This is embarrassing.

@daiaji commented on GitHub (Jun 26, 2023): This is embarrassing.

deekerman commented

2026-02-20 23:15:32 -05:00

Author

Owner

@Technetium1 commented on GitHub (Jul 3, 2023):

Wow, there's a release! https://github.com/rustdesk/rustdesk/releases/tag/1.2.0
I disowned the AUR package long ago, so this is complete as far as I'm concerned.

@Technetium1 commented on GitHub (Jul 3, 2023): Wow, there's a release! https://github.com/rustdesk/rustdesk/releases/tag/1.2.0 I disowned the AUR package long ago, so this is complete as far as I'm concerned.