Revert "{citra,yuzuPackages}: remove package"

[Atemu]

Description of changes

As explained in #293312 (comment), an upstream source no longer being available does not warrant an immediate removal of a package that can build fine with cached sources for the time being.

Approval was only given by one of the 5 maintainers; the rest were not even notified. (This PR should ping them again.)

This is especially not an appropriate reaction when it is a package many people (including myself) used up until that point. Even if removal was the appropriate action, there should have been a grace period.

Appropriate measures for this issue I can think of:

• Marking the package with a warning
• Using a mirror
• Setting yuzu.src.meta.broken = true

Until such an appropriate measure is taken, revert to the previous status quo: A fully working Yuzu derivation with a minor problem for an extremely limited amount of users.

(If the maintainers do not wish to be listed here anymore because the package is "problematic" now, please speak out.)

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[K900]

I would want to wait for the dust to settle a little bit, so we can be more confident this isn't going to lead to a DMCA strike or whatever.

[Atemu]

That is my intention. Revert to the status quo, wait for an actual issue to crop up (i.e. DMCA notice) and then take a more extreme action.

I highly doubt Ninty would dare to attempt their corporate shitfuckery to this extent outside the US though.

[thiagokokada]

I concur with @K900 here. Let's wait, there is no reason to restore those packages until we have a proper upstream (that is also not DMCA'd).

For everyone that wants to use those packages, you can always just copy the derivation to your configuration and get a copy of the repo somewhere.

Edit: sorry, pinged the wrong person in the original reply.

[Atemu]

there is no reason to restore those packages until we have a proper upstream

That's the point I disagree with. These packages have users and they work for them. We are actively removing functionality from their systems.

This was not a cleanup of dead or broken code; it still works. I just built yuzu right on my system. The source came from cache.nixos.org which is obviously not ideal but not the end of the world either.

I intended to keep this rather simple to unbreak users but switching out the sources for an alive mirror should be rather simple and would leave the yuzu package without any significant technical issue.

[thiagokokada]

That's the point I disagree with. These packages have users and they work for them. We are actively removing functionality from their systems.

Removal of packages or features will always break someone relying on that functionality. Heck, even a refactor made wrong will break some users.

In the end we need to decide between what is worth maintaining and what it is not, and in my opinion keeping those packages is not worth maintaining them until we get a new upstream that will not be DMCA'd next week.

That's the point I disagree with. These packages have users and they work for them. We are actively removing functionality from their systems.

I think we agree to disagree at this point.

[Scrumplex]

It should also be emphasized that the early-access source code provided by pineappleEA is still available and has been available despite upstream yuzu being taken down.

See https://github.com/pineappleEA/pineapple-src

[thiagokokada]

It should also be emphasized that the early-access source code provided by pineappleEA is still available and has been available despite upstream yuzu being taken down.

See https://github.com/pineappleEA/pineapple-src

It doesn't help that pineappleEA only publishes the code and doesn't seem interested in maintaining the code (that IMO is more important to me). Looking at the commit history the only commit after the whole mess was an update to the README.

I would be ok if pineappleEA is re-introduced as pineapple-ea instead of yuzu-early-access though. At least this would make it clear that this is not Yuzu, so there is no maintained upstream.

However I would still prefer to wait because I am sure eventually an actual upstream will appear.

[thiagokokada]

I am putting this as "request changes" since I don't concur with this decision, but if there is a consensus that we need to restore those feel free to dismiss my review.

[Atemu]

In the end we need to decide between what is worth maintaining and what it is not, and in my opinion keeping those packages is not worth maintaining them until we get a new upstream that will not be DMCA'd next week.

I fail to see any sort of maintenance burden here. I can assure you that the package will not have to account for upstream changes in the foreseeable future ;)

I'm willing to step up as a maintainer in the interim if you're at all worried.

I'm also again of the opinion that packages should not be removed on the grounds that there could potentially possibly be a burden sometime far into the future but rather at the point where an actual burden materialises.

only publishes the code and doesn't seem interested in maintaining the code (that IMO is more important to me).

That's enough for them to function as a mirror which is all we need to mend the "pressing" technical issue of source unavailability.

Yes, upstream development is no longer taking place. If I had to guess the same is true for 1000s if not 10000s of packages in Nixpkgs; they're not hurting anyone.

[thiagokokada]

I fail to see any sort of maintenance burden here. I can assure you that the package will not have to account for upstream changes in the foreseeable future ;)

Maintenance burden also happens when we do any changes in dependencies that can break because a package depends in an older version of this package.

