qt6.wrapQtAppsHook: add qtbase and qtwayland to propagatedBuildInputs

[wineee]

qtwayland client side is the wayland platform plugin, provides a way to run Qt applications as Wayland clients

without this, Qt applications only work on x11/xwayland

wrap-qt5-apps-hook has make qtwayland propaged

nixpkgs/pkgs/development/libraries/qt-5/5.15/default.nix

Lines 354 to 358 in b206336

	wrapQtAppsHook = callPackage ({ makeBinaryWrapper, qtbase, qtwayland }: makeSetupHook {
	name = "wrap-qt5-apps-hook";
	propagatedBuildInputs = [ qtbase.dev makeBinaryWrapper ]
	++ lib.optional stdenv.isLinux qtwayland.dev;
	} ../hooks/wrap-qt-apps-hook.sh) { };

Description of changes

cc @NixOS/qt-kde

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/)
• 23.11 Release Notes (or backporting 23.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.

Priorities

Add a 👍 reaction to pull requests you find important.

[wineee]

Maybe need more adjusted #264964

[NickCao]

This was intentionally removed to reduce the closure size of cli only qt programs, but in the long run it looked like a bad idea. Maybe we can have a wrapQtClisHook for that particular usecase?

[puetzk]

Hmm. If the push is closure size, CLI-only programs (QCoreApplication) shouldn't need xcb plugin either. So the real prize (in terms of shrinking closure) would be to split QtCore away from QtGui/QtWidgets in a muliple-output package, and send, and make QtGui the piece that carries all the QPA/QRhi plugins. Or there's the "the "plugins/platforms/libqminimal.so" qpa plugin for things that link to QtGui but don't actually display anything.

[wineee]

1. Not tested on darwin (I don't have the device)
2. Should move libs to depsTargetTargetPropagated(but the qt5 patch is still marked as draft, @Artturin Are there still obstacles to doing this?)
3. qt5.wrapQtAppsHook always propagate qtwayland in linux，maybe we should add qt5.wrapQtClisHook

[Aleksanaa]

3. qt5.wrapQtAppsHook always propagate qtwayland in linux，maybe we should add `qt5.wrapQtClisHook`

This should not matter, because it just happens that there is no qtwayland in qtbase, but logically there should be.

[K900]

I think we can leave Qt5 as is at this point, it'll just go away after a while. I'll look at the rest of the change in a bit.

[drupol]

It looks like you accidentally mass-pinged a bunch of people, which are now subscribed
and getting notifications for everything in this pull request. Unfortunately, they
cannot be automatically unsubscribed from the issue (removing review request does not
unsubscribe), therefore development cannot continue in this pull request anymore.

Please create a new pull request, link back to this one and ping the
people actually involved in here over there. For the next time, remember to set your PR to draft status before rebasing. In draft status, you can preview the list of maintainers that are about to be requested for review, which allows you to sidestep this issue.

In order to avoid this in the future, there are instructions for how to properly
rebase between branches in our contribution guidelines.
Setting your pull request to draft prior to rebasing is strongly recommended.
In draft status, you can preview the list of people that are about to be requested
for review, which allows you to sidestep this issue.
This is not a bulletproof method, though, as OfBorg still does review requests even on draft PRs.