kdeApplications: Use latest qt515 by default #101369
Conversation
doronbehar
force-pushed
the
pkg/kdeApplications/qt515
branch
from
e0d667b
to
ed82afe
Compare
doronbehar
force-pushed
the
pkg/kdeApplications/qt515
branch
from
ed82afe
to
ead227d
Compare
|
The list above was filtered from the original ofborg eval gist with: |
doronbehar
force-pushed
the
pkg/kdeApplications/qt515
branch
2 times, most recently
from
80d8558
to
2de9cf7
Compare
Make sure only compatible qt versions are used for it (NixOS#101369) - kdeFrameworks is always using `libsForQt5` where e.g `libsForQt514.kpmcore` would have otherwise used a kio compiled with qt515.
Part of NixOS#101369: In order to avoid packages using the default `kdesu` always built with qt515, we put it in scope only for packages defined with a `libsForQt5`, to avoid incompatible qt versions used together in inputs of a package.
|
All of the above now don't use mixed qt versions. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/456-potentially-broken-qt-applications-libraries-need-your-help/9609/1 |
|
From kile, I get:
I wonder if it means it's broken or it's just because I don't use kde. cc @piegamesde . |
Use fetchFromGitLab as it seems to be unavailable in the previous url.
|
Just a note for myself. The following is the KDE Plasma release schedule https://community.kde.org/Schedules/Plasma_5#Support_status_by_Release_Series. We currently have:
|
|
@doronbehar the kdeconnect revert got removed edit: nevermind, it got moved as it should |
|
My system is running on this PR now without issues. |
|
Backport PR #102347 |
Backport of the PR NixOS#101369. All commits have been squashed, and other minor changes were made as well to align the state of 20.09 with that of master.
|
Looking at it again, I think we may have gone too far regarding using aliases here. The applications should still be available from |
I disagree. The issue is also explained in the commit message of b5c6505 - many attributes in I guess we (I) could have filtered out what was aliased and what was inherited by inspecting each attribute in |
|
Hm, this breaks building systems with |
|
Nice those undocumented options to Nixpkgs. Aside from documenting this option, we should also pass it as false in |
|
At first glance this looks to me as backported successfully in #102347. |
erictapen
added
8.has: port to stable
Motivation for this change
Fix #100707 , Fix #102167 , Fix #100854 , Fix #98268. (cc @ttuegel ).
Things done
In order to do that, before building, one can verify whether incompatible versions are used using the following steps:
dep-ver-consistent.nix.$pkgsubstituted for the attribute path you want to test:You can use
1or2or any other number instead of4in the command above to adjust the depth for which inputs of inputs will be checked. The command will printtrueif no issues are found, andfalse+ a trace, if there _are _ incompatible qt versions used.Given a list of attributes in a file you can iterate them all with:
I think all of affected packages now have no mismatched versions used together, up to depth 4. Upcoming ofborg evals may tell differently.
Here's the current list of affected packages,
kdeFrameworks.andkdeApplications.prefixes were cut in favor of maintaining uniqueness.sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)