hebasto
commented at 10:50 AM on April 17, 2026:
member
This PR isolates the GUI build, including its specific dependencies, into a dedicated container.
Benefits of this approach:
Improves security: Any unknown backdoors in GUI-specific dependencies will no longer affect bitcoind and other non-GUI binaries.
Enables a safer upgrade path: Allows for the introduction of additional GUI dependencies needed for Wayland support or transitioning to the QML-based GUI.
guix: Split manifest into build and codesign manifests690e587b7b
cmake: Move `USE_DBUS` to `bitcoinqt` target
This removes the `USE_DBUS` definition from `bitcoin-build-config.h`,
reducing the dependency of non-GUI code on GUI-specific definitions.
afcb4be937
cmake: Move `USE_QRCODE` to `bitcoinqt` target
This removes the `USE_QRCODE` definition from `bitcoin-build-config.h`,
reducing the dependency of non-GUI code on GUI-specific definitions.
Additionally, `QRencode::QRencode` is now linked only when wallet is
enabled, because the `qrencode.h` header is used exclusively in
wallet-specific code.
29d4d1ff96
guix: Split GUI dependencies into separate manifest037fce4eee
guix, depends: Omit `GUIX_ENVIRONMENT` from `gen_id` calculations
When using the Guix build/sign scripts from this repository, the Guix
environment and the `GUIX_ENVIRONMENT` variable within the container are
fully defined by the commit hash and the user-provided
`ADDITIONAL_GUIX_*_FLAGS`.
This change removes `GUIX_ENVIRONMENT` from the package ID calculations.
Doing so allows us to split manifests and reuse built depends packages
across containers that utilize these split manifests in subsequent
commits.
The potential impact of `ADDITIONAL_GUIX_*_FLAGS` is still accounted for
by passing them to the `gen_id` script via the `{BUILD,HOST}_ID_SALT`
variables.
0bb539dec3
hebasto added the label Build system on Apr 17, 2026
DrahtBot
commented at 10:51 AM on April 17, 2026:
contributor
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
See the guideline for information on the review process.
A summary of reviews will appear here.
<!--174a7506f384e20aa4161008e828411d-->
Conflicts
Reviewers, this pull request conflicts with the following ones:
#35131 (guix, refactor: Minor script cleanups and improvements by hebasto)
#35072 (cmake: Remove optional definitions from bitcoin-build-config.h by hebasto)
#34948 (guix: Split manifest into build and codesign manifests by hebasto)
#33974 (cmake: Check dependencies after build option interaction by hebasto)
#32764 (guix: Build for macOS using Clang only by hebasto)
#32162 (depends: Switch from multilib to platform-specific toolchains by hebasto)
#25573 (guix: produce a -static-pie bitcoind by fanquake)
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.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
DrahtBot added the label CI failed on Apr 17, 2026
DrahtBot
commented at 11:58 AM on April 17, 2026:
contributor
<!--85328a0da195eb286784d51f73fa0af9-->
🚧 At least one of the CI tasks failed.
<sub>Task lint: https://github.com/bitcoin/bitcoin/actions/runs/24561368833/job/71811492362</sub>
<sub>LLM reason (✨ experimental): CI failed because the shell lint check (lint-shell.py) reported a ShellCheck SC2206 word-splitting warning in contrib/guix/libexec/build.sh and treated it as an error.</sub>
<details><summary>Hints</summary>
Try to run the tests locally, according to the documentation. However, a CI failure may still
happen due to a number of reasons, for example:
Possibly due to a silent merge conflict (the changes in this pull request being
incompatible with the current code in the target branch). If so, make sure to rebase on the latest
commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the
affected test.
An intermittent issue.
Leave a comment here, if you need help tracking down a confusing failure.
</details>
guix: Build GUI sequentiallyc4730955ec
hebasto force-pushed on Apr 24, 2026
DrahtBot removed the label CI failed on Apr 24, 2026
hebasto
commented at 10:01 AM on April 27, 2026:
member
fanquake
commented at 12:39 PM on April 29, 2026:
member
or transitioning to the QML-based GUI.
Is that blocked on this change; I thought it just needed to be finished? (looking at https://github.com/bitcoin-core/gui-qml, it just has this repo as a subtree; I also can't see any new dependencies)
Im not sure yet, given the current approach of re-using the same build dir. We will want to compile / link the static binaries with different compilation / link flags.
hebasto
commented at 1:45 PM on April 29, 2026:
member
or transitioning to the QML-based GUI.
Is that blocked on this change; I thought it just needed to be finished? (looking at https://github.com/bitcoin-core/gui-qml, it just has this repo as a subtree; I also can't see any new dependencies)
The qt6 branch using this repo as a subtree is a shortcut taken during the migration from Qt 5 to Qt 6.
The transition to QML-based GUI will use a branch that is cleanly mergeable into the master branch in this repo (rebasing is currently in progress).
The new dependencies will look like the ones here.
Im not sure yet, given the current approach of re-using the same build dir. We will want to compile / link the static binaries with different compilation / link flags.
Dropped this from the PR description. However, it still seems unreasonable to keep GUI-specific stuff in a Guix prefix where static non-GUI binaries are being built.
fanquake
commented at 1:53 PM on April 29, 2026:
member
The new dependencies will look like the ones here.
Ok, so some additional Qt subcomponents? My point is that doing anything QML related in this repo, doesn't seem to be blocked on the changes here. It could be done today, by just enabling a few more components in Qt, without any other, new, non-Qt dependencies?
hebasto
commented at 2:08 PM on April 29, 2026:
member
The new dependencies will look like the ones here.
Ok, so some additional Qt subcomponents? My point is that doing anything QML related in this repo, doesn't seem to be blocked on the changes here. It could be done today, by just enabling a few more components in Qt, without any other, new, non-Qt dependencies?
I'm a bit confused. Are we making a distinction between additional Qt components and other non-Qt dependencies? If so, what is the difference between them from a security perspective?
This PR is not proposed solely for the transition to the QML-based GUI. Its primary purpose is to resolve #29914, which doesn't mention QML at all. As a byproduct, it also enables the transition to the QML GUI without having any effect on the security of the non-GUI release binaries.
fanquake
commented at 3:30 PM on April 29, 2026:
member
I'm a bit confused. Are we making a distinction between additional Qt components and other non-Qt dependencies? If so, what is the difference between them from a security perspective?
Yes. I think we could generally add new Qt submodules as-needed, given we are already using Qt. Any other new dependency should be evaluated on a case-by-case basis.
it also enables the transition to the QML GUI without having any effect on the security of the non-GUI release binaries.
I think this is my confusion. I don't think there are any security-related issues that would arise from moving to QML, today, if it only requires using a few more Qt modules; so am trying to clarify how this PR provides a "safer upgrade path".
fanquake
commented at 12:34 PM on May 20, 2026:
member
I've pushed an alternate approach into #25573 (if you want to leave approach feedback there), as the approach here wont work for static builds (we can't re-use depends / build artifacts across linux & linux GUI builds. My approach should be compatible with #34948, and wouldn't need changes like #35072.
DrahtBot added the label Needs rebase on May 26, 2026
DrahtBot
commented at 10:26 AM on May 26, 2026:
contributor
<!--cf906140f33d8803c4a75a2196329ecb-->
🐙 This pull request conflicts with the target branch and needs rebase.
hebasto
commented at 2:56 PM on May 28, 2026:
member
I've pushed an alternate approach into #25573 (if you want to leave approach feedback there), as the approach here wont work for static builds (we can't re-use depends / build artifacts across linux & linux GUI builds.
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2026-06-04 09:51 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me
