Ryujinx has been removed. Need to decide next steps.

[Faeranne]

Issue description

The owner of the Ryujinx organization has deleted the org and all data. According to riperiperi on the discord:

Yesterday, gdkchan was contacted by Nintendo and offered an agreement to stop working on the project, remove the organization and all related assets he's in control of. While awaiting confirmation on whether he would take this agreement, the organization has been removed, so I think it's safe to say what the outcome is.

This is a hard block to building ryujinx anymore. Like Yuzu before, something needs to be decided here, though in this case this is not a DMCA take down, so existing license applies. Might make just as much sense to find a valid fork in the not too distant future.

Maintainers

@06kellyjac
@artemist

[artemist]

I'll follow the fork situation. There were some active devs other than gdkchan and it's possible some of them work on a maintained fork, though a few have posted in the ryujinx discord guild that they will not be continuing to work on switch stuff.

The source code for 1.1.1401 is still in the nix substituter so building after an stdenv or c# change should not be a problem.

[artemist]

I tend to be against removing software just because it's no longer maintained. If there's a security vulnerability, mark it as such, but I don't see any reason to remove ryujinx before there's a suitable replacement

[griffi-gh]

Could point it to https://github.com/ryujinx-mirror/ryujinx for now? (until a proper fork appears)

[Naxdy]

@artemist There was a similar discussion about Yuzu when it was removed, starting with this comment: #293312 (comment)

I think, sadly, the logical conclusion is to remove Ryujinx from nixpkgs, until a well-supported and -maintained fork pops up. Those who continue to rely on Ryujinx (to which I count myself) will have to build it from source. I'll work on a flake for that in the meantime, which I will publish on my personal git instance sometime this week: https://git.naxdy.org/NaxdyOrg/Ryujinx/

[griffi-gh]

This is different from the Yuzu situation tho since it's not a legal takedown, just a repo deletion.
It should be fine to just point it to a mirror and mark the package as deprectated instead of outright removing it.

[Naxdy]

The reasons for the takedown don't matter. Upstream is gone, the expressions no longer compile without binary cache. Refer to the thread I linked to (you'll have to expand the comments), where all of this has already been discussed at length. The DMCA wasn't even part of the reason to remove it from nixpkgs.

I don't like it either, but there's no point in keeping software in nixpkgs that has no upstream.

[Naxdy]

As an update for everyone, I added an easy-to-use flake to keep Ryujinx in your configs to my repo of it. I don't plan on maintaining it at all however (not even updating dependencies), so it will essentially just be a snapshot of the last available version, until some other fork comes around.

GitHub: https://github.com/Naxdy/Ryujinx

Forgejo: https://git.naxdy.org/NaxdyOrg/Ryujinx

[niklaskorz]

Proposing moving to your own unmaintained flake at the same time as opening the removal PR for a package that you're not the maintainer of kind of feels like a hostile takeover, not gonna lie. I feel like this behavior should be discouraged.

[Naxdy]

I'm sorry you feel that way. The purpose of the flake is not to take anything over, but rather a short-term solution to provide a starting point for people who wish to continue building Ryujinx from source after its inevitable removal from nixpkgs, until a proper fork emerges.

