No one had made git clones of them?

https://github.com/pineappleEA/pineapple-src is still up, but for how long 😓

https://github.com/citra-emu/citra is down too.

Citra can be done in a second PR? 🤔

You can delete it here too.

I'm not a lawyer, but I imagine that they need to be purged off from Hydra too?

Better safe than sorry.

Software Heritage has up-to-date archives if you didn't get them in time, and there are out-of-tree yuzu flake's on other forges for maintaining the nix expressions.

Removed now Citra too 😭

This feels a bit premature. There was no ruling that Yuzu is illegal. The out of court settlement, from my understanding, is mostly based on the situation that the company developing Yuzu took money for early access releases that specifically supported a yet unreleased game and also did not forbid discussion of piracy on their private Discord. I feel like for now it may make more sense to point this to a fork that contains the commits references from nixpkgs, and maybe switch it to a more active community maintained one once such is established. As Yuzu itself is GPL licensed, it will not disappear anytime soon.

Right now our expression does compile nothing. Waiting for an "oficial fork" does not make much sense.

On the other hand, there are copies of it floating around the forges currently.

Can't we remove mainline only and keep EA that is fetched from another repo? If it starts failing to compile at some point and there is no new upstream, then remove it.

Can't we remove mainline only and keep EA that is fetched from another repo? If it starts failing to compile at some point and there is no new upstream, then remove it.

My main issue with it is that the name itself is confusing: it should have been called pineapple-ea or something. Calling it yuzu-early-access does look like the upstream is still yuzu itself.

This is also why I think we need to wait until the situation stabilises: it may as well that pineappleEA becomes the new upstream, but I think this is still too soon to say.

Can't we remove mainline only and keep EA that is fetched from another repo? If it starts failing to compile at some point and there is no new upstream, then remove it.

Also, I am less concerned about the source code itself being available (as pointed above, Hydra caches FOD forever), and more about if we have an upstream giving the code proper support.

Can't we remove mainline only and keep EA that is fetched from another repo? If it starts failing to compile at some point and there is no new upstream, then remove it.

pineapple-ea just publishes GPL'ed Yuzu EA source code. Even if their repository stays online it's not a fork, it's more like a mirror, and the code is still unmaintained, there's no upstream, etc..

I think it's best to remove for now and see what happens in the future.

Backport failed for release-23.11, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-23.11
git worktree add -d .worktree/backport-293312-to-release-23.11 origin/release-23.11
cd .worktree/backport-293312-to-release-23.11
git switch --create backport-293312-to-release-23.11
git cherry-pick -x ef72e8b3a9b9743544b3ca6bca9da5770e20f51f 9b90f685e58c1483cbdea6388069e1ed8f57edae

Could it be re-added under suyu https://gitlab.com/suyu-emu/suyu ?

@RGBCube it will only make sense to do so if they prove to support the fork for real.

Could it be re-added under suyu https://gitlab.com/suyu-emu/suyu ?

Nope.

Status
We are trying to get the builds working. We are in need of developers. Join our discord to contribute.

Let's wait they gain more traction.
Besides, you can create a NUR node (or ask a NUR node maintainer to add it!).

I support the decision to delete any version of citra/yuzu that has no upstream. The fact that they have no upstream can causes a bunch of other issues that is not related to code availability, e.g.: who is going to fix build issues once we bump glibc, gcc or whatever else? Without the source code available upstream this task would be difficult (of course, not impossible, but it is more work than it should be).

I fully agree that this is a problem.

What I do not agree on is that a package must be removed due to such a problem. For the time being, Yuzu builds for anyone who can access cache.nixos.org which is practically everyone.

