ci: build multiprocess on most jobs #30975

Sjors · 2024-09-26T10:29:38Z

This builds most of the CI jobs with multiprocess enabled.

Two jobs run the functional test suite, one with depends and one with the regular build.

The Windows job does not use multiprocess since that's not supported yet.

The previous version of this PR changed the depends system to build libmultiprocess by default as one of the final steps for #31098 - but based discussion here and on IRC it was decided it's too early to ship it. This now happens in the followup #31802.

Based on #31741

DrahtBot · 2024-09-26T10:29:43Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/30975.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	ryanofsky
Stale ACK	vasild

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#32162 (depends: Switch from multilib to platform-specific toolchains by hebasto)
#32054 (cmake, guix: Skip building tests in subtrees for releases by hebasto)
#31375 (multiprocess: Add bitcoin wrapper executable by ryanofsky)
#31282 (refactor: Make node_id a const& in RemoveBlockRequest by maflcko)
#30595 (kernel: Introduce initial C header API by TheCharlatan)
#28792 (Embed default ASMap as binary dump header file by fjahr)
#28710 (Remove the legacy wallet and BDB dependency by achow101)

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.

contrib/guix/libexec/build.sh

Sjors · 2024-09-26T10:34:34Z

I'll look into the linter once it's clear if the make MULTIPROCESS=0 behaviour above is intentional.

fanquake · 2024-09-26T11:22:08Z

If multiprocess is (currently) unsupported on Windows, then that should be fixed in depends, i.e (for now) don't even try building the packages/functionality for that platform, not leaked into Guix with a workaround.

More generally, if the project decides to start shipping multiprocess as part of it's releases, then there's a number of other things that need to happen first. We should be switching multiprocess from an opt-in in depends, to being built/used by default, as well as testing all of this, on all relevant platforms in our CIs, not just enabling it for some platforms as part of the release process.

There are also documentation/website/release process updates that will be needed, as this change is going to produce a release tarball, which will contain:

bitcoin-cli
bitcoin-gui
bitcoin-node
bitcoin-qt
bitcoin-tx
bitcoin-util
bitcoin-wallet
bitcoind
test_bitcoin

with no explanation of why there is bitcoind & bitcoin-node, as well as bitcoin-qt & bitcoin-gui, what the difference is betweem them, or which one someone should use. I'd think that even if we started doing multiprocess, we should still only be shipping a bitcoind and bitcoin-qt (which contain the functionality, not multiple different binaries).

and as a result add bitcoin-node, bitcoin-gui and bitcoin-wallet to the release binaries.

bitcoin-wallet already exists in the release binaries:

ls bitcoin-28.0rc2/bin 
bitcoin-cli
bitcoin-qt
bitcoin-tx
bitcoin-util
bitcoin-wallet
bitcoind
test_bitcoin

DrahtBot · 2024-09-26T11:43:45Z

🚧 At least one of the CI tasks failed.
_{Debug: https://github.com/bitcoin/bitcoin/runs/30698173359}

Hints

Make sure to run all tests locally, according to the documentation.

The failure may 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.

Sjors · 2024-09-26T12:23:25Z

I would also prefer it if bitcoind (and bitcoin-qt) had multiprocess built in. That way the instruction for miners is "Install Bitcoin Core as you always do, just add ipcbind=unix to you config". cc @ryanofsky

Another approach, if touching the bitcoind and bitcoin-qt binaries is something people are worried about doing too soon, is to move bitcoin-node and bitcoin-qt into an ipc folder. A document explaining all the different binaries would still be needed.

that should be fixed in depends, i.e (for now) don't even try building the packages/functionality for that platform, not leaked into Guix with a workaround.

I'll look into that.

there's a number of other things that need to happen first. We should be switching multiprocess from an opt-in in depends, to being built/used by default, as well as testing all of this, on all relevant platforms in our CIs, not just enabling it for some platforms as part of the release process.

I'll add some commits here to do these things. Those can be split into separate PRs later for a more incremental approach.

bitcoin-wallet already exists in the release binaries:

Ah, I either misremembered or things changed. But in #19460 it's not / no longer the plan to have bitcoin-node spawn a bitcoin-wallet process. Updated the description.

ryanofsky · 2024-09-26T12:37:29Z

It's good to have this PR open as a draft to see what it looks like but it sounds like there are a number of followups that need to happen for it to be ready. For my part, I need to fix the windows build and also open an issue listing different ways it would be possible to make releases including multiprocess support in short or long term. It would also be good to review and merge #30940 which this is currently based on.

Sjors · 2024-09-26T15:40:17Z

I moved the Windows build skip workaround from Guix to depends. This made me excited about the prospect of moving that bit of Autotools stuff to CMake as well. :-)

