build, qt: Add Wayland support for Linux builds with depends#22708
build, qt: Add Wayland support for Linux builds with depends#22708hebasto wants to merge 5 commits intobitcoin:masterfrom
Conversation
hebasto
force-pushed
the
210815-wayland
branch
3 times, most recently
from
5aa6bc7 to
d233a7c
Compare
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
hebasto
force-pushed
the
210815-wayland
branch
from
d233a7c to
30bee59
Compare
|
Concept ACK. Thanks for working on this.
Speaking of which, does this add any |
hebasto
force-pushed
the
210815-wayland
branch
2 times, most recently
from
1fe7d4e to
2ad38d8
Compare
Yes it does. This change in it's current state adds the following runtime dependencies to qt/bitcoin-qt: NEEDED library libwayland-egl.so.1 is not allowed
qt/bitcoin-qt: NEEDED library libGLESv2.so.2 is not allowed
qt/bitcoin-qt: NEEDED library libwayland-cursor.so.0 is not allowed
qt/bitcoin-qt: NEEDED library libwayland-client.so.0 is not allowed
qt/bitcoin-qt: NEEDED library libEGL.so.1 is not allowed |
|
@MarcoFalke Guix builds for the current state of this PR seem useless, so the "DrahtBot Guix build requested" label could be dropped. |
…anged f52a72a ci: Invalidate depends caches when sources have been changed (Hennadii Stepanov) 939640f ci: Reorder scripts to make git available before depends_sources_cache (Hennadii Stepanov) Pull request description: On master (502d22c) the Cirrus CI do _not_ invalidate depends caches when their sources has been changed, i.e. source version updates, a new dependency etc. This behavior causes: - breaking CI build for Android APK (see #22708) - the cache sizes growing It is assumed that caches could be invalidated via Cirrus CI API/GUI, but it is inconvenient and it does not work as expected in all cases. The common part of `fingerprint_key`s for both `depends_sources_cache` and `depends_built_cache` is the recent commit that changes sources in the `src/depends` sub-directory. For `depends_built_cache` additionally `CIRRUS_TASK_NAME` is used to avoid sharing of the same cache between tasks with different OSes and different `DEP_OPTS`. --- The `depends_sources` cache: - in master (502d22c)  - with this PR  ACKs for top commit: MarcoFalke: cr ACK f52a72a Zero-1729: crACK f52a72a Tree-SHA512: 0d14814ff308317c7c18cc725cf69055139030c207200af003872068f5567bd4b9c1f6783845d11742e314ebcc1dc5cae16aa86475376b623d921af5fcda14dd
hebasto
force-pushed
the
210815-wayland
branch
from
2ad38d8 to
ec94b62
Compare
|
Rebased 2ad38d8 -> ec94b62 (pr22708.06 -> pr22708.07) due to the conflict with #22710. |
hebasto
force-pushed
the
210815-wayland
branch
from
ec94b62 to
2b4c1ca
Compare
|
Rebased ec94b62 -> 2b4c1ca (pr22708.07 -> pr22708.08) due to the conflict with #22418. |
Maybe we want that for ARM/AArch64 builds? |
|
Rebased bc0411a -> 8ffd5ca (pr22708.23 -> pr22708.24) due to the conflict with #24668. PR description has been updated. |
Guix builds on
|
Guix builds on
|
|
It would be great if the changes were a bit more comprehensively explained. The PR adds a number of new dependencies (host and native) to depends, but doesn't mention:
It's unfortunate that from the get-go we're already an older version one package, because of a want to avoid meson. What is the effect of that? Is there a plan for solving this longer term, i.e just using the meson versions, or are we going to stay pinned to this older version forever?
|
I've updated the PR description with the new dependencies details. |
|
Updated 8ffd5ca -> 46cfa61 (pr22708.24 -> pr22708.25):
|
The former. It can run on Wayland desktops which do not support native X11 applications (tbh, I'm not aware of any such system).
A backend automatically depends on the
The runtime dependencies required to run I guess that Wayland-aware desktops already have this package been installed.
Hardly. There are no related CVEs so far.
I've looked through |
If you're loading more libraries at runtime your attack surface is increased.
I'm asking about Wayland support in general. Does it make a difference / would it be easier if we only supported it for Qt 6 onwards. |
|
Updated 46cfa61 -> df5d7ae (pr22708.25 -> pr22708.26):
|
Reverted back as the |
|
Updated 46cfa61 -> 95bc748 (pr22708.25 -> pr22708.27):
|
Guix builds on
|
|
Concept ~0. Without some sort of plan / outline for what we are doing with Qt going forward, I'm not convinced this should be merged. For many years we've been trying to reduce the number of dependencies we need to manage, and the scope of features/things that need to be maintained in this repository, and this change moves us in the opposite direction. Not only are we now supposedly going to return to supporting two major versions of Qt simultaneously (the benefit of which is not clear given basically all system packages of Qt 6 are currently unusable in our build system), but at the same time, this change introduces a second Linux graphics backend to support, along with more packages in depends, new runtime dependencies, and the scope for adding even more drivers/features in the future. If there was some overwhelming demand for us to support it (which I don't see, and the majority of people who care about this are likely already self-compiling), and a plan to migrate towards say just supporting qt6+wayland, then this may be more interesting. |
Even reducing new packages in |
|
This PR might be reconsidered along with #29914. |
|
Also: bitcoin-core/gui#916. |
7 participants
This PR adds the QtWayland module into the
qtpackage in depends.This change allows to build release binaries for Linux systems that can run natively—as a Wayland client—on modern desktops with Wayland compositors.
Closes #19950.
The diff for Qt "Configure summary" in depends:
Here is an excerpt from the log on Ubuntu 22.04 + GNOME:
Please note that for the simplicity sake Wayland 1.19.0 has been used as in Wayland 1.20.0:
Notes about new runtime dependencies
Wayland compositor infrastructure:
Vendor neutral GL dispatch libraries:
https://ubuntu.com/security/cves and https://security-tracker.debian.org/tracker/ have no records about the packages mentioned above.
More details:
qtwayland/README