# PLEASE fix ALL packages which were broken by the Qt-wrapping-changes
**URL:** https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444
**Category:** Development
**Created:** [March 27, 2020, 1:15pm UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444 "2020-03-27T13:15:04Z")
**Posts on this page:** 9
**Page:** 2
### Author:  [@Ekleog](https://discourse.nixos.org/u/Ekleog)
#### Post date: [March 30, 2020, 9:35pm UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/21 "2020-03-30T21:35:31Z")
Saying that we need to run nixpkgs-review all the time is, in my
opinion, a mistake. We have to either make that automatic, or not
require it, or it will be forgotten. (Also, we should provide an
interactive script somewhere that just does all the things that the PR
template requires.)
Making it automatic on the developer’s laptop is not reasonable, due to
the mass-rebuilds that can occur, and for which another process would be
required.
But we already have a set of machines that does these mass-rebuilds, and
it has a feature to automatically ping the maintainers of packages that
are newly broken: hydra.
Does anyone remember why the automatic emails have been disabled, and
why they haven’t been reenabled since? There has been one spam incident
once where hydra started to send thousands of emails to everyone, but as
far as I know that was the exception and not the rule, and it brought
more advantages than disadvantages overall – I’m pretty sure just
reenabling it would help a lot to keep nixpkgs not-broken.
---
### Author:  [@jtojnar](https://discourse.nixos.org/u/jtojnar)
#### Post date: [March 30, 2020, 9:47pm UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/22 "2020-03-30T21:47:37Z")
Reverting is fine when there is large amount of breakage but in reality it is often not so black and white. Large fraction of breakages I encounter is breakage of a few leaf packages – it is sad that it broke some packages but reverting the breaking change would be actually a change for worse.
The Qt breakage is actually one such example. Before the introduction of wrappers, **every Qt package was broken**. If people were lucky and had homogenous environment, it worked for them, but I marked several issues as duplicate every week:
- [many qt apps crash on launch?? · Issue #36173 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/issues/36173)
- [Qt libraries shouldn't end up in system-path · Issue #15498 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/issues/15498)
- [qt5 impurities break some apps, reporting symbol lookup errors · Issue #17448 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/issues/17448)
- [lxqt.qterminal segfaults after qt 5.10.1 update · Issue #36160 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/issues/36160)
- [QT version mismatch error · Issue #37864 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/issues/37864)
- …
The solution Thomas chose was to make the breakage explicit and give maintainers a way to finally fix the long standing issue. We cannot blame him for not having enough time to also fix the world.
---
### Author:  [@worldofpeace](https://discourse.nixos.org/u/worldofpeace)
#### Post date: [March 30, 2020, 10:43pm UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/23 "2020-03-30T22:43:03Z")
I believe this would be a good process if NixOS had a hybrid structure, where nixos-unstable became an actual rolling distro. Which I feel might be strenuous on the structure of a mono-repo (how should that even look like exactly? more branches can turn into more work). I’m not sure how I feel about keeping nixos-unstable in such a primed state and calling it “unstable”.
I do agree that the “one defined moment” of zero hydra failure initiative isn’t working as good, but I believe that is because nixos-unstable moves so fast and your package failing to build has no notification. The people that are aware of these things quickly are using nixos-unstable and tracking development delicately.
---
### Author:  [@jonringer](https://discourse.nixos.org/u/jonringer)
#### Post date: [March 31, 2020, 7:36pm UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/24 "2020-03-31T19:36:16Z")
And in the case of the Qt applications, the build would still be successful, it’s only when running the application would you see the error.
---
### Author:  [@timokau](https://discourse.nixos.org/u/timokau)
#### Post date: [March 31, 2020, 9:00pm UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/25 "2020-03-31T21:00:35Z")
> [@Ekleog](#):
>
> Saying that we need to run nixpkgs-review all the time is, in my
> opinion, a mistake. We have to either make that automatic, or not
> require it, or it will be forgotten. (Also, we should provide an
> interactive script somewhere that just does all the things that the PR
> template requires.)
I disagree. Automating it would be much nicer, but I don’t think its a requirement. There’s a checkbox. There’s not really an excuse to forget it and accidentally check the box. And if it does happen every once in a while, there’s the revert option. It doesn’t have to work perfectly to be an improvement.
> [@Ekleog](#):
>
> Making it automatic on the developer’s laptop is not reasonable, due to
> the mass-rebuilds that can occur, and for which another process would be
> required.
Yes, in that case there’s staging.
> [@Ekleog](#):
>
> But we already have a set of machines that does these mass-rebuilds, and
> it has a feature to automatically ping the maintainers of packages that
> are newly broken: hydra.
I agree that we should have hydra notifications ([Re-enable email notifications · Issue #51 · NixOS/infra · GitHub](https://github.com/NixOS/nixos-org-configurations/issues/51)). But those should be a last line of defense. Fixing my packages after they were broken on master is like putting out a fire. It’s stressful for me and annoying for the users. Fixing them with a week’s notice and additional context is much nicer.
> [@jtojnar](#):
>
> Reverting is fine when there is large amount of breakage but in reality it is often not so black and white. Large fraction of breakages I encounter is breakage of a few leaf packages – it is sad that it broke some packages but reverting the breaking change would be actually a change for worse.
I’m not saying we should block indefinitely because of leaf packages, just let it sit for a week. The status quo has been working until know, it will work for a couple more days. Of course there will be special cases, and maybe the QT thing was such a special case (I don’t have much context), but this still applies to most cases.
> [@jtojnar](#):
>
> The solution Thomas chose was to make the breakage explicit and give maintainers a way to finally fix the long standing issue. We cannot blame him for not having enough time to also fix the world.
My suggestion would not require him to fix the world. It clearly defines who has which responsibilities, and _where those responsibilities end_. The author of a PR has to
- make the change
- evaluate its impact
- notify impacted maintainers
He does _not_ have to fix everything.
> [@worldofpeace](#):
>
> I believe this would be a good process if NixOS had a hybrid structure, where nixos-unstable became an actual rolling distro. Which I feel might be strenuous on the structure of a mono-repo (how should that even look like exactly? more branches can turn into more work). I’m not sure how I feel about keeping nixos-unstable in such a primed state and calling it “unstable”.
I already use `nixos-unstable` as a rolling distro and I think a lot of people do. I’m not sure what you mean by more strenuous or why more branches would be needed. I don’t think the name is much of an argument 😉
> [@jonringer](#):
>
> And in the case of the Qt applications, the build would still be successful, it’s only when running the application would you see the error.
Yes, in that case someone would notice the runtime breakage. They’d then revert bisect the issue, revert the change and ping the author. They can then come up with a build-time test (as was done for the QT change) and ping maintainers.
---
### Author:  [@zimbatm](https://discourse.nixos.org/u/zimbatm)
#### Post date: [April 1, 2020, 8:48am UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/26 "2020-04-01T08:48:51Z")
OT: It’s so nice that one grumpy message from @rkoe, after some rocky start, turned into a real discussion. In a lot of other communities this thread could have become a flame war 🙂
---
### Author:  [@Mapybara](https://discourse.nixos.org/u/Mapybara)
#### Post date: [April 1, 2020, 9:36am UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/27 "2020-04-01T09:36:32Z")
> [@zimbatm](#):
>
> In a lot of other communities this thread could have become a flame war
It’s not too late. 🙂
---
### Author:  [@b42](https://discourse.nixos.org/u/b42)
#### Post date: [April 7, 2020, 10:34pm UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/28 "2020-04-07T22:34:38Z")
Tried to semi-automatically fix some low-hanging fruit, please take a look if you have spare capacity for code review:
>
>
> This attempts to fix several Qt applications that crash on startup with:
> \`\`\`
> q…t.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
> This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
> \`\`\`
> A \[crude script\](https://gist.github.com/mmilata/9eeb216d01a560b9c98cebf5e9eb34fb) was used to find packages that:
> \* are called with \`libsForQt5.callPackage\` from \`top-level/all-packages.nix\`, and
> \* use \`stdenv.mkDerivation\`, but
> \* are not marked as \`broken\` nor do they refer to \`wrapQtAppsHook\`, and
> \* have binaries that crash with the message above.
>
> This was followed with manual steps:
> \* Modify package file to use \`mkDerivation\` from argument list instead of \`stdenv\`, and
> \* build the package and check that some sort of window appears.
>
> \###### Motivation for this change
>
> \#65399
>
> \###### Things done
>
>
>
> \- \[x\] Tested using sandboxing (\[nix.useSandbox\](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option \`sandbox\` in \[\`nix.conf\`\](http://nixos.org/nix/manual/#sec-conf-file) on non-NixOS linux)
> \- Built on platform(s)
> - \[x\] NixOS
> - \[\] macOS
> - \[\] other Linux distributions
> \- \[\] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside \[nixos/tests\](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
> \- \[x\] Tested compilation of all pkgs that depend on this change using \`nix-shell -p nixpkgs-review --run "nixpkgs-review wip"\`
> \- \[x\] Tested execution of all binary files (usually in \`./result/bin/\`)
> \- \[\] Ensured that relevant documentation is up to date
> \- \[\] Determined the impact on package closure size (by running \`nix path-info -S\` before and after)
> \- \[x\] Fits \[CONTRIBUTING.md\](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
>
> \----
>
> Result of \`nixpkgs-review pr 84673\` \[1\](https://github.com/Mic92/nixpkgs-review)
> \
> \3 package marked as broken and skipped:\
>
> - bonfire
> - swiften
> - swiftformat
> \
> \
> \34 package built:\
>
> - aqemu
> - awesomebump
> - bibletime
> - bomi
> - calaos\_installer
> - candle
> - caneda
> - colord-kde
> - dfasma
> - enyo-doom
> - firebird-emu
> - glogg
> - httraqt
> - iannix
> - ipe
> - kdeApplications.okteta
> - luckybackup
> - mindforger
> - mpc-qt
> - openbrf
> - phototonic
> - pro-office-calculator
> - qcomicbook
> - qmediathekview
> - qstopmotion
> - qt-box-editor
> - ricochet
> - rocket
> - swift-im
> - tensor
> - traverso
> - valentina
> - write\_stylus
> - yabause
> \
---
### Author:  [@rkoe](https://discourse.nixos.org/u/rkoe)
#### Post date: [April 24, 2020, 10:03am UTC](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/29 "2020-04-24T10:03:07Z")
First of all: Sorry for the wording – I was quite frustrated, then. I do not want to insult, annoy or displease anyone, and I do not want to devalue others work. **Sorry for that.**
I really love the technical concepts of NixOS and I’m thankful for the work many people are putting into it. **Thanks for that.**
The QA-problems nevertheless still exist (and I’ve experienced it again with the recent 20.03 upgrade). I’m really interested in a solution here and am willing to help.
Unfortunately, I did not have time recently to think more about this, but now I’ll soon try to offer a concept for discussion how to solve these issues.
[Previous page](https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444.md?page=1)