fix cross build for various python packages

[DavHau]

• python3Packages.contourpy: fix cross build
• python3Packages.home-assistant-chip-wheels: simplify dependency closure generation
• python3Packages.home-assistant-chip-wheels: fix cross build
• python3Packages.bcrypt: fix cross build

Apart from the cross fixes, this contains an optimization for the dependency closure computation in home-assistant-chip-wheels.

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[mweinelt]

Thank you!

• The changes to bcrypt look fine
• The changes to contourpy need work, they break the test suite and Python 3.13 support
• For the home-assistant-chip-wheels changes I'd like @symphorien to also take a look

All changes except for chip-wheels need to pass through staging, because they're too stronk.

[symphorien]

This regresses #355051

[symphorien]

I'm surprised you could cross compile chip at all. The list of python dependencies mixes build and runtime dependencies. Also TIL about genricClosure, thanks.

[DavHau]

This regresses #355051

Fixed

I'm surprised you could cross compile chip at all. The list of python dependencies mixes build and runtime dependencies. Also TIL about genricClosure, thanks.

Hm, not sure. At least it does build now. We can still push more fixes later in case it doesn't work in practice. I don't use matter as of now.

Another weird thing is, when evaluating chip for a cross system, it takes very long and uses around 50GB or ram. I had to enable zram in order to build it. I wonder if such performance impact is expected because of cross, or if this has to do with this manual dependency juggling going on here.
I was hoping introducing genericClosure would fix the performance here, but it only improved it a little bit.

[symphorien]

About the egregious memory use when cross building: I commented out all attributes of stdenv.mkDerivation except name and version and got the same issue, so the memory issue does not come from the computation you replaced by genericClosure.

[mweinelt]

The cause of the excessive memory usage for cross python is known, but I have no idea how to resolve this.
#338231 (comment)