Made some minimal documentation changes.

I didn't change the non-depends build (yet).

All CI instances that use depends now use multiprocess, the others don't (yet). Let's see if that breaks anything...

maflcko · 2024-09-26T16:52:29Z

From CI:

SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/src/mp/proxy.cpp:146:25 in mp::Connection::addAsyncCleanup(std::__1::function<void ()>)

ryanofsky · 2024-09-26T19:46:39Z

For my part, I need to fix the windows build and also open an issue listing different ways it would be possible to make releases including multiprocess support in short or long term.

Update: currently working on getting mingw32 build working, and I created issue #30983 to lay out different multiprocess release options.

fanquake · 2024-09-27T09:26:54Z

ci_container_base/src/ipc/capnp/mining.cpp -DARENA_DEBUG -DDEBUG_LOCKORDER -DDEBUG_LOCKCONTENTION -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES 
In file included from /ci_container_base/src/ipc/capnp/mining.cpp:5:
In file included from /ci_container_base/src/ipc/capnp/mining-types.h:9:
In file included from /ci_container_base/ci/scratch/build-x86_64-pc-linux-gnu/src/ipc/capnp/common.capnp.proxy-types.h:6:
In file included from /ci_container_base/ci/scratch/build-x86_64-pc-linux-gnu/src/ipc/capnp/common.capnp.proxy.h:7:
In file included from /ci_container_base/depends/x86_64-pc-linux-gnu/include/mp/proxy.h:8:
/ci_container_base/depends/x86_64-pc-linux-gnu/include/mp/util.h:207:20: error: no template named 'function' in namespace 'std'; did you mean 'kj::Function'?
  207 | using FdToArgsFn = std::function<std::vector<std::string>(int fd)>;
      |                    ^~~~~
/ci_container_base/depends/x86_64-pc-linux-gnu/include/kj/exception.h:34:29: note: 'kj::Function' declared here
   34 | template <typename T> class Function;
      |                             ^
1 error generated.

TSAN compile failure fixed in bitcoin-core/libmultiprocess#113.

Sjors · 2024-09-27T11:00:34Z

Rebased after #30940

Sjors · 2024-10-01T07:50:04Z

Rebased after #30043.

TSAN compile failure fixed in chaincodelabs/libmultiprocess#113.

Added a commit to bump libmultiprocess to include this (can be its own PR later).

Sjors · 2024-10-01T11:01:43Z

MSAN says https://cirrus-ci.com/task/6248232848719872:

SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/src/mp/proxy.cpp:146:25 in mp::Connection::addAsyncCleanup(std::__1::function<void ()>)
[10:00:27.923] Exiting

ryanofsky · 2024-10-01T14:58:35Z

MSAN says https://cirrus-ci.com/task/6248232848719872

Thanks! I created bitcoin-core/libmultiprocess#115 with details about this, and I think I have a potential fix.

This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, several jobs fail due to the mptest executable not being built by default, as reported bitcoin#30975 (comment) Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>

This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, the "macOS 14 native no depends job" fails due to warnings in boost headers treated as errors, reported in bitcoin#30975 (comment) and bitcoin-core/libmultiprocess#138

This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, clang-tidy job fails due to missing generated example files as reported bitcoin#30975 (comment) Different fixes were suggested bitcoin#30975 (comment) and bitcoin#30975 (comment) Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>

This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, several jobs fail due to the mptest executable not being built by default, as reported bitcoin#30975 (comment) Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>

This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, the "macOS 14 native no depends job" fails due to warnings in boost headers treated as errors, reported in bitcoin#30975 (comment) and bitcoin-core/libmultiprocess#138

This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, clang-tidy job fails due to missing generated example files as reported bitcoin#30975 (comment) Different fixes were suggested bitcoin#30975 (comment) and bitcoin#30975 (comment) Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>

Sjors · 2025-04-04T13:36:20Z

