Package Details: sunshine 0.23.1-5

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: 53
Popularity: 2.08
First Submitted: 2021-04-26 11:33 (UTC)
Last Updated: 2024-09-04 04:09 (UTC)

Required by (0)

Sources (13)

Pinned Comments

xiota commented on 2024-07-17 01:54 (UTC) (edited on 2024-07-17 01:56 (UTC) by xiota)

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

xiota commented on 2024-07-09 23:41 (UTC) (edited on 2024-07-27 10:27 (UTC) by xiota)

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.

<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 2 3 4 5 6 7 8 9 10 .. 16 Next › Last »

lounges commented on 2024-07-08 21:48 (UTC)

Ah nice, @xiota 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.

Fazzi commented on 2024-07-08 21:20 (UTC)

Aside from the conversation below, I'm happy to see this package back in working order. I understand the frustration but as long as we still have access to maintain this package ourselves it isn't too big of a deal.

dr460nf1r3 commented on 2024-07-08 15:16 (UTC)

If you can't take valid criticism, that's not a problem with Arch community but something else.

<deleted-account> commented on 2024-07-08 11:16 (UTC)

I'm done with Arch. This is not a community I will associate with or support any longer. No bug reports for this package will be accepted on our GitHub.

dr460nf1r3 commented on 2024-07-08 10:36 (UTC)

This whole discussion is a disgrace, honestly. 1. Fixing this whole situation would've already been done easily if @LizardByte didn't insist on this very weird mentality of not pushing updates 2. Instructing users to potentially break their systems as "fix" is the next thing which is absolutely outrageous 3. Threatening to cease Archlinux support is a really immature way of handling it, especially if people make a valid point 4. There is a thing called pkgrel for packaging updates without having to wait for the next stable release upstream. It's indeed very common practice to fix up packages.

xiota commented on 2024-07-08 02:45 (UTC)

@lounges "Knock it off." – Knock what off? After other people had reported problems, requested fixes, and proposed solutions, the maintainers refused to fix this package. I made a single request for them to change their mind. I opened the orphan request after it was apparent they would not.

Other comments have been in response to comments about or directed toward me, such as yours. If you don't want me to comment, don't make unsubstantiated claims for me to defend against.

What exactly is the maintainer/developer calling me out on? Asking them to fix the package? Opening the orphan request when they refuse? Both could have been avoided if they had fixed the package over five days ago when the patch became available.

At this time, the maintainer has indicated that he might fix it, but has not committed to doing so. So the orphan request stands. Again, when this package is fixed, the orphan request will be closed. It is fully up to the maintainer when that happens or whether the package really does need to be orphaned.

lounges commented on 2024-07-08 02:25 (UTC)

@xiota They made a PR to drop support for this package and explicitly called you out by name. That is the definition of chasing away. Knock it off.

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

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 16 Next › Last »