nc4nix: 0-unstable-2024-03-01 -> 0-unstable-2024-05-24; nextcloudPackages: update

[pyrox0]

Updates nc2nix to include a commit that generates SRI hashes instead of sha256 hashes for extensions.

Also updates the nextcloud2{8,9}Packages package sets, in order to have those new hashes. This causes no rebuilds of the derivations besides those that are updated.
Note that out-of-tree usages of fetchNextcloudApp will not throw an error with sha256, but this is one step towards being able to do that(per #325892)

Description of changes

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.

[onny]

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

1 package built:

• nc4nix

[onny]

This is great, thank you :)

[dotlambda]

This causes no rebuilds of the derivations besides those that are updated.

Quite the opposite. It causes everything to fail to build. How was this not even tested??

[alois31]

This causes no rebuilds of the derivations besides those that are updated.

Quite the opposite. It causes everything to fail to build. How was this not even tested??

Testing does not help for FODs when the thing with the specified hash (in this case, the zip file fetched by upstream nc4nix) is already in the store.

[dotlambda]

This causes no rebuilds of the derivations besides those that are updated.

Quite the opposite. It causes everything to fail to build. How was this not even tested??

Testing does not help for FODs when the thing with the specified hash (in this case, the zip file fetched by upstream nc4nix) is already in the store.

But it's not. The hashes aren't the same.

[alois31]

But it's not. The hashes aren't the same.

Upstream nc4nix uses fetchurl, which does not uncompress the file, while nixpkgs uses fetchzip, which does. So the hashes are going to be different, but you aren't going to notice that when you already had the zip file in the store because you used upstream nc4nix.

[dotlambda]

But it's not. The hashes aren't the same.

Upstream nc4nix uses fetchurl, which does not uncompress the file, while nixpkgs uses fetchzip, which does. So the hashes are going to be different, but you aren't going to notice that when you already had the zip file in the store because you used upstream nc4nix.

That doesn't excuse @onny merging this without testing.

[pyrox0]

I pushed an updated one that mimics fetchzip, please go to that. I apologize for not testing this more thoroughly, but what's done is done.

#326947