Generally who handles those fixes is upstream, but without an upstream who is going to do those? In lack of upstream doing the change (because e.g.: they don't support third-party packaging for example) we can do it ourselves, but generally having the source code available is crucial for those cases and right now we don't (unless you download the code from Hydra, that really is a PITA).

That's enough for them to function as a mirror which is all we need to mend the "pressing" technical issue of source unavailability.

See point above.

[AndersonTorres]

That's the point I disagree with. These packages have users and they work for them. We are actively removing functionality from their systems.

Yes, because upstream died.

This was not a cleanup of dead or broken code; it still works.

This is literally a dead and broken code, since the upstream repo disappeared.

I just built yuzu right on my system. The source came from cache.nixos.org which is obviously not ideal but not the end of the world either.

1. This is not ideal, caching is a workaround. This is an argument for its removal, not for bit-rotting the repo.
2. There are projects that do the archaeological work you are proposing:

• https://lazamar.co.uk/nix-versions/
• https://www.nixhub.io/
• https://history.nix-packages.com/
• https://github.com/jeff-hykin/nix_version_search_cli

I intended to keep this rather simple to unbreak users but switching out the sources for an alive mirror should be rather simple and would leave the yuzu package without any significant technical issue.

Let the NURers do it, then.

I fail to see any sort of maintenance burden here. I can assure you that the package will not have to account for upstream changes in the foreseeable future ;)

Including security bugs (that will be discovered some day) that we will not patch (since we are mere packagers)?

This is precisely another argument for removal, not for keeping the corpse.

[AndersonTorres]

(unless you download the code from Hydra, that really is a PITA).

Remembering that Hydra merely downloads raw code, not its Git history.

[yu-re-ka]

I am in favor of keeping around.

There is nothing that would make this criminal anyways, just like youtube-dl isn't criminal.

Indeed SuYu looks quite active already, and even if that project dies there is going to be ten new ones. I don't worry about maintenance burden falling on nixpkgs devs at all. Quite the opposite, this is one of the easier packages compared to the other corpses we have lying around (OpenCV2 anyone?).

[AndersonTorres]

There is nothing that would make this criminal anyways, just like youtube-dl isn't criminal.

This is not about legal conundrums, but about the removal of a dead software.

Indeed SuYu looks quite active already

Are you arguing for packaging Suyu or for reverting the removal of Yuzu?

[yu-re-ka]

I would suggest reverting the removal of Yuzu now, and switching the source over to SuYu (or whatever fork seems to align most with former yuzu) at a later point (when a suitable tagged version is available).

[ElvishJerricco]

Inaccessible tarballs that only work by the grace of cache.nixos.org is not an acceptable thing to knowingly merge into nixpkgs IMO. Sure, there are probably a lot of packages that rely on this in nixpkgs but that's not on purpose and they should probably be removed when noticed. This is a knowing action to add broken packaging to nixpkgs.

If we were changing the package to point to a new fork or something, it'd be a different story.

[Atemu]

I did the thing and all sources are now reproducible again. It's not pretty but it works and is good enough.

I also added the notice and made myself the maintainer of these packages for the interim. I'll again extend my offer to the previous maintainers to remove them if they no longer wish to maintain these packages.

[thiagokokada]

I've yet to see an argument that did not boil down to whataboutism. If I missed one, let me know.

Again, those are arguments for issues that will happen. The question is not what or if, it is when here.

I don't cut my arm off to go skiing because I could potentially break it when I fall. That makes no sense at all.
would somehow not be able to deal with this package's "critical" issue.

I am tired of this discussion and the sarcastic (and passive-aggressive) tone (from both sides actually, this is not just direct to OP). I will unfollow this thread. My point still stands, and I am not really happy to the proposed solution (pointing to random repository mirrors, especially because the changes keep the update scripts).

I am ok for opening a new PR packaging Suyu or some other fork, but please don't ping me to be a reviewer since I don't want to be part of this discussion anymore.

[Atemu]

