treewide: unpin protobuf_21 where possible

[alyssais]

Description of changes

Motivation: protobuf_21 doesn't build with musl 1.2.5. (See #229439.)

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.

[K900]

Marble should be OK, Python needs some care to ensure there's no random protobuf version conflicts when you use any two ML packages, no opinion on the rest.

[alyssais]

Python needs some care to ensure there's no random protobuf version conflicts when you use any two ML packages

Even though we're still using the same version of the Python protobuf library, and just changing the C++ one?

[SuperSandro2000]

The matching protobuf version should be taken from passthru https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules/protobuf/4.nix#L119

[alyssais]

Ah thanks! How does that look?

[K900]

Python needs some care to ensure there's no random protobuf version conflicts when you use any two ML packages

Even though we're still using the same version of the Python protobuf library, and just changing the C++ one?

I remember it exploding somehow for some weird reason.

[alyssais]

@SuperSandro2000 do you know what I'm supposed to do now that python3Packages.protobuf is protobuf 5 in staging, which does not have a protobuf passthru attribute?

[SuperSandro2000]

Mhhh, we no longer build it directly from protobuf and just use the pypi download. So I would just use pkgs.protobuf and test if that works.

[alyssais]

So just go back to what I was doing before?

[SuperSandro2000]

Yeah, probably 😅 sorry about the back and forth. Didn't think about that change.

[alyssais]

no worries

[alyssais]

Seems like python3Packages.onnx is broken on staging by the protobuf upgrade anyway, so I'll fix it there first and then we can come back to this.

[alyssais]

I've just dropped the python3Packages.onnx change from this PR, so it doesn't have to hold the rest back. It seems like it will be some time before it can be fixed on staging, due to #340252 (comment).

[SuperSandro2000]

LGTM but I am not super confident that there are not more regressions. Someone else please decide if we just want to send it to master and see how it goes.