✅ fanquake closed an issue: "cmake: multiprocess guix build broken"
(https://github.com/bitcoin/bitcoin/issues/30931)

🚀 fanquake merged a pull request: "depends: Fix build with `MULTIPROCESS=1` in Guix environment"
(https://github.com/bitcoin/bitcoin/pull/30940)

🚀 fanquake merged a pull request: "ci: Inline PACKAGE_MANAGER_INSTALL"
(https://github.com/bitcoin/bitcoin/pull/30974)

🤔 hebasto reviewed a pull request: "docs: Add instructions on how to self-sign bitcoin-core binaries for macOS"
(https://github.com/bitcoin/bitcoin/pull/30982#pullrequestreview-2333289289)
Concept ACK.

I've tested the content of the [`bitcoin-28.0rc2-x86_64-apple-darwin.tar.gz`](https://bitcoincore.org/bin/bitcoin-core-28.0/test.rc2/bitcoin-28.0rc2-x86_64-apple-darwin.tar.gz) on macOS (Apple M1) Sequoia 15.0 (24A335).

The `code sign -s - ...` command is not required to run downloaded binaries. However, I didn't test other maOS versions.

💬 maflcko commented on pull request "test: re-bucket long-running tests":
(https://github.com/bitcoin/bitcoin/pull/30879#issuecomment-2378900314)
`feature_config_args.py` could be moved as well, but at some point it doesn't matter too much. I wonder if this even has an effect at all.

💬 fanquake commented on pull request "docs: Add instructions on how to self-sign bitcoin-core binaries for macOS":
(https://github.com/bitcoin/bitcoin/pull/30982#issuecomment-2378901637)
> The code sign -s - ... command is not required to run downloaded binaries.

How are the binaries running if they aren't codesigned at all?
If this isn't an issue why are we adding these instructions?

💬 maflcko commented on pull request "test: re-bucket long-running tests":
(https://github.com/bitcoin/bitcoin/pull/30879#issuecomment-2378902126)
review ACK f5a2000579b140a1f51fc433706c775ca560c62c

Haven't checked what effect this has, but it sounds plausible and harmless.

🚀 fanquake merged a pull request: "test: generalize HasReason and use it in FailFmtWithError"
(https://github.com/bitcoin/bitcoin/pull/30921)

💬 hebasto commented on pull request "docs: Add instructions on how to self-sign bitcoin-core binaries for macOS":
(https://github.com/bitcoin/bitcoin/pull/30982#issuecomment-2378938037)
The GUI users [may be able to temporarily override your Mac security settings to open it](https://support.apple.com/en-gb/102445#openanyway) (tested on the same machine for `Bitcoin Core.app` downloaded from https://bitcoincore.org/bin/bitcoin-core-28.0/test.rc2/bitcoin-28.0rc2-x86_64-apple-darwin.zip).

💬 willcl-ark commented on pull request "docs: Add instructions on how to self-sign bitcoin-core binaries for macOS":
(https://github.com/bitcoin/bitcoin/pull/30982#issuecomment-2378938200)
> Concept ACK.
>
> I've tested the content of the [`bitcoin-28.0rc2-x86_64-apple-darwin.tar.gz`](https://bitcoincore.org/bin/bitcoin-core-28.0/test.rc2/bitcoin-28.0rc2-x86_64-apple-darwin.tar.gz) on macOS (Apple M1) Sequoia 15.0 (24A335).
>
> The `code sign -s - ...` command is _not_ required to run downloaded binaries. However, I didn't test other maOS versions.

I certainly see an error and ask for it to be removed, also on 15.0

<img width="908" alt="image" src="https://github.com/u
...

🚀 fanquake merged a pull request: "test: re-bucket long-running tests"
(https://github.com/bitcoin/bitcoin/pull/30879)

💬 hebasto commented on pull request "docs: Add instructions on how to self-sign bitcoin-core binaries for macOS":
(https://github.com/bitcoin/bitcoin/pull/30982#issuecomment-2378944754)
My bad! I downloaded binaries for `x86_64` arch on `arm64` machine. They were using the Rosetta framework.

💬 willcl-ark commented on pull request "docs: Add instructions on how to self-sign bitcoin-core binaries for macOS":
(https://github.com/bitcoin/bitcoin/pull/30982#issuecomment-2378949502)
> I downloaded binaries for `x86_64` arch on `arm64` machine. They were using the Rosetta framework.

A very sneaky undocumented workaround!

🤔 ismaelsadeeq reviewed a pull request: "Cluster linearization: separate tests from tests-of-tests"
(https://github.com/bitcoin/bitcoin/pull/30605#pullrequestreview-2333401196)
Code review ACK 0cae0c487cb8b32b96f888a31e818f2a90f848cc

💬 stickies-v commented on pull request "tinyformat: refactor: increase compile-time checks and don't throw for tfm::format_error":
(https://github.com/bitcoin/bitcoin/pull/30928#discussion_r1778429402)
I assumed the next step would be to validate the `bilingual_str` overload at compile-time too, but I've been looking at implementing that and with the run-time translation dependency (`QCoreApplication::translate`) it doesn't really seem feasible.

I hadn't considered that translations can introduce format errors too, which makes the case for `bilingual_str` format errors not throwing ever stronger indeed. I was worried that blanket catching all formatting errors at the `tfm` level could be co
...

💬 Sjors commented on pull request "Add multiprocess binaries to release build":
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2379013786)
Rebased after #30940

💬 Sjors commented on pull request "rpc: add optional blockhash to waitfornewblock":
(https://github.com/bitcoin/bitcoin/pull/30635#discussion_r1778446846)
So this effects GUI users that use the console, rather than bitcoin-cli?

💬 stickies-v commented on pull request "tinyformat: refactor: increase compile-time checks and don't throw for tfm::format_error":
(https://github.com/bitcoin/bitcoin/pull/30928#issuecomment-2379043395)
Force-pushed to address @maflcko's [comment](https://github.com/bitcoin/bitcoin/pull/30928/#discussion_r1776965132) about generally not letting `tinyformat` throw format errors, instead of just for the `util::ConstevalFormatString` overloads. Most notably, this changes behaviour for the `bilingual_str` `format` overload to also not throw.

👍 maflcko approved a pull request: "tinyformat: refactor: increase compile-time checks and don't throw for tfm::format_error"
(https://github.com/bitcoin/bitcoin/pull/30928#pullrequestreview-2333489859)
lgtm

💬 hebasto commented on issue "RFC: Multiprocess binaries and packaging options":
(https://github.com/bitcoin/bitcoin/issues/30983#issuecomment-2379073216)
> I like the idea of a unified `bitcoin` command.

So do I.

Would it be beneficial for users if we started shipping DEB and RPM packages? The package manager would handle the proper installation of multiple executables.