Yuzu & Citra were removed from nixpkgs extremely quickly after their takedown from upstream, and the lack of alternatives both in nixpkgs and otherwise was a pretty big blocker for me personally, so my intent was to avoid others from having to go through the same hassle of sourcing recently removed build scripts, fixing the source inputs, and integrating them into their config, as I have done with Citra (a mirror of which I also host, here https://git.naxdy.org/Mirror/citra - just without the flake)

[Frontear]

Yuzu and Citra were as a result of a lawsuit from Nintendo (which was to some extent justified given the profiting).

Ryujinx is a slightly different edge-case and I think it's generally a better idea to take the maintainers perspective here, which is to leave the package alone. However if a suitable fork can't be found, I believe the best choice would be to simply mark as broken. This way can indicate to all affected users that this binary is not buildable for the time being.

[AndersonTorres]

I tend to be against removing software just because it's no longer maintained.

First, there is RFC 180 discussing that issue.

Second, let's be more accurate here.
This is not a mere "no longer maintained" abandonware situation (as in, say, Jikes), but a takedown: the original, pristine source simply disappeared.

[Atemu]

RFC180 does not cover upstream situations, only our downstream situation. It explicitly defines "unmaintained" packages as packages that do not have Nixpkgs maintainers listed.

We also don't really know what spurred the takedown yet. As far as we can tell, no legal action was involved, so it's not like we can expect mirrors to be taken down (as was the case with Yuzu).

[honnip]

I think it should use a mirror and disable updates, or be removed. There's no point marking it as broken if it's never going to be fixed.

[Faeranne]

As someone who has slowly been building my own private binary cache (internet here is garbage, and being unable to do any config changes for hours can leave me unable to do any work), leaving broken package in purely on the idea of "well the binary cache still has it" has left me stranded in the past. Idk what the solution actually is, since rapidly removing a package isn't a great option either, but if nixpkgs isn't actually building correctly, that seems like a bug to me. Since changing the source for a package involves forking nixpkgs, that seems like a quick way to lose sanity, vs nixpkgs actually being valid and reproducible.

[MathiasSven]

Why don't we just follow what the AUR did? Any mirror pointed at the same commit hash would suffice. Then we just drop passthru.updateScript and the script file itself.

[Atemu]

Doing what @MathiasSven suggests seems like the best option until something about the situation changes. Source unavailability, while certainly not a major issue, is a serious problem and using a mirror would be an immediate band-aid for that.

If the package were to break due to dependency changes in the future and the maintainers didn't want to vendor a fix, the package would then be marked as broken and could be removed (probably in accordance with RFC180 at that point). I don't expect that to happen any time soon though.

If a new upstream appears, we can simply switch to that and make ryujinx an alias for it if it's under a different name.

[artemist]

Thanks for adding the archive.org mirror. I've been busy for the past few days I was planning on using the mirror used in the AUR today, but the Internet Archive seems like a better choice.

[Nabile-Rahmani]

Yeah, they won't go anywhere there :)

The git repo I got from archive.org from which I regenerated the tarballs seems 99.94% pristine (SHA256: b4e3aa518a05ce44c33298b83829f2ce27b98fcc3d5774ed7479cc9679782b82).

Thanks to your maintenance efforts and the package's SHA256 hashes, we can be reasonably confident that the repository history up to 1.1.1401 is untampered, leaving us with merely two commits to audit if we're paranoid.

* a2c00350 (HEAD -> master, tag: 1.1.1403, origin/master, origin/HEAD) Update audio renderer to REV13: Add support for compressor statistics and volume reset (#7372)
* 7d158acc (tag: 1.1.1402) Do not try to create a texture pool if shader does not use textures (#7379)
* 5dbba07e (tag: 1.1.1401) sdl: set app name (#7370)

21 files changed, 353 insertions(+), 89 deletions(-)

Of course, we wouldn't even need to question anything had the commits been cryptographically signed.

I can't thank you enough for resisting this anti-consumer intimidation against a brilliant piece of engineering.

I don't want my games nor all these years of effort to go to waste, and mirroring Atemu's thoughts, am hoping maintenance on this solid software will be smooth sailing for years to come.

Heck, I hope I'd be able to lend a hand in case stuff breaks.

Can we please defuse the removal PR ? :)

[Nabile-Rahmani]

Pardon me for bringing this up, but I find it really puzzling that the first reaction to stable software getting orphaned is to remove it from a distribution, rather than mirroring it and tending to it as our maintainers are willing to do.

Has the software industry at large conditioned people to think that if you look away for a mere second, software will inevitably bit rot ?

Most software I ever wrote can be rebuilt and run without modification years after the fact (maybe less so for moving targets like Blender addons or the web ecosystem, which I'm picky about).

Technologies like .NET, SDL, Rust, the Linux kernel, or Wine (90s SDKs are still alive and kicking) care deeply about backwards compatibility. Even a standard HTML5 website can work just fine on a Dreamcast if you do the right thing and progressively enhance it.

This results in timeless, predictable software, and happy developers and maintainers.

Conversely, eagerly removing a perfectly working package contributes to said churn as all users relying on it would be startled as soon as they upgrade NixOS and be forced to needlessly fix their configuration, either removing it or looking for an out-of-tree replacement, with all the inconveniences that comes with that (no binary caching, etc.).

It doesn't sound like a good time for anyone involved, so why do it ?

It made me wonder if I would've lost access to this software had I not stumbled on the news in time.

[AndersonTorres]

I have the opinion that we should put those things on NUR.

Technologies like ... Rust ... care deeply about backwards compatibility.

Ehr, Rust introduced breaking changes recently.

[emilazy]

Has the software industry at large conditioned people to think that if you look away for a mere second, software will inevitably bit rot ?

Nixpkgs maintenance has conditioned me to think that :/

A modern emulator like Ryujinx especially has quite a lot of moving parts. Hopefully someone will pick up maintenance, although it seems like there aren’t many qualified maintainers to continue with these kinds of projects after the original teams call it quits. I wouldn’t be surprised if an FFmpeg update or similar breaks it otherwise.

[Nabile-Rahmani]

@AndersonTorres Could you provide any rationale on why this package should suddenly be downgraded and break all users' installation when nothing happened to the source code and maintainers are there to support it ?

As for Rust, one unforseen issue should not discredit the stellar stability guarantees they've upheld for such a long time. It certainly doesn't compare to some other software ecosystems.

But yeah, this strongly makes me question why I still have it in me to swim against the current in seeking real software engineering. I'll see what I can do to keep this one alive though.

[AndersonTorres]

First, "nothing happened to the source code" is at least a doubtful sentence. The original repo disappeared, the best we have is a backup.
And, since at least the xz-incident, second-hand source code is less reliable.

Second, NUR is just a migration, not a huge downgrade.

Third, IMnsHO Nixpkgs is a database for scripting and metadata for fresh and pristine software. "Fresh" is a bit malleable - the monorepo has some useful abandonware -, on the other hand "pristine" has a more clear cut definition.

When the source code disappears, arguably it can no longer be treated as pristine.
This conclusion can be drawn from the recent guidelines for adding packages: https://github.com/NixOS/nixpkgs/tree/master/pkgs#quick-start-to-adding-a-package

Is the package ready for general use? We don't want to include projects that are too immature or are going to be abandoned immediately. In case of doubt, check with upstream.

Bold mine.

Further I have written at length about this months ago:

• {citra,yuzuPackages}: remove package #293312
• Revert "{citra,yuzuPackages}: remove package" #295587

[emilazy]

Without speaking to the general point of abandonware in Nixpkgs –

First, "nothing happened to the source code" is at least a doubtful sentence. The original repo disappeared, the best we have is a backup. And, since at least the xz-incident, second-hand source code is less reliable.

We have a git archive tarball hosted on archive.org that matches the exact NAR hash from GitHub; there’s really no question about its authenticity and any mismatch would be immediately caught. We have plenty of web.archive.org in the tree serving a similar purpose.

[Nabile-Rahmani]

Thank you for explaining this.

No offense, but it hurts inside when someone in a position of power does not seem to grasp the basics, but I'm willing to believe I'm misunderstanding.

It doubly hurts when I wish to reach out and offer my help to improve a distribution I love so that users don't get turned off by the churn, only to be taken down.

But that is okay. I'm certainly not blaming anyone for my own feelings. I'm more likely to just walk away.

There is a reason Nix trusts these cryptographic hashes that it systematically puts them on all packages.

An xz would be hard to pull off there. I too hate malware.

Combined with how git hashes its commits to assure you that their ancestors are pure (the buzzword is "blockchain"), along with multiple tree archives that pretty much match bit-for-bit with results we already know, we can safely assume nobody evil had the time to poison any mirrors converging on that truth.

Please see Wikipedia:

The Git history is stored in such a way that the ID of a particular version (a commit in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. The structure is similar to a Merkle tree, but with added data at the nodes and leaves.

Lastly, handwaving away a respected systems programming language on the basis of a single mistake is disheartening when they work so hard to make people's lives easier.

I kindly wish you the best.

[emilazy]

While I have mixed feelings about both removing software because of Nintendo’s meddling and keeping unmaintained software in Nixpkgs, I feel I ought to point out that @AndersonTorres is a non‐committer contributor, like you, and his word doesn’t necessarily carry any more or less weight in this discussion than yours.

[Naxdy]

While personally, I don't have a strong opinion on what to do in these situations (remove, switch to mirror, do nothing), I do think that we should have a proper guideline with regards to what should happen in the case of a sudden upstream disappearing magic act.

In the meantime, I opened #346797 to mark Ryujinx as known vulnerable, to let users know what they're installing is not developed or maintained by upstream.

[AndersonTorres]

We have a git archive tarball [. . .]

I am speaking about this in general terms.
A better rewording would be "a backup/mirror/copy/etc. is no more reliable than the original Git repo".

(Although, if we would be more paranoid about this, the tarball generated from fetchFromGitHub discards at least the .git dir. But let's not dig this conversation even more.)

No offense, but it hurts inside when someone in a position of power does not seem to grasp the basics, but I'm willing to believe I'm misunderstanding.

I have no power here.
At best I can complain about bad code (or good code), but ultimately I do not have the last word.

There is a reason Nix trusts these cryptographic hashes that it systematically puts them on all packages.

Most of what I have written is not restricted to Nixpkgs, at least in principle.
This is just about a script that expects an input - and that input disappeared.
What should we do?

I think it makes few to no sense to keep this piece eating cycles on Hydra.

Lastly, handwaving away a respected systems programming language on the basis of a single mistake is disheartening when they work so hard to make people's lives easier.

No one throws away OpenSSH away because or RegreSSHion.
On the other hand, homeric battles were fought because of backwards compat being broken...

[Redhawk18]

It's important to remember that this isn't like Yuzu, the author likely took a check and closed the project. They were not stuck with a dmca, it should be space to host it in nixpkgs.

[AndersonTorres]

Even the case of Yuzu is unclear.
We just provide the script, the inputs for the script are up to you.

[Redhawk18]

Thats true, I agree. Thats exactly what I did in my pr that involves assets in #342365.

[Faeranne]

It's important to remember that this isn't like Yuzu, the author likely took a check and closed the project. They were not stuck with a dmca, it should be space to host it in nixpkgs.

Either a check, or an agreement not to sue/harass, we don't know the exact details rn. Either way Nintendo isn't using the legal system to claim the license on the code is invalid, so it, in theory, is still safe to have in nixpkgs, just needs an actual source backing it somewhere.

[Redhawk18]

The mirror suggests this fork now