I am not really happy to the proposed solution (pointing to random repository mirrors

Let me be clear here: I'm not happy about this at all either but it is an interim solution and for that, it's good enough.

the changes keep the update scripts

Good point, forgot about those. They're actually dead code this time.

[JoshuaFern]

I'm unsubscribing from this discussion as well. I believe this entire proposal is driven by some kind of emotional desire not to give up on Yuzu, which I empathize with.

My stance is that this change should not be reverted, cache.nixos.org or mirrors should not be used, and whatever other "solutions" and arguments are manifested to include broken, dead, and unmaintained software into nixpkgs should be rejected.

[AndersonTorres]

Staging cycles bear no significance for keeping or not keeping packages. Their one and only purpose is to group large rebuilds.

Since Staging brings too many mass-rebuild packages to Master, it has bigger probability of clash.
But this is not relevant to the arguments in any way.

Any "mirror" of the most recent Yuzu code falls under the first condition for "not being accepted" under the packaging guidelines

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

Bold mine.
Further, remembering that I helped writing this in order to be more welcoming to new contributors. The original proposal was way harsher.

Please take your false dichotomies elsewhere and don't lay words in my mouth.

This is precisely the tone you are directing this pull request: keeping a dead-upstream package at all costs.

I do not see what python2 has to do with this? Yuzu does not depend on python2 in any way that I'm aware of.

I gave two examples of similar polemics of keeping a software after its EOL.

Sorry, I missed a word in the sentence: "Why would we not attempt to patch security bugs when they're discovered?"

We can anything we like (given that it is not a sin or a crime or a trigger for a Nintendo lawsuit).
But this is not our duty as package maintainers.

It was attempted for python2. Python2 was marked insecure because it remained insecure despite attempts, with reasonable notice and attempted alternatives.

Even after reasonable notice and attempted alternatives, Profpatsch loudly complained about their packages being removed.

Looks like the story is repeating.

Up to which point updating patches does not become acting like an upstream maintainer?

I'd draw the line at developing new features related to the core of its purpose. Patching things to be compatible or secure is historically well within the domain of distros.

We have at least two problems here.

• Yuzu is not meant to be a static piece of code that will never change. Indeed such emulators need to deal with new softwares and new functionalities created for the original hardware (and the host hardware too). In other words, Yuzu is obsoleted software since 2024-03-04.
• Even before that "only security or otherwise minor patches" line, the ideal scenario should be uploading those general-purpose patches to the upstream. And, as I said before, upstream is gone and backup repos are at most a subpar band-aid.

This expression is being kept with the help of too much devices.

I don't see any merit discussing the philosophy of when someone is considered an upstream maintainer in this context.

As I said before, maintaining a collection of patches for a backup of a dead upstream is not our duty.

Okay, point still stands. A quick ripgrep reveals 313 instances of pythonRelaxDepsHook to patch software to "keep up to date" with our newer deps. I believe many more instances of that exist done manually.

Not going into the intricacies of Python projects,
As I said before, in an ideal scenario, those patches and hacks should be upstreamed.

That's about the extent of "keeping up to date" we'd need to do for yuzu. (Note that this is an exclusive "we", you or anyone else uninterested in yuzu is not obliged in any way to touch yuzu in any way.)

This "exclusive we" is an argument for keeping this in a NUR, not in the Nixpkgs monorepo.

I advocate for that too. Don't see how that applies here in any way as upstream is quite obviously dead.

And this is the master point of the original pull request you are now reverting.

If by "general-purpose patches" you mean compatibility and security patches then that is a false statement. We have plenty of those in-tree. If not, I don't see why you'd mention this because patches other than compatibility and security were not up to discussion before.

Point taken.
Nonetheless this is not the ideal - again and again, it is not our duty to be a repository of general-purpose patches, they should be offered to upstream.

I do not.

This is the tone of your whole banzé. Your arguments always impose a series of "maybe" steps before removal of this dead upstream.

Please make serious arguments. I do not appreciate trolling.

You are being sarcastic and passive-aggressive all the time. "Pot meets kettle", as they say in Anglophone world? LOL

Answering the hidden content

It's funny when you rely on passive-agressive behavior, whereas when I retort in the same tone pointing out the ridiculousness of your "keep it indefinitely" proposal, your reaction is a threat to call the mods!

Maybe I should need to learn how to be more sensitive to sarcasm and threaten to call the mods when I am the target of one!

If you're not interested in yuzu, feel free to ignore it. Nobody is asking you to maintain yuzu in any way whatsoever.

Again, another argument for keeping it in a NUR.

If you happened to be a maintainer of a dep of yuzu (correct me if I'm wrong here but I don't believe you are)

Just to be sure, Yuzu depends on Qt and CMake.

It will be impossible to ignore it when/if they become incompatible - yet another reason to NURing it.

Further, personalizing arguments this way is a little bit dishonest.
I don't like it. I hate badge-flashing arguments.

Not that you care, seemingly...

Ah yes of course, you know that so much better than me. Lol.

Paraphrasing myself:

Your purpose, from what you wrote - from what you wrote -, is not merely reverting a premature PR, but keeping this packages indefinitely.

I can't read your mind, I can only read your words.

[Aleksanaa]

suyu release is out, let's move to it

[K900]

I would give it some more time. The 0.0.2 release of suyu is ... extremely messy.

[aanderse]

hi team 👋

where are we on this? new release coming up, it would be nice to have something easily available...

[K900]

Yuzu is very dead.

[aanderse]

i think everyone here understands that - so what will we do? package suyu? abandon everything all together and add an article to the wiki with a nix expression on how to build the last release of yuzu locally? or... ?

[K900]

Recommend people to use Ryujinx. Suyu is effectively also dead.

[nyabinary]

Recommend people to use Ryujinx. Suyu is effectively also dead.

What about for 3ds emulation?

[K900]

We can see which of the forks is alive, if any, and package that.

[AndersonTorres]

Lime3ds, I believe...

[nyabinary]

Lime3ds, I believe...

Panda3DS too (not a fork but an independent 3ds emulator)