browsr: 1.19.0 -> 1.21.0, mupdf: 1.23.6 -> 1.24.8, python312Packages.pymupdf: 1.23.6 -> 1.24.8, python312Packages.textual-universal-directory: 1.1.0 -> 1.5.0

[greg-hellings]

Description of changes

A change in a previous PR lifted a Python 3.12 limitation on building browsr. The existing version then failed to build due to being out of date. This PR updates the rest of the dependency tree to build in Python 3.12 and to reflect their latest versions.

Closes #274882
Closes #290651

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.

[teto]

Looks fine. Considering the number of rebuild, this should probably target staging though

[phanirithvij]

what about #298783 #274882 #290651 etc. can they all be closed?

[greg-hellings]

what about #298783 #274882 #290651 etc. can they all be closed?

It looks like they would be able to be closed if this gets merged

[phanirithvij]

Could you update the target branch for the pr to staging from master?

[greg-hellings]

Could you update the target branch for the pr to staging from master?

Done

[SuperSandro2000]

Can you also pick f9eb925 (#298783)

Also there are some additional changes in b476b96 (#298783) and 4a3db5a (#298783) which I think are worthwhile to carry over to here

[thiagokokada]

Can you also pick f9eb925 (#298783)

Also there are some additional changes in b476b96 (#298783) and 4a3db5a (#298783) which I think are worthwhile to carry over to here

I went and merged this since while those changes are nice to have, they're not essential, and mupdf is broken for a long time in nixpkgs so it is better to fix it and improve the package later.

[dotlambda]

I went and merged this since while those changes are nice to have, they're not essential, and mupdf is broken for a long time in nixpkgs so it is better to fix it and improve the package later.

Then why were the other PRs closed??

[thiagokokada]

I went and merged this since while those changes are nice to have, they're not essential, and mupdf is broken for a long time in nixpkgs so it is better to fix it and improve the package later.

Then why were the other PRs closed??

Because the main thing that is the bump is done, the only changes are smaller ones that can be done targeting either master or staging.

I think at that point it will be better to just remake the PR since there are lots of conflicts.

[dotlambda]

I think at that point it will be better to just remake the PR since there are lots of conflicts.

They can be closed once that's done.
This is unacceptable.

[thiagokokada]

I think at that point it will be better to just remake the PR since there are lots of conflicts.

They can be closed once that's done. This is unacceptable.

Feel free to reopen the PRs if you think I did a mistake. I only closed them to help reduce the huge amount of PRs we have.

No need to feel attacked.

[SuperSandro2000]

and mupdf is broken for a long time in nixpkgs so it is better to fix it and improve the package later.

If it is broken for a longer time and there is no urgency, we can also take the extra day or two to take the improvements.

Also apparently this PR was so rushed, that we immediately got a regression in #334596

[dotlambda]

Also apparently this PR was so rushed, that we immediately got a regression in #334596

That's unrelated because this PR wasn't merged into master.

[thiagokokada]

Also apparently this PR was so rushed, that we immediately got a regression in #334596

Completely unrelated, this PR is targetting staging.

[thiagokokada]

If it is broken for a longer time and there is no urgency, we can also take the extra day or two to take the improvements.

It is my opinion that sometimes we focus too much in fixing things that doesn't really help anyone. For example, the meta.mainProgram change, it is fine, but it is something so trivial that can be done in a separate PR targetting master directly. No need to go through staging, and no need to be backported to this PR.

IMO, this kind ends up just discouraging newcomers that end up doing good work fixing difficult packages like this one. But I am not sure if this is the correct place to discuss this issue either, feel free to ask me in Matrix or something if you want to discuss this issue further.

[SuperSandro2000]

If the change is so trivial IMO creating another PR is just creating overhead for reviewers and mergers.

[thiagokokada]

If the change is so trivial IMO creating another PR is just creating overhead for reviewers and mergers.

I think the overhead is way higher for the ones opening a PR than the ones reviewing it. And at least for low impact changes, I don't think it matters too much. Now, getting packages fixed has a much higher impact, IMO.

But we can agree to disagree here, not sure if it makes sense to comment much more on this particular issue. If I don't forget I will open a PR later applying the meta.mainProgram changes.

[greg-hellings]

If the change is so trivial IMO creating another PR is just creating overhead for reviewers and mergers.

It also makes it an absolute PITB for someone who just wants to contribute a fix and isn't wanting to be nitpicked to death by drift in reviewer's preferences and optional fields since the package was first merged in. In this case, adding a mainProgram option would be trivial, but would require bouncing back through a git rebase that not every contributor would be comfortable with. The other two PRs linked make major changes to the mupdf package. If those changes are desired, they should be subject to a completely different process than just a quick build fix submission by someone who is not the package maintainer and who just needs the package to build in order to fix their own problem. I just wanted browsr to work, I didn't want to adopt mupdf. I just needed to fix mupdf in order to get there.

[vcunat]

FYI: 9b88d05