pkgs/top-level/release.nix: enable pkgsLLVM

[RossComputerGuy]

Description of changes

Now that the Nixpkgs LLVM WS project has reached its first goal, let's enable pkgsLLVM testing in CI.

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.11 Release Notes (or backporting 23.11 and 24.05 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.

[RossComputerGuy]

Ofborg runs into infinite recursion with legacyPackages.x86_64-darwin.pkgsLLVM.python3 but not legacyPackages.aarch64-darwin.pkgsLLVM.python3

[RossComputerGuy]

@ofborg eval

[RossComputerGuy]

It seems Ofborg might be OOM'ing.

[RossComputerGuy]

@ofborg eval

[nyabinary]

Merge conflict (also what the general status?)

[RossComputerGuy]

Rebased, the problem is Ofborg doesn't have enough resources. Not sure about the solution to that.

[nyabinary]

Rebased, the problem is Ofborg doesn't have enough resources. Not sure about the solution to that.

Could potentially ask in the staging channel a solution to this?

[pbsds]

The ofborg evaluator needs to be fitted with more ram to accommodate the larger release set, and may even have to add more workers, considering we already have a rising eval queue problem

[RossComputerGuy]

Could potentially ask in the staging channel a solution to this?

Does changing the branch increase the amount of available RAM?

[RossComputerGuy]

I've rebased the PR. @infinisil how can I verify that attributes under pkgsLLVM are being evaluated? I see in the attrpaths JSON that ["pkgsLLVM", "stdenv"] is mentioned.

[wolfgangwalther]

Just some thoughts.

[wolfgangwalther]

Those checks are related to pkgsLLVM specifically, so I think it's the wrong place to put this knowledge.

Assume we are going to add e.g. pkgsStatic eventually, too - we might need different conditions here.

Is this even needed with the "if darwin then self" check you currently have in stage.nix?

[RossComputerGuy]

The problem is I need to disable eval for Darwin but checking if it's for Darwin isn't as simple as it looks.

[wolfgangwalther]

The problem is I need to disable eval for Darwin

That's what I was questioning. With this line:

pkgsLLVM = if stdenv.hostPlatform.isDarwin then self else

eval should succeed on darwin, right?

In fact, it should just refer to the same attributes as on the top-level, so eval on darwin should be a no-op? What am I missing?

[RossComputerGuy]

No, it complains about missing attributes and fails to eval Darwin.

[wolfgangwalther]

I assume that release-attrpaths-parallel.nix is only run by nix/eval, while release-outpaths.nix is also run by hydra?

If so, I think we should add includeSubpackages here like includeSubpackages = true; and don't take an argument for it in this file.

[RossComputerGuy]

Yes but I still think it isn't a bad idea to have this so if someone runs this in their own setup, they could disable it.

[wolfgangwalther]

I think it would be great, if we ultimately had an interface like this:

Suggested change

	pkgsLLVM = if stdenv.hostPlatform.isDarwin then self else nixpkgsFunSub {
	pkgsLLVM = nixpkgsFun {
	config = { eval = true; hydra = false; };
	...
	}

Thus we could define those properties in exactly one location - right where we define the package set.

And then everything else should just work off of that.

[RossComputerGuy]

The problem is some attributes in CUDA disappears in Darwin which causes Darwin evals to fail. From a UX perspective, this looks better but practically this is a harder problem to solve.

[RossComputerGuy]

@ofborg eval

[RossComputerGuy]

Not able to reproduce the Ofborg error, trying a rebase to see if that fixes it.