🚀 fanquake merged a pull request: "cmake, qt: Use absolute paths for includes in MOC-generated files"
(https://github.com/bitcoin/bitcoin/pull/31361)

💬 maflcko commented on pull request "doc: correct libfuzzer-nosan preset flag":
(https://github.com/bitcoin/bitcoin/pull/31402#issuecomment-2511148334)
lgtm ACK 16b140f225a24b9075ef6e4cf6f0788bf96ace5f

✅ fanquake closed a pull request: "doc: Update license year range to 2025"
(https://github.com/bitcoin/bitcoin/pull/31400)

💬 fanquake commented on pull request "doc: Update license year range to 2025":
(https://github.com/bitcoin/bitcoin/pull/31400#issuecomment-2511150850)
This will happen at some later point.

🚀 fanquake merged a pull request: "doc: correct libfuzzer-nosan preset flag"
(https://github.com/bitcoin/bitcoin/pull/31402)

💬 dergoegge commented on pull request "[POC] cmake: Introduce LLVM's Source-based Code Coverage reports":
(https://github.com/bitcoin/bitcoin/pull/31394#issuecomment-2511161883)
Would we keep supporting generating coverage with gcc?

💬 laanwj commented on issue "macOS 13.7 depends build can't find qt (symlink)":
(https://github.com/bitcoin/bitcoin/issues/31050#issuecomment-2511163338)
Yes, this is a different problem. #31361 had to do with generated (moc) files, not finding Qt itself.

💬 Sjors commented on pull request "Miner: never create a template which exploits the timewarp bug":
(https://github.com/bitcoin/bitcoin/pull/31376#issuecomment-2511166913)
> in any normal circumstance

By normal circumstance you mean when nobody else on the network is attempting a timewarp attack? But what if there is one?

Let's say the software is deployed in the future with `MAX_TIMEWARP` set to `300`. But honest miner Alice is still running the v29 release with this PR it, using `600`. Mean miner Bob now wants to produce a block at the end of the retarget period such that others accidentally produce an invalid block. They would set it 600 seconds in the fu
...

💬 fanquake commented on pull request "cmake: Add `CheckLinkerSupportsPIE` module":
(https://github.com/bitcoin/bitcoin/pull/31359#issuecomment-2511181438)
> Enhances robustness

Can you explain this further? Why is CMakes own check not "robust" enough to use directly? Is this another bug/something that should be improved upstream?

🚀 fanquake merged a pull request: "cmake: Improve build script correctness"
(https://github.com/bitcoin/bitcoin/pull/31357)

💬 Sjors commented on pull request "Add multiprocess binaries to release build":
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2511204009)
Trivial rebase after #31399.

I disabled ASan + LSan + UBsan again, see previous failure log: https://github.com/bitcoin/bitcoin/actions/runs/11970857809/job/33374462331?pr=30975

(this drops fda0d98237b4a82a94a5672f6bd263bca04adf35 and adjusts 0b5c84bc988e600484012f43df0e9950e7c444f5 to enable multiprocess for `ci/test/00_setup_env_native_valgrind.sh`)

💬 l0rinc commented on pull request "refactor: prohibit direct flags access in CCoinsCacheEntry and remove invalid tests":
(https://github.com/bitcoin/bitcoin/pull/30906#discussion_r1865645185)
It's not the purpose of this PR to add additional coverage, but after these refactors it's now possible to exercise the negative cases as well (which are missing here but tested in the other test methods, hence the TODO), similarly to how the above PR does for fuzzing.

💬 le0nAg commented on issue "Add `sat_to_btc()` and conversely `btc_to_sat()` util functions in functional tests":
(https://github.com/bitcoin/bitcoin/issues/31345#issuecomment-2511225604)
Could I take the issue?

💬 l0rinc commented on pull request "test: cover base32/base58/base64 with symmetric roundtrip fuzz (and padding) tests":
(https://github.com/bitcoin/bitcoin/pull/30746#discussion_r1865666794)
I forgot about this comment, thanks for checking, both tests on 42 and 43 were invalid because of the non-trailing `=`, not the `\0` - [updated them](https://github.com/bitcoin/bitcoin/compare/6fd185c035c1cc4dd961cf14a2087e97fb069440..37e5fcfd4fad2f2daed041ddfd60b0c28e5da6b6)

💬 hebasto commented on pull request "cmake: Add `CheckLinkerSupportsPIE` module":
(https://github.com/bitcoin/bitcoin/pull/31359#issuecomment-2511246212)
> > Enhances robustness
>
> Can you explain this further? Why is CMakes own check not "robust" enough to use directly? Is this another bug/something that should be improved upstream?

Sure thing!

(Almost?) every CMake check internally uses the [`try_compile()`](https://cmake.org/cmake/help/latest/command/try_compile.html) command, whose behaviour, in turn, depends on the [`CMAKE_TRY_COMPILE_TARGET_TYPE`](https://cmake.org/cmake/help/latest/variable/CMAKE_TRY_COMPILE_TARGET_TYPE.html) var
...

💬 fanquake commented on pull request "cmake: Add `CheckLinkerSupportsPIE` module":
(https://github.com/bitcoin/bitcoin/pull/31359#issuecomment-2511251713)
This seems very fragile and unintuitive, and the fact that this could silently break at any point is not documented in any way. I don't think other bad design decisions should lead to us having to write even more boilerplate code to fix things that should "just work" (minus the upstream bugs).

👋 fanquake's pull request is ready for review: "[28.x] Backports & 28.1rc1"
(https://github.com/bitcoin/bitcoin/pull/31104)

✅ fanquake closed an issue: "RPC breakage with v28.0"
(https://github.com/bitcoin/bitcoin/issues/31039)

💬 fanquake commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2511284738)
Closing this now. Anything left to do can be tracked in individual issues. A number of things have been merged / resolved downstream. It looks like some wont be, i.e https://github.com/vansergen/rpc-bitcoin/pull/65, but that package in particular is essentially unmaintained at this point.

✅ fanquake closed a pull request: "doc: Fix dead links to mailing list archives"
(https://github.com/bitcoin/bitcoin/pull/31240)