c-blosc2: init at 2.13.2, python3Packages.blosc2: 2.3.2 -> 2.5.1

[risicle]

Description of changes

c-blosc2 package largely copied from c-blosc, however c-blosc2 is developed under a separate tree and has a different e.g. pkg-config name so probably warrants a separate package as it will likely diverge.

This allows us to switch python3Packages.blosc2 to use this system c-blosc2 instead of its own bundled version.

Also built pkgsStatic, pkgsMusl, pkgsCross.aarch64-multiplatform, pkgsi686Linux versions of c-blosc2.

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.

[risicle]

pkgs/by-name check is failing but I don't really want to separate this package from c-blosc.

(cc @infinisil )

[infinisil]

@risicle Yeah i wouldn't separate it in that way. Check out #285922 (comment) for my recommendation

[risicle]

Hmm neither of those really feel appropriate here.

Have you considered the ghetto option of simply making the checker ignore any attrnames ending in a digit?

[infinisil]

Hmm neither of those really feel appropriate here.

I'd expect this to work out just fine:

  inherit (callPackages ../development/libraries/c-biosc { })
    c-biosc c-biosc2;

Or is there a problem with this?

Have you considered the ghetto option of simply making the checker ignore any attrnames ending in a digit?

I have considered it, but it feels like a hack, which I'm really not fond of!

It's actually really interesting to have this restriction, because it highlights the problem of multiple package versions and encourages exploration of better solutions.

Even the above recommendation already has the benefit of being explicit about multiple attributes coming from the same source, which is a step in the right direction for future improvements.

[risicle]

Ok I've gone with that approach, but FWIW it also feels like a bit of a hack that doesn't serve much purpose but to placate the CI. And I'd much rather have a hacky CI than to fill nixpkgs with all these hacks that don't really add any value.

[Mindavi]

Sometimes adding a hack to CI is ok, but exempting packages with a number at the end is overly broad to me. So I think this is the right solution, for now. We can always reconsider later if we get tens or hundreds of packages like this.