Arch Linux User Repository

Switched to default to cuda disabled (no nvenc) because cuda is a heavy package and Nvidia users are minority on Linux.

Nvidia users, install cuda manually before building or run as _build_cuda=t makepkg (method to pass variables to AUR helpers may vary).

Comments here are for matters related to this AUR package only. Discussion of upstream issues should take place upstream. The upstream link is in package details.

For those concerned about "losing" upstream support for AUR, such support had already officially been discontinued long ago. The relevant comment from 2023-02-21 is pinned.

Before reporting issues to upstream, confirm them with git checkout or upstream binaries. Properly confirmed bugs do not need to mention AUR.

Package-specific issues should be reported here.

In order to simplify maintenance of Sunshine, we have decided to drop support of this AUR package, since we are now publishing a pre-compiled pkg.tar.zst package as well as the PKGBUILD file to our GitHub releases. If someone would like to take over the AUR it would be ideal if there is communication with us in our Discord. Please reach out if you're interested. Thanks!

@LizardByte Thanks for the links, the underlying problem though is that Arch packages basically need to be built daily unless you statically link a bunch of libs in. The current stable release was compiled against many bumped shared libs like libminiupnpc.so.17 is now libminiupnpc.so.18 etc etc. What is needed to put this to bed once and for all is a github action that runs a cron (schedule in actions terminology) nightly to build against the current stable release and push an updated sunshine.pkg.tar.zst to the release. This was basically the only reason I am currently ingesting from AUR, that and there are not any pkgbuild tars attached to the releases. So basically anyone trying to follow https://docs.lizardbyte.dev/projects/sunshine/en/master/about/setup.html would end up here as neither methods work.

@LizardByte this is a pretty interesting point of view. How much time did you invest into this whole drama in total? Hours? Could've easily fixed the package for everyone without instructing people to break their systems during that time! You seem to be ignoring this fact since the beginning. A fun fact about the news list article you linked in your orphan request:

changes suggested by muflone

This is actually an Arch TU. Did you read the comment below the mail? The maintainer indeed seems to have broken rules here :) Jumping to quick conclusions seems to be a thing, huh? It's also funny how the PKGBUILD fixes were instantly negatively commented on. Please provide proof about those statements, or be grateful about someone rectifying your shortcomings.

@TheLamer, thank you.

We are keeping ArchLinux support, but are not advising anyone to use this AUR package moving forward. We will also not provide any technical support for this AUR package while Chaotic-AUR maintainers are in control of it.

After doing further research I found that they have a history of being abusive to packagers on AUR, until they quit. Chaotic-AUR has no vested interest in Sunshine and certainly doesn't follow development of the project close enough to catch all the new build changes that we introduce from version to version. Due to that I have re-created my account, and am seeking to re-gain control here, via https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/ZJZZ7UJWR7LSZTJO33BQC7I2YPX7JES5/ I should have done this before hastily disowning this package, and for that I do apologize.

Anyway, outside of AUR, we now have 2 supported methods for installation outside of AUR. https://docs.lizardbyte.dev/projects/sunshine/en/master/about/setup.html

I am also looking into hosting our own pacman repo via GitHub, where no one can come in and threaten us. I apologize for any inconvenience.

Isn't the point of having an AUR package so that users can safely install it into their Arch systems without messing around with build/runtime dependencies? That's about as fundamental as it gets.

With respect to the upstream maintainer for their hard work, if they're unable or unwilling to provide that for whatever reason, then why not accept the help of a person willing to take over that responsibility for Arch? Yes, I'm aware of the Jia Tan parallels here. Fortunately, it's easier to inspect a PKGBUILD than an entire package. As AUR users, that's OUR responsibility.

Just want to chime in with a quick message for maintainers, the silent majority that either ingests this for personal use or a downstream package appreciate your effort and understand that volunteer work takes time. I hope a few anime avatars don't ruin the whole thing. Keep up the good work and looking forward to future releases.

@lounges the "workaround" was something you'd absolutely not want on Arch systems. Every other software relying on that particular package would potentially be subject to break in the same matter this application did. Being "bullied out" is a harsh way of "multiple people raised valid points that the author couldn't justify".

@escape0707 I can appreciate your points. I understand that it is open sourced and can be reviewed. My point is simply that the maintainer of this package (who happened to be the author of the software) was harassed out of this packages ownership while still being here, responsive, and providing workarounds. This is not how we continue to have nice things. Frustrations of a broken package aside, do not lose sight of the fact that someone worked to create this for free.

I was not here during the recent discussion, but someone else linked the upstream PR, so I ended up here. I just want to clarify some statements from some fellow AUR users. No judgement towards current maintainers or previous ones.

@lounges

pulled of a "Jia Tan" takeover of the package from the original author. Nobody should use this package, who knows what they did to it.

The AUR's repo is open sourced, and it's literally the reason why AUR makes it so easy for you to click "View PKGBUILD / View Changes" and check the content of the PKGBUILD to verify whether it's legit or not. Building and installing an AUR package without yourself understanding it is not supported by Arch, either. You should take the responsibility to review and use AUR packages yourself. Your statement is just an invalid assault to current maintainers.

But, if you do discovered malicious changes during your review, you can definitely file a request against it.

@BrianAllred

saying "it's a one line fix", taking over the PKGBUILD, and now the entire PKGBUILD is different is a little weird Might be prudent to explain the changes.

It would always be great to have documents everywhere, for sure. But users of AUR packages are expected to have some degrees of the ability to read the PKGBUILD and related files (bash scripts, basically).

It's not weird at all for the current maintainers to rewrite an old PKGBUILD with some modern practice in mind, especially upon taking over. I've read the file and if I understand correctly the main changes are basically just listing submodules in sources and adding scripts to manage updates of them. I think current maintainers' effort / result is of high quality. The "one line fix" is probably line 151's cherry-pick. If current maintainers decide to keep the previous way of writing the PKGBUILD file, this could be the "one line fix" that they were talking about.

Of course, you guys should and are welcomed to review the AUR repo's changes every time if you are still using it. And I think a proper technical question about the content of, say, PKGBUILD can surely be asked here, and you will often get explained carefully.

I'm not necessarily defending the original maintainer, but saying "it's a one line fix", taking over the PKGBUILD, and now the entire PKGBUILD is different is a little weird.

Might be prudent to explain the changes.