Package Details: sunshine 2025.122.141614-8

Git Clone URL: https://aur.archlinux.org/sunshine.git (read-only, click to copy)
Package Base: sunshine
Description: A self-hosted GameStream host for Moonlight
Upstream URL: https://github.com/LizardByte/Sunshine
Keywords: gaming moonlight streaming
Licenses: GPL-3.0-only
Submitter: hadogenes
Maintainer: dr460nf1r3 (xiota)
Last Packager: xiota
Votes: 59
Popularity: 2.21
First Submitted: 2021-04-26 11:33 (UTC)
Last Updated: 2025-06-15 19:55 (UTC)

Dependencies (29)

Required by (0)

Sources (15)

Pinned Comments

xiota commented on 2025-02-19 18:03 (UTC) (edited on 2025-05-02 04:06 (UTC) by xiota)

Rebuilding AUR packages for library updates and mismatches is inevitable. This package uses sodeps to reduce breaks caused by library updates. When ready to rebuild, use a clean chroot or force upgrades with pacman -Syudd.

xiota commented on 2024-07-17 01:54 (UTC) (edited on 2025-02-19 18:06 (UTC) by xiota)

Switched 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).

xiota commented on 2024-07-09 23:41 (UTC) (edited on 2025-02-19 18:07 (UTC) by xiota)

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.

Package-specific issues should be reported here.

<deleted-account> commented on 2023-02-21 02:33 (UTC)

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!

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 20 Next › Last »

xiota commented on 2024-07-08 01:57 (UTC)

@lounges I am not "chasing away" anyone. Asking maintainers to fix packages and opening orphan requests when they refuse is not harassment.

As stated multiple times, I will close the orphan request when this package is fixed. It is up to the maintainer to decide when that happens. The maintainer/developer already has a patch (mentioned in comment) that fixes the issue. It's mysterious why he prefers to leave this package broken over taking a few minutes to fix it.

To other users: The pinned comment is an inappropriate workaround. It instructs to put your system into a state of "partial upgrade" which would break other packages (whose maintainers did update them), potentially break the system, and is not supported by Arch.

lounges commented on 2024-07-08 01:30 (UTC)

@xiota I'm not really sure what you hope to accomplish by chasing away the author of this software. Not every package on AUR is officially maintained, and I for one appreciate it when they are. I made an account just so I could report you for harassment, but there does not appear to be any of that kind of functionality.

xiota commented on 2024-07-08 00:11 (UTC) (edited on 2024-07-08 00:24 (UTC) by xiota)

@LizardByte "I'm also not against providing a patch to this package. We would just need to discuss (probably easier on our Discord) and decide which patch to provide."

You could have stated that sooner instead of making threats. Regardless, orphan request will be closed when this package is fixed. Also, PMs do not act without reason. So this package is unlikely to be orphaned without your having had sufficient time to update.

"I have never once said to keep this package in a broken state"

KuleRucket implied package would remain in broken state in (deleted) response to requests to update. When I asked maintainers to reconsider, you threatened to drop support for Arch. This implies that you would rather drop Arch support than fix the package. You did not indicate, prior to the orphan request, prior to making continued threats, any intention to fix this package. (Arguably, you still have not, as "not against" fixing is not the same as intending to fix.)

<deleted-account> commented on 2024-07-08 00:09 (UTC)

@xiota... do you have trouble with reading comprehension? I have never once said to keep this package in a broken state... and I literally fixed the code upstream a few days ago... just because you are impatient does not mean this repo should be orphaned. "Broken" is also not the same as "out-of-date". https://bbs.archlinux.org/viewtopic.php?id=264443

I think you have some kind of weird and unhealthy obsession with obtaining ownership of AUR packages. Maintaining 340 packages, is not practical and there is no possible way you can keep up with changes upstream in that amount of packages.

xiota commented on 2024-07-07 23:50 (UTC)

@LizardByte If you drop support for Arch, that is YOUR decision. Threats do not change that this package is currently broken.

The fix requires adding a single line, and takes only a few minutes to apply. Instead, you insist on keeping the package in a broken state, expending more effort to do so than would be required to just fix it.

AUR is not a right, for users or maintainers. Maintainers who are unwilling or unable to keep packages in working condition should not maintain those packages. Orphan requests are a last resort to obtain PM adjudication. They rarely act without reason, which can be addressed by fixing this package.

<deleted-account> commented on 2024-07-07 23:22 (UTC)

@martyg, thank you for the backup! It's good to know this effort is appreciated. It's tough to read when this has been flagged so many times recently. The donation definitely is not necessary, but appreciated either way!

P.S. I am hoping to publish a new stable in the coming weeks. We just need to go through release validation checks.

I'm also not against providing a patch to this package. We would just need to discuss (probably easier on our Discord) and decide which patch to provide.

martyg commented on 2024-07-07 23:06 (UTC)

@xiota Your interference here is most unwelcome and appaling.

You should be thankful upstream has taken even a microsecond of their precious time to set this PKGBUILD up for you. Instead, we get this hostile priviledged attitude.

What do you hope to accomplish my pissing off our upstream developer? Is it so hard for you recompile locally to get yourself back online? Nobody appointed you as AUR police. Please go away.

@LizardByte Your efforts on this software have a great deal of value to me. I expect most other users here would feel the same way. Some beer money coming to you via PayPal. Thank you for this very useful free software.

<deleted-account> commented on 2024-07-07 21:54 (UTC)

@xiota as I said, if this orphaned... I will merge this https://github.com/LizardByte/Sunshine/pull/2819

This package was in a really broken state before I became the maintainer, so I would re-consider if I were you. By not supported, I mean I will literally, not support any users on our Discord or GitHub who use this ArchLinux package.

Cheers.

xiota commented on 2024-07-07 21:44 (UTC) (edited on 2024-07-07 21:46 (UTC) by xiota)

@LizardByte I have opened an orphan request. I fail to see how keeping this package in a broken state is "supporting Arch". Fixing a package does not make it "bleeding edge". The fix is a single line that takes less time to copy/paste/commit than it probably took for you to type your reply.

Note: I will close the orphan request when this package is fixed.

<deleted-account> commented on 2024-07-07 20:10 (UTC)

@xiota ... that wouldn't be smart, since I am the primary maintainer and the official owner of the source code on GitHub as well. And... if you do that, I promise I will stop supporting ArchLinux altogether :)

If you want bleeding edge please use the pre-release from our GitHub, where a pre-built package is provided as well as a PKGBUILD... or as already mentioned, used sunshine-git. You therefore have three options for a working build. The suggestion by @Cookie_Monster is also perfectly acceptable until we publish the next stable release.

@ZenithCC ... while that may allow the package to build, I'm sure you will get a segfault as soon as Sunshine tries to call those functions, which may not be an issue if you have upnp disabled.

@KuleRucket ... the suggestion by @Sonico98 isn't terrible, assuming you can do that without conflicts.

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 20 Next › Last »