chawan: 0-unstable-2025-04-18 -> 0-unstable-2025-05-25

[kachick]

This PR aims to fix the failing automatic updater: https://nixpkgs-update-logs.nix-community.org/chawan/2025-05-04.log

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.

[kachick]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 406717
Commit: 542dc8f4aeb49bc44566fd153db6bb35716fed1d

---

x86_64-linux

✅ 1 package built:

• chawan

---

aarch64-linux

✅ 1 package built:

• chawan

---

x86_64-darwin

✅ 1 package built:

• chawan

---

aarch64-darwin

✅ 1 package built:

• chawan

[kachick]

@jtbx Any thoughts or feedback on this PR?

[jtbx]

Yeah looks good thanks could you possibly squash the two commits?

[kachick]

Thank you for the review!

I believe it's better to keep the commits separate in this case. Doing so clarifies the specific timing when Brotli is required and makes it easier to revert the second commit if needed.

Of course, if there's a guiding principle that recommends squashing these commits, I'm happy to respect that. However, based on my understanding of patterns like those seen in #400934, this particular situation doesn't seem to fit the typical use case for squashed commits.

That said, since the documentation PR is still under discussion and not yet merged, I'm happy to follow the package maintainer's suggestion if you think squashing is indeed better for this pattern.

[jtbx]

Kenichi Kamiya writes:

Thank you for the review! I believe it's better to keep the commits separate in this case. Doing so clarifies the specific timing when Brotli is required and makes it easier to revert the second commit if needed.

Sweet, makes sense