hydra-unstable: 2022-02-07 -> 2022-05-03

[NickCao]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 22.05 Release Notes (or backporting 21.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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[NickCao]

The fixed link failure should be a result of nix commit da7d8da

[Mindavi]

Diff LGTM now, I'll maybe install this later today and test it out further. Thanks for picking this up!

[Mindavi]

@ofborg build hydra_unstable

[Mindavi]

I had some issues upgrading due to sddm breakages :(, so didn't get a good chance to test this (though it seemed it did at least start running).

[NickCao]

It's running riscv builds fine on my machine (even with nixUnstable and a bit more patching).

[NickCao]

The ofborg failure looks like just a timeout?
A timeout (event) has occured (after 60.9713 seconds), job was forcefully killed

[Mindavi]

Seems like an unstable test, which is annoying since it prevents hydra being cached properly.

Are you willing to look into this (e.g. disable the test for now)? Would be nice if ofborg and hydra are happy with this too.

[Mindavi]

I got this to build locally and it looks good. The diff viewer (scmdiff) is broken, but that due to this issue and should be handled upstream: #169193.

[Mindavi]

Noting the test fail here for reference:

Failure executing slapadd -F /build/yath-4590-S6UpHp/tmp/EMc9Hr/UWkQCivT0y/slap.d -b dc=example -l /build/yath-4590-S6UpHp/tmp/EMc9Hr/UWkQCivT0y/load.ldif.

Also seeing some 'unexpected EOF', but that's probably nix bugs :(.

[NickCao]

I tried rebuilding multiple times, no luck to reproduce the failure, does ofborg configure nix daemon in a particular way that makes this happen?

[Mindavi]

Not sure. I managed to reproduce it though, although rarely.

[Mindavi]

Might need to disable that Hydra/Controller/User/ldap-legacy.t test to reduce the amount of failures we'll see on hydra.

Result of nixpkgs-review pr 173218 run on x86_64-linux 1

3 packages built:

• hydra_unstable
• perl532Packages.TestPostgreSQL
• perl534Packages.TestPostgreSQL

Been running this for a few days now and looks good otherwise.

[NickCao]

Might need to disable that Hydra/Controller/User/ldap-legacy.t test to reduce the amount of failures we'll see on hydra.

Would a simple rm do the trick?

[Mindavi]

Yeah, that'd probably work fine.

[FlorianFranzen]

@Mindavi Why was the pin moved from v2.8 to v2.6? I would even argue to remove the pin, if I run e.g. a 22.05 hydra, I would assume it uses the same nix for evaluation as a regular NixOS 22.05

[NickCao]

@Mindavi Why was the pin moved from v2.8 to v2.6? I would even argue to remove the pin, if I run e.g. a 22.05 hydra, I would assume it uses the same nix for evaluation as a regular NixOS 22.05

It's now back on 2.8 actually.

[Mindavi]

Because nix doesn't have a stable enough API yet, so building against latest nix occasionally fails. I prefer hydra not failing to build whever nix is bumped.

It's indeed on 2.8 now.

Feel free to locally override, with the sidenote that it'll inevitably fail to build one day.

[FlorianFranzen]

Because nix doesn't have a stable enough API yet, so building against latest nix occasionally fails. I prefer hydra not failing to build whever nix is bumped.

I think hydra is important enough to be updated in parallel to nix, so not pinning it would make sure of that.

It's indeed on 2.8 now.

Right, I just realized the fix just has not hit unstable yet.

Feel free to locally override, with the sidenote that it'll inevitably fail to build one day.

We should not force people to build their own hydra just to have consistent nix behavior out of the box. So alternatively, to make the current scheme work, maybe we could passthru nix in the hydra expression, so that information is more easily accessible.

[lheckemann]

I think hydra is important enough to be updated in parallel to nix, so not pinning it would make sure of that.

No, Hydra's development is generally based on an old version of Nix because Nix's development disregards Hydra. Hydra upstream pinned Nix 2.4 until recently. And the Hydra packaging in Nixpkgs is even less important than Hydra itself (hydra.nixos.org runs on Hydra master via flakes). :(

[FlorianFranzen]

Hmm, ok. It would at least be nice to make that pin easily available then, so I proposed to add it to the passthru in #175452.