qt5.qtbase: fix cross

[ghost]

Description of changes

This commit fixes builds of pkgsCross.*.qt5.qtbase by adding the buildPlatform compiler to depsBuildBuild. The qtbase build machinery expects to find it in the $PATH in unprefixed form.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.05 Release Notes (or backporting 22.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.

[Mindavi]

Should go to staging

[ghost]

@OPNA2608 let me know what you think of the latest push.

[OPNA2608]

And I feel like the modifying of that config file really belongs into postPatch more than preConfigure.

[OPNA2608]

Sorry to nit, but the title of the last commit doesn't match the commit conventions. Prolly fine to just squash it into the preceding one.

[ghost]

So apparently during the ~four months it took for this to be reviewed, somebody went and simply started deleting qt5 support from a bunch of packages. And now they're claiming those deletions can't be reverted because it might cause some users' browser cookies to be deleted after they are warned and given an opportunity to not delete their cookies.

This is incredibly demoralizing.

I think nixpkgs has a real organizational/cultural problem; the swarms of drive-by version-bump committers massively outnumber the people willing to put in long sustained effort on the hard underlying plumbing of nixpkgs. The latter have PRs that take way longer to review, with far fewer qualified reviewers, and they have to suffer way more merge conflicts in the meantime.

At some point we're going to lose the plumbers. And all that will be left will be the yolo-version-bump committers. That's not going to be a healthy software distribution.

[dotlambda]

Here are my deleted comments:

Shouldn't this have gone to staging?

And now they're claiming those deletions can't be reverted because it might cause some users' browser cookies to be deleted after they are warned and given an opportunity to not delete their cookies.

False. A revert should be discussed before it's done, that's all.

[samueldr]

@amjoseph-nixpkgs can you explain why or how comments ended-up being deleted here?

[ghost]

Sorry, I should have marked them off-topic, which they are.

[samueldr]

No.

[samueldr]

This should have gone to staging.

This is not the appropriate behaviour here.

You can't just decide to flip up the game board when you're mad about how things are going in the game.

We have processes for development. Mass rebuilds cannot go in master. That's always been the case.

EDIT: note that you'd acknowledged that fact already.

[samueldr]

(Now, since I've been made aware of this PR... let's look into it...)

Is this an appropriate change? Mismatches in Qt will lead to severe issues down the line.

I suspect it's a cross-compilation idiosyncrasy here, but without a comment explaining it, I have no way to know for sure.

If a platform name ended-up breaking this check, the platform name should be added to the check.

[vcunat]

Another issue with this PR is that it breaks build of qtbase on x86_64-darwin – and you could've seen the error on ofBorg already. Hydra: https://hydra.nixos.org/build/232824447/nixlog/2/tail

[RaitoBezarius]

I will address this publicly.

So apparently during the ~four months it took for this to be reviewed, somebody went and simply started deleting qt5 support from a bunch of packages. And now they're claiming those deletions can't be reverted because it might cause some users' browser cookies to be deleted after they are warned and given an opportunity to not delete their cookies.

Pull request discovery or "who is working on that" discovery is a difficult problem and I acknowledge this is a very frustrating experience.

I am not a domain expert in those areas and I cannot judge for the claim on impossibility of revert the deletions, I know that browser profiles have a migration system, and they rarely expect to go in both directions. Therefore, the claim is at least realistic. As we err on the caution, and we act generally in favor of the largest numbers (yes, this sucks but more on that later.).

The call of reviving a new package set for qt5 or qt6 is a valid option and has been proposed, I know that in all of that frustration, I can understand people losing their cool and moving on actions.

This is incredibly demoralizing.

I am sorry that you feel like this, all I can say is that nixpkgs is an inherently frustrating project, we all work to reduce it in the long run by building better tools for contributors themselves, improving our CI, improving our tests, improving a lot of things, it's not a work that receives a lot of attention.

I would love to have nixpkgs be the perfect place for people having exotic setups on a daily basis but we are already struggling with tier 2 platforms, it's not realistic to push the burden on people regarding cross compilation yet.

All of this should be the best effort basis and engaging in good faith.

I think nixpkgs has a real organizational/cultural problem; the swarms of drive-by version-bump committers massively outnumber the people willing to put in long sustained effort on the hard underlying plumbing of nixpkgs. The latter have PRs that take way longer to review, with far fewer qualified reviewers, and they have to suffer way more merge conflicts in the meantime.

I would argue this is a labor resource problem rather than organizational/cultural, as you can see, nixpkgs is decentralized in their collaboration, you do not want to join the Matrix platform to coordinate with anyone and this is mostly fine except in moment of higher stress and nervousness that cannot be handled calmly by GitHub discussions.

People often spend time posting about their avenues, e.g. removing Qt 5, etc. They ask, re-ask, ask for reviews, etc., and the model works to a certain extent for a lot of contributors.

On many instances, I have seen / reviewed your work on the sole basis that I care about your work and I enjoy it.

Overall, I feel like you have a very special problem that is shared by everyone who is doing their collaboration without interacting on the RFC-mandated (which, for public record, is driving me completely mad on a daily basis.) collaboration platform. I conjure you: please solve this issue moving forward. If I am not wrong, I believe this is one of the biggest driver for your demoralization and inability to solve this type of incident in a polite way off-GitHub.

At some point we're going to lose the plumbers. And all that will be left will be the yolo-version-bump committers. That's not going to be a healthy software distribution.

We are surely going to lose the plumbers for some areas, but not everything. It's fine if nixpkgs does not improve its plumbers for a while, it's a shame though because you are doing awesome and talented work in cross compilation and GCC space.

But, as a release manager, I cannot stand up for someone who caused such an incident, as you know, this is not the first friction you created.

Just to be clear and correct me if I'm wrong:

• this PR was sent in reaction to the other PR on qutebrowser
• this PR caused breakage for Darwin as @vcunat mentions it: it could have been caught using OfBorg
• this PR caused mass rebuilds: build infra confirms it even though you disagreed or ignored
• in this PR, you removed comments you considered as off-topic: this is a dangerous abuse of privileges I believe is a total nogo from a nixpkgs committer
• in the other PR, you engaged into a confrontational revert which was reverted again: such situations should always be solved politely or at least escalated to an intermediate of authority of nixpkgs, e.g. GitHub organization owners, release managers, etc. In theory, maintainers of said packages should have the last say in conflict resolution except in presence of special cases: release management concerns, security team concerns, etc.
• As you know, nixpkgs is a public good and its resources are important, we cannot aim for perfect support for any platforms, cross is bound to be a non-concern from a lot of maintainers (which I also regret FWIW.) because it's unrealistic to expect from them to handle it. Therefore, your entitlement for supporting your usecases on a short notice is uncalled-for — I believe you have the skills to maintain patches on the top of your nixpkgs HEADs.

I am sorry if this sounds harsh, and I am willing to apologize for the insufficiencies of nixpkgs as I am probably responsible for not doing enough for this project. But I am not okay with antagonizing contributors, and we are not at the first instance of collaboration events charged with friction/confrontational remarks/etc. from your end.

I conjure you to change your ways.

We are all in the same boat, including the "yolo-version-bump committers" who I would urge you to find more respectful words to describe them because they are doing the hard work of testing for the tier1/tier2 platforms we do have and maintaining this software distribution up-to-date.

Once we get there, I cannot guarantee that collaboration will be frustrationless, the people doing the plumbing work always had it hard in nixpkgs and this is merciless work, but expectation-wise, we will definitely be able to make a dent and move the agenda forward and focus on more and more interesting stuff.

[zimbatm]

As a complement to Raito's response that makes good points,

I share Amjoseph's frustration; people who do large refactors are not well accompanied

The longer the PR is dragging along, the more people will participate in it, with potentially conflicting opinions. It feels like trying to move with more and more weights attached to the back. With no end in sight (insert dramatic tone)! And because we are spread thin, the quality of the reviews isn't always there either.

Potentially a better system would quickly identify and triage those PRs. Decide if fundamentally it's right, and if yes, assign a fixed review buddy who is in the same camp and helps move things along.