Besides, we have lots of packages where the source isn't available anymore (or never was, proprietary software anyone?).
We should strive towards having available sources (that's why we have the mirrors infrastructure) and not doing so warrants potentially marking a package as problematic but removal is a complete overreaction IMHO.

Some of our packages that have far worse issues than the upstream source having died that are still in the tree and don't hurt anyone.

Also, while the decision may be premature, I also don't want to add any of the forks that are appearing right now since they may or may not gather enough popularity. Once we have a clear winner I think we can reintroduce it without much issues. The code for the derivations will be preserved forever in Git anyway, so it should be easier to grab the old diffs and restore.

I'm similarly cautious but it doesn't really matter as we don't have to trust the forks for this purpose specifically. Because they contain all the previous revisions, we'd treat them as a mirror and simply lock the srcs to the specific revisions they would have pointed at before. It'd just be a different URL that serves the same content; hash would stay the same.

I'd certainly not have this reach the stable channel (absolutely no good reason for the breakage) and will propose to revert this.

How to handle "the Yuzu issue" requires a bit more discussion still and I see no point in removing it this soon already because it might potentially cause minor issues years down the line.
Once we reach the point where Yuzu causes actual issues affecting real users, then we can start thinking about removing it. Though even then marking the package with a harsher warning or requiring its source to be manually added to the Nix store would be the appropriate action, not removal.
At that point, we'll likely have an established continuation of the project too.

Besides, we have lots of packages where the source isn't available anymore (or never was, proprietary software anyone?).

For packages that are open source and the source is not available anymore, we should strive to remove them. Unmaintained software is a maintenance burden and we already have way too many packages in nixpkgs, IMO.

For proprietary software, AFAIK we generally have either of those 2 approaches:

• We have a derivation that uses requireFile and let the user download the software themselves
• The derivation itself downloads the source if possible

The first approach is really difficult to check if the source is still available, while the second one AFAIK people generally works to keep it up-to-date or at least available, so I don't see much of the issue here.

The first approach is really difficult to check if the source is still available, while the second one AFAIK people generally works to keep it up-to-date or at least available, so I don't see much of the issue here.

Yes and that's exactly my point. If it's not an issue for other packages, why would it be an issue for Yuzu?

Yes and that's exactly my point. If it's not an issue for other packages, why would it be an issue for Yuzu?

I am arguing it is an issue for other packages, it is just more difficult to track.

Yuzu/Citra kinda was really easy to reason its removal because it was in news everywhere, but most packages will disappear in the world and nobody will blink an eye. But my argument here is that if we find those packages we also need to remove them from nixpkgs.

What I do not agree on is that a package must be removed due to such a problem. For the time being, Yuzu builds for anyone who can access cache.nixos.org which is practically everyone.

1. Nix allows pinning a rev of Nixpkgs. I see no problem here.
2. Nix is, primarily, a source-based package manager. It makes few to no sense to keep a buildscript for a source that does not exist anymore.
3. You yourself gave the example of packages that can't be cached. Then we have exceptions to deal.

Besides, we have lots of packages where the source isn't available anymore (or never was, proprietary software anyone?). We should strive towards having available sources (that's why we have the mirrors infrastructure) and not doing so warrants potentially marking a package as problematic but removal is a complete overreaction IMHO.

I don't think so. The upstream does not exist anymore, and keeping an expression for it makes few to no sense.
As an historical curiousity (fulfilled by the fact it is a VCS with (a huge) history), maybe, but as a build script? Nope.

Some of our packages that have far worse issues than the upstream source having died that are still in the tree and don't hurt anyone.

Hey, this is an argument for cleaning up the codebase, not an argument for keeping it bit-rotting!

my argument here is that if we find those packages we also need to remove them from nixpkgs.

No. We do not as a general rule need to remove building, working packages where the upstream source happened to have gone MIA. Especially not if a substitute is likely to come up within a month or so and doubly enjoyed so if it's used by thousands.

We should create issues on them, ping maintainers, mark them as problematic etc. because a fetchable upstream is obviously something we want but removal without notice is not an appropriate action for any such package.

1. Nix allows pinning a rev of Nixpkgs. I see no problem here.

You cannot use graphical applications from revisions other than your system revision without terrible hacks. This is not an option for users and you should not be recommending it without mentioning that major gotcha.

Nix is, primarily, a source-based package manager. It makes few to no sense to keep a buildscript for a source that does not exist anymore.

For anyone who can use cache.nixos.org, it does indeed exist. If that went away too, then I'd start considering touching the package at all. Even in that case removal without notice is not the appropriate action for a widely used package but marking the source as broken and/or looking for a mirror.

You yourself gave the example of packages that can't be cached. Then we have exceptions to deal.

I do not understand what this sentence is trying to say.

The upstream does not exist anymore, and keeping an expression for it makes few to no sense.

Even if this was valid (which it is not, the src is cached), this only concerns the src, not the rest of the drv. While others are preferable of course, requireFile is absolutely a valid way to declare a source. This is really not much different.

Hey, this is an argument for cleaning up the codebase, not an argument for keeping it bit-rotting!

I have yet to see a good argument for how this "cleaning up" is going to help anyone.

Actually dead code that does not build anymore, where the package has no responsive maintainers and/or causes a concrete issue, yeah remove that shit.
Code that still works (I just built it), has maintainers and does not cause any concrete issue whatsoever for anyone? Why in the world would you remove that? Seriously.

No. We do not as a general rule need to remove building, working packages where the upstream source happened to have gone MIA. Especially not if a substitute is likely to come up within a month or so and doubly enjoyed so if it's used by thousands.

Thankfully it does not happen very often, but that kind of "what to do" should be documented somewhere to avoid this kind of situations.

Thankfully it does not happen very often, but that kind of "what to do" should be documented somewhere to avoid this kind of situations.

The previous occurrence was way worse: #157959

And at least in the previous case we had a still-alive source code.

I will not lock this thread (or at least yet) but can we please keep the discussion in #295587 instead?

For one this PR is already merged, for another having the same discussion happening in 2 different places is confusing.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/installing-package-that-was-removed-from-nixpkgs/41799/1