protobuf_25: 25.2 -> 25.3

[GaetanLepage]

Description of changes

Changelog: https://github.com/protocolbuffers/protobuf/releases/tag/v25.3

cc @jonringer

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.

[GaetanLepage]

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

1 package built:

• protobuf_25

[GaetanLepage]

Result of nixpkgs-review pr 289224 run on aarch64-linux 1

1 package built:

• protobuf_25

[GaetanLepage]

Result of nixpkgs-review pr 289224 run on aarch64-darwin 1

1 package built:

• protobuf_25

[GaetanLepage]

Result of nixpkgs-review pr 289224 run on x86_64-darwin 1

1 package built:

• protobuf_25

[kirillrdy]

anyone can comment on CI errors?

[GaetanLepage]

anyone can comment on CI errors?

Yes, they are caused by python3Packages.protobuf not building with this version.
It was already the case with 25.2, hence not a regression.
I am working on a fix before updating the default protobuf to protobuf_25.

(See discussion in #264902)

[kirillrdy]

protobuf_25 and python3Packages.protobuf builds on master, where is the regression coming from ?

[GaetanLepage]

python3Packages.protobuf builds fine on master because it relies on the sources of pkgs.protobuf, which is protobuf_24.
What doesn't build is the python bindings of protobuf_25 (which cannot be directly built, you can however set protobuf = protobuf_25; in all-packages.nix).

[kirillrdy]

thank you for clarification, what is the merge plan for this ? merging this breaks protobuf_25.tests

[GaetanLepage]

thank you for clarification, what is the merge plan for this ? merging this breaks protobuf_25.tests

I would encourage a merge of this PR as it doesn't bring any regression.
protobuf_25.tests are also broken on master for the same reason (i.e. python3Packages.protobuf's tests fail).

[superherointj]

kirillrdy thanks for keeping a keen eye on this.

I agree with Gaetan that merging this does not break protobuf_25.tests. But also, doesn't fix protobuf_25.tests. It just upgrades the Go package. Which was my initial reasoning on this too. (I had been using protobuf in Go, but not Python.)

To show master is already broken:

So I think, merging this makes sense. As it only affects protobuf_25. And does not cause breakage of other things. And if Python part is fixed. It should be fixed for the new version. So it is an advancement still and desirable to have this PR merged.

[superherointj]

Maybe because we know that python test is specifically broken, we should mark it [the test, pythonProtobuf] broken for version 25?

[GaetanLepage]

Maybe because we know that python test is specifically broken, we should mark it broken?

The C++ library (pkgs.protobuf_25) itself is not broken. Also, the only version of the python bindings that exist in nixpkgs (i.e. python3Packages.protobuf) is built against the default protobuf (24.4 currently) and is not broken.
So no package is actually broken currently.

[superherointj]

I agree with you that protobuf_25 package is fine.

What is to be marked broken is the pythonProtobuf test, that is broken. Reference:

[superherointj]

If we don't mark it as broken, it is going to show as unhandled broken builds in CI/Hydra. Also causing unnecessary builds. So because it is broken, it is necessary to open an issue to track the fix at nixpkgs. Phew... I know. What a bureaucracy.

Sorry having to annoy you with these things.

Something like this could work:

But there may exist a better way to do this. [But I don't have a better suggestion yet.]

Missing from my code:

• Adding a comment to clarify issue.
  • And with reference of the tracking issue.
    • Which requires to open an issue to track breakage. (Which centralizes conversation of such solution.)

So, kirillrdy is right in his questioning. Because we were not handling the breakage. In fact, because master is broken for this test, whoever upgraded the package first should have marked it broken. Now we have to.

[GaetanLepage]

@superherointj I directly marked the python package as broken for protobuf newer than 25. Does that work for you ?
The test is automatically marked as broken for protobuf_25.

[superherointj]

@superherointj I directly marked the python package as broken for protobuf newer than 25. Does that work for you ? The test is automatically marked as broken for protobuf_25.

Yes. That is a much better idea indeed.

[superherointj]

Whenever marking a package broken it is usual to add a comment for:

• date
• error
• tracking issue

[GaetanLepage]

Whenever marking a package broken it is usual to add a comment for:

* date

* error

* tracking issue

Sure ! Done