(not rebasing yet, CI already ran on the latest base PR push)

vasild

ACK 369da6a

Except: 1. i686, DEBUG (changed to "no multiprocess") 2. Windows due to lack of support

Install capnp where needed. The bitcoin-node binary is built on all platforms which have multiprocess enabled, but for functional tests it's only used in the macOS native (no depends) and CentOS native (depends) jobs.

Sjors · 2025-04-11T17:28:01Z

Rebased after #31741 landed. Also adjusted after #32218.

maflcko

No, objection, but I wonder what the goal of the changes here is.

In the OP you mention that it is too early to enable it by default in depends, so to me it seems better to just have CI follow when this is turned on by default in depends.

However, in #31802 (comment) you claim that this will be turned on by default for devs as well.

It would seem like useless churn if most of the changes here would be reverted soon after anyway, which is why I am asking.

Sjors · 2025-04-11T18:18:13Z

@maflcko #31802 turns IPC on in the guix build and by default for devs. But even (especially?) if it's not turned on by default, it's good to have CI coverage.

too early to enable it by default in depends

This is because turning it on in depends turns it on in guix and ships it in the next release. That seems better to decide in the next PR.

this will be turned on by default for devs as well

I could do that here as well, but prefer to keep this PR limited to CI changes. Also it's a bit weird to turn it on for developers only if they don't use depends.

(in other words, the coupling between depends defaults and guix builds is a bit annoying)

ryanofsky · 2025-04-11T19:00:03Z

Code review ACK 747af17

I think I agree with marco, and it might be simpler to just close this PR and turn on ENABLE_IPC by default in ci, in depends, and in cmake all in a single PR instead of turning it on in CI first, which makes CI builds and default builds less consistent with each other and creates churn in the CI configuration files.

I can also see the other point of view that that a change to enable IPC in releases is a bigger decision than enabling IPC in CI and developer builds, so maybe that should have a dedicated PR.

I think my preference would depend on how soon we think #31802 should be merged. If pretty soon, the simplest thing would be to close this PR and just update cmake default, depends default, and CI all together in #31802. But if we want to wait more time before merging #31802, it would be helpful to have ENABLE_IPC turned on in CI earlier so there's better CI testing for other IPC/multiprocess PR's being worked on.

Sjors · 2025-04-11T19:31:26Z

I've marked #31802 as ready for review. It includes all the commits here. But I'll leave this open for now.

Sjors · 2025-04-11T22:01:44Z

Since I reordered the commits in #31802 it's now a non-trivial rebase, so I'm closing this.

This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, several jobs fail due to the mptest executable not being built by default, as reported bitcoin#30975 (comment) Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>

This change is technically not needed to add libmultiprocess as a subtree, but it avoids a CI failure in followup PR bitcoin#30975 which enables multiprocess build option in more CI jobs. In that PR, clang-tidy job fails due to missing generated example files as reported bitcoin#30975 (comment) Different fixes were suggested bitcoin#30975 (comment) and bitcoin#30975 (comment) Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>

ce7d94a doc: add release note (Sjors Provoost) 71f29d4 doc: update build and dependencies docs for IPC (Sjors Provoost) 3cbf747 cmake: set ENABLE_IPC by default (Sjors Provoost) 32a90e1 ci: use bitcoin-node for one depends job (Sjors Provoost) b333cc1 ci: build one depends job without multiprocess (Sjors Provoost) 16bce9a build: depends makes libmultiprocess by default (Sjors Provoost) Pull request description: Have depends make libmultiprocess by default. This PR causes the following behavior changes: 1. **bitcoin-node and bitcoin-gui binaries are included in releases**, due to `ENABLE_IPC` option being switched on by default in depends builds 2. `ENABLE_IPC` is also switched on by default in non-depends builds (instructions updated, #33190 does this as a standalone PR) 3. Various changes to CI: switching on `ENABLE_IPC` on in most configurations and using `bitcoin-node` binary (`bitcoin -m`) for functional tests in two of them. 4. The `bitcoin-node` and `bitcoin-gui` are added to `Maintenance.cmake` (since they're now in the release) This PR doesn't need to do all of these things at once. However it's is simpler, avoids code churn (especially in CI), and probably less confusing to make all these changes in the same PR. Windows is not supported yet, so `ENABLE_IPC` is off by default for it. It can be enabled after #32387. The initial main use case for IPC is to enable experimental support for the Mining IPC interface. A working example of a Stratum v2 Template Provider client using this interface can be found here: Sjors#48. See #31756 for discussion of when this should happen. Supersedes #30975. ## Wait what, why? The [Stratum v2 spec](https://stratumprotocol.org/specification) has been around for a few years now, mostly stable but with [ongoing activity](https://github.com/stratum-mining/sv2-spec/commits/main/) to clarify and fix more subtle issues encountered by implementers. Most of the implementation is built in Rust in a project called the Stratum Reference Implementation ([SRI](https://github.com/stratum-mining/stratum)). [Braiins](https://demand.work) added Stratum v2 support to both their (custom) firmware and pool several years ago, though they have fallen behind on recent spec changes (update: it seems they've fixed that). Apparently [new hardware is underway](#31802 (comment)) that supports Stratum v2 without the need for custom firmware. [DMND pool](https://www.dmnd.work) is Stratum v2 native from the start and employs several of the SRI developers (they haven't fully launched though). The industry is rather secretive, but apparently [there is more underway](#31802 (comment)). What does Bitcoin Core have to do with this? Well, in Stratum v2 jargon we are the Template Provider. Or at least, the Template Provider role needs us to make block templates. Initially back in 2023 the plan was to have Bitcoin Core implement this role entirely, see #23049. It would speak the sv2 encrypted message protocol. In fact the spec was designed around this assumption, making sure to only use cryptographic primitives already in our codebase. I took over that effort in late 2023, but during 2024 it became quite clear there was [strong resistance](#29432 (review)) to the idea of including all this new code, opening another network ports, etc. At the same time there was the long running multiprocess / IPC project #10102, and the idea was born to apply that here: instead of including Stratum v2 specific stuff, we offer a general Mining interface via an IPC connection that can e.g. push out fresh block templates as fees rise above a threshold (something not possible and/or very inefficient with `getblocktemplate`). A client sidecar application then sits between the Stratum v2 world and our node. Currently there's only one such sidecar application, maintained by me, and reusing the same codebase from the integrated approach. An attempt has been made to connect to our interface from Rust bitcoin-core/libmultiprocess#174, which would pave the way for SRI include the Template Provider role. Plebhash below indicates he's also working on that: #31802 (comment). So with this new approach in mind, between mid 2024 until spring 2025, I introduced a new Mining interface (#30200 - #31785). At the same time Russ Ryanosky worked on more tight integration of [libmultiprocess](https://github.com/bitcoin-core/libmultiprocess), including making it a subtree in #31741. See [design/multiprocess.md](https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md). Meanwhile I've been maintaining a fork of Bitcoin Core that includes the Template Provider, in the original integrated approach (Sjors#68) as well as an IPC + sidecar variant (Sjors#48). I've been shipping [regular releases](https://github.com/Sjors/bitcoin/releases), mostly after bug fixes or major rebases. The SRI team has been testing both variants, though the "official" [instruction on their web page](https://stratumprotocol.org/developers) is to stick to integrated version. Bug reports on [my repo fork](https://github.com/Sjors/bitcoin/issues?q=is%3Aissue) as well as on the [SRI repo](https://github.com/stratum-mining/stratum/issues?q=is%3Aissue%20%20label%3A%22template%20provider%22) are evidence of actual testing happening. But as Pavlenex writes below: > one recurring feedback I kept getting regardless of the size/type of miner is that the need to run a forked version of Bitcoin Core remains a significant barrier to adoption This PR gets rids of that significant barrier. People can download a "pristine" version of Bitcoin Core and the only change is to start it with `bitcoin node -m -ipcconnect=unix` instead of the usual `bitcoind`. Once that's released, I can dramatically simplify my sidecar codebase (Sjors#48) by removing pretty much all Bitcoin Core code that it doesn't need. My plan is to then make that a separate repository, which should be much easier to contribute to. I can then also make (deterministically built) signed releases, while making it clear that sidecar code has nothing to do with Bitcoin Core. Perhaps later on SRI implements the same and I can stop maintaining that project. Conceptually the situation will be a lot clearer; - today: download forked version of `bitcoind` (or a forked version of `bitcoin-node`, plus `bitcoin-mine`), install SRI stuff - tomorrow: download Bitcoin Core v30, install `bitcoin-mine` and SRI - future: download Bitcoin Core v30 and SRI <details> <summary> Guix hashes: </summary> ``` find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum 6dbf29baecb1d1593087ef1306ae7c78aa160c8beb04dc016e02549ae2d6d90d guix-build-ce7d94a492e6/output/aarch64-linux-gnu/SHA256SUMS.part 4b465e5e8f9652c176aa57cfe5c289267c28c3a3c684034a9ce471b529b95275 guix-build-ce7d94a492e6/output/aarch64-linux-gnu/bitcoin-ce7d94a492e6-aarch64-linux-gnu-debug.tar.gz 85bc6fa008b83419d96443d9dcc212b46f0992387fd58fd2dda5da76536ee22c guix-build-ce7d94a492e6/output/aarch64-linux-gnu/bitcoin-ce7d94a492e6-aarch64-linux-gnu.tar.gz 5ed9ea52a8bd55361d2d9c01fbd1b25ec9970530c2776e6c1959424ba1689f52 guix-build-ce7d94a492e6/output/arm-linux-gnueabihf/SHA256SUMS.part 2e483011fac64462d3aa000b577c3c05c825506032d879e39612e096d7a6c65b guix-build-ce7d94a492e6/output/arm-linux-gnueabihf/bitcoin-ce7d94a492e6-arm-linux-gnueabihf-debug.tar.gz 7ff1e3ba54944a2be89dd7d68cb91dff6f8950de9d7b521e15dfb746965f81bd guix-build-ce7d94a492e6/output/arm-linux-gnueabihf/bitcoin-ce7d94a492e6-arm-linux-gnueabihf.tar.gz abdf89e701b21b8c1238a8cec46aeaa55e0c3a0b88ad718636e89cde9813ca08 guix-build-ce7d94a492e6/output/arm64-apple-darwin/SHA256SUMS.part fb55cff0296cd5474811fe5cedcf28603628729dd085eeefa007c72582459b33 guix-build-ce7d94a492e6/output/arm64-apple-darwin/bitcoin-ce7d94a492e6-arm64-apple-darwin-codesigning.tar.gz e9aa566b1e79c467d7987b7c68fa608db788e6ddf89c4d90e524cd47b4faaf86 guix-build-ce7d94a492e6/output/arm64-apple-darwin/bitcoin-ce7d94a492e6-arm64-apple-darwin-unsigned.tar.gz bb428fc62a1230a55f49fa3b5c7ba8d588e8fed491357f890d5a6724a38b14e9 guix-build-ce7d94a492e6/output/arm64-apple-darwin/bitcoin-ce7d94a492e6-arm64-apple-darwin-unsigned.zip 5ef4b75e94b2c8265fbc588bbb42467a84438af969fddac0ea61ced3e4113345 guix-build-ce7d94a492e6/output/dist-archive/bitcoin-ce7d94a492e6.tar.gz 4f55d56a108c8f312a502cd5dfdf0840b091861a6d502df31caf4636a203697a guix-build-ce7d94a492e6/output/powerpc64-linux-gnu/SHA256SUMS.part 66c5b1242c60e37098885a00e24efe19baee4afcd2e3d6407207523d8872f055 guix-build-ce7d94a492e6/output/powerpc64-linux-gnu/bitcoin-ce7d94a492e6-powerpc64-linux-gnu-debug.tar.gz d9dbbee7217544eda26e77158cd82caeaef2b40fb9fc7033323e7ffe64264109 guix-build-ce7d94a492e6/output/powerpc64-linux-gnu/bitcoin-ce7d94a492e6-powerpc64-linux-gnu.tar.gz d9b808cc5685c819abcebb4ace65f003ebc4bfedf3fca046b34de37994358782 guix-build-ce7d94a492e6/output/riscv64-linux-gnu/SHA256SUMS.part eeeea470b1cf76515bfae14c779a3ea356d89f719d1fef1a81e8f0d6b04ab747 guix-build-ce7d94a492e6/output/riscv64-linux-gnu/bitcoin-ce7d94a492e6-riscv64-linux-gnu-debug.tar.gz 9993da4eb51618b8bd25ec88cc576496720e5589315e9eba6f3ddab25f9c3e60 guix-build-ce7d94a492e6/output/riscv64-linux-gnu/bitcoin-ce7d94a492e6-riscv64-linux-gnu.tar.gz 1b5a676580e0e79598d182f6ebbb05fb8aee2381edc3c09c042cae2600f448ab guix-build-ce7d94a492e6/output/x86_64-apple-darwin/SHA256SUMS.part 9152122d95a34d5df75305c6883c87707e7b09033fffd08e264d703ed177ef12 guix-build-ce7d94a492e6/output/x86_64-apple-darwin/bitcoin-ce7d94a492e6-x86_64-apple-darwin-codesigning.tar.gz 2793f75730dbef6bdf12b5ed7135e22ed21178abff2926dee92843837d4ab544 guix-build-ce7d94a492e6/output/x86_64-apple-darwin/bitcoin-ce7d94a492e6-x86_64-apple-darwin-unsigned.tar.gz e89aafd7e4a330a41f470e8f0a91ea876fad7d19547b404600867413f1a8ccb7 guix-build-ce7d94a492e6/output/x86_64-apple-darwin/bitcoin-ce7d94a492e6-x86_64-apple-darwin-unsigned.zip 955b27f881927a86da3c566357ad8ca68dbe17e9652bde8c482a57ceacba92cb guix-build-ce7d94a492e6/output/x86_64-linux-gnu/SHA256SUMS.part fd012be97bdf5c75ac12ddef21526bfdb5e17ecc77cde9c34d832194b0dc3293 guix-build-ce7d94a492e6/output/x86_64-linux-gnu/bitcoin-ce7d94a492e6-x86_64-linux-gnu-debug.tar.gz 0ecf7f80e9049369760d0e27fe6c026391ab25eae0f42336bef43e51a2621726 guix-build-ce7d94a492e6/output/x86_64-linux-gnu/bitcoin-ce7d94a492e6-x86_64-linux-gnu.tar.gz 2e8085f5fecc246d841b0bf6f28ecd0684a6cee49252fc88c1019d7586c7b7a2 guix-build-ce7d94a492e6/output/x86_64-w64-mingw32/SHA256SUMS.part c60041e8137eda352557254c5f67fb83eeb97ecfec342ee528451bd44ee4523a guix-build-ce7d94a492e6/output/x86_64-w64-mingw32/bitcoin-ce7d94a492e6-win64-codesigning.tar.gz b1be6b2f4de1c69c2e0e4de6dd97a4891ae9eb50d89435ef47247b5a187915a9 guix-build-ce7d94a492e6/output/x86_64-w64-mingw32/bitcoin-ce7d94a492e6-win64-debug.zip bfe143f41a20c537145c7044aca889b28efe19072b0150042a3bd865983b3d7e guix-build-ce7d94a492e6/output/x86_64-w64-mingw32/bitcoin-ce7d94a492e6-win64-setup-unsigned.exe 94a906b83d84db7b25f7e3cfdce2a2030243f2ee6cc70b1fc088459f0b2f382d guix-build-ce7d94a492e6/output/x86_64-w64-mingw32/bitcoin-ce7d94a492e6-win64-unsigned.zip ``` </details> ACKs for top commit: ryanofsky: Code review ACK ce7d94a. This was just rebased to fix a conflict since last review. josibake: ACK ce7d94a achow101: ACK ce7d94a ismaelsadeeq: ACK ce7d94a and tested again on macOS by building via depends and source. janb84: ACK ce7d94a Tree-SHA512: f7ab72933854e9dfce5746cdf764944bc26eec815f97cd0aa6b54fa499c3cccb1b678861ef5c1c793de28153d46bbb6e4d1b9aa0652163b74262e2d55ec8b813

DrahtBot added the Build system label Sep 26, 2024

Sjors commented Sep 26, 2024

View reviewed changes

contrib/guix/libexec/build.sh Outdated Show resolved Hide resolved

DrahtBot added the CI failed label Sep 26, 2024

Sjors force-pushed the 2024/09/multiprocess-guix branch from 8b2546c to df97390 Compare September 26, 2024 15:40

Sjors changed the title ~~guix: add multiprocess binaries~~ Add multiprocess binaries to release build Sep 26, 2024

ryanofsky mentioned this pull request Sep 26, 2024

RFC: Multiprocess binaries and packaging options #30983

Open

This was referenced Sep 26, 2024

depends: Fix build with MULTIPROCESS=1 in Guix environment #30940

Merged

net: Replace libnatpmp with built-in PCP+NATPMP implementation #30043

Merged

DrahtBot added the Needs rebase label Sep 27, 2024

Sjors force-pushed the 2024/09/multiprocess-guix branch from df97390 to 9cd4666 Compare September 27, 2024 10:59

DrahtBot added Needs rebase and removed Needs rebase labels Sep 27, 2024

Sjors force-pushed the 2024/09/multiprocess-guix branch from 9cd4666 to 3ef2a7c Compare October 1, 2024 07:33

DrahtBot removed the Needs rebase label Oct 1, 2024

Sjors force-pushed the 2024/09/multiprocess-guix branch from 3ef2a7c to 43c8866 Compare October 1, 2024 07:48

ryanofsky mentioned this pull request Oct 1, 2024

MSAN Error during connection shutdown bitcoin-core/libmultiprocess#115

Closed

DrahtBot added the Needs rebase label Apr 2, 2025

Sjors force-pushed the 2024/09/multiprocess-guix branch from 7c96e38 to 369da6a Compare April 2, 2025 15:12

DrahtBot removed the Needs rebase label Apr 2, 2025

This was referenced Apr 3, 2025

ci: Merge master in test-each-commit task #32203

Merged

net: Prevent accidental circuit sharing when using Tor stream isolation #32176

Merged

DrahtBot added the Needs rebase label Apr 4, 2025

vasild approved these changes Apr 10, 2025

View reviewed changes

Sjors added 2 commits April 11, 2025 13:24

ci: build multiprocess for all depends jobs

af7cecb

Except: 1. i686, DEBUG (changed to "no multiprocess") 2. Windows due to lack of support

ci: enable multiprocess for non-depends jobs

747af17

Install capnp where needed. The bitcoin-node binary is built on all platforms which have multiprocess enabled, but for functional tests it's only used in the macOS native (no depends) and CentOS native (depends) jobs.

Sjors force-pushed the 2024/09/multiprocess-guix branch from 369da6a to 747af17 Compare April 11, 2025 17:27

Sjors marked this pull request as ready for review April 11, 2025 17:28

DrahtBot removed the Needs rebase label Apr 11, 2025

maflcko reviewed Apr 11, 2025

View reviewed changes

DrahtBot requested a review from vasild April 11, 2025 19:00

Sjors closed this Apr 11, 2025

ci: build multiprocess on most jobs #30975

ci: build multiprocess on most jobs #30975

Uh oh!

Conversation

Sjors commented Sep 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DrahtBot commented Sep 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage & Benchmarks

Reviews

Conflicts

Uh oh!

Uh oh!

Sjors commented Sep 26, 2024

Uh oh!

fanquake commented Sep 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DrahtBot commented Sep 26, 2024

Uh oh!

Sjors commented Sep 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ryanofsky commented Sep 26, 2024

Uh oh!

Sjors commented Sep 26, 2024

Uh oh!

maflcko commented Sep 26, 2024

Uh oh!

ryanofsky commented Sep 26, 2024

Uh oh!

fanquake commented Sep 27, 2024

Uh oh!

Sjors commented Sep 27, 2024

Uh oh!

Sjors commented Oct 1, 2024

Uh oh!

Sjors commented Oct 1, 2024

Uh oh!

ryanofsky commented Oct 1, 2024

Uh oh!

Sjors commented Apr 4, 2025

Uh oh!

vasild left a comment

Choose a reason for hiding this comment

Uh oh!

Sjors commented Apr 11, 2025

Uh oh!

maflcko left a comment

Choose a reason for hiding this comment

Uh oh!

Sjors commented Apr 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ryanofsky commented Apr 11, 2025

Uh oh!

Sjors commented Apr 11, 2025

Uh oh!

Sjors commented Apr 11, 2025

Uh oh!

Uh oh!

Sjors commented Sep 26, 2024 •

edited

Loading

DrahtBot commented Sep 26, 2024 •

edited

Loading

fanquake commented Sep 26, 2024 •

edited

Loading

Sjors commented Sep 26, 2024 •

edited

Loading

Sjors commented Apr 11, 2025 •

edited

Loading