💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2081860464)
added a comment and bumped the value

💬 rkrux commented on pull request "Wallet: Fix Non-Ranged Descriptors with Range [0,0] Trigger Unexpected Wallet Errors in AddWalletDescriptor":
(https://github.com/bitcoin/bitcoin/pull/32344#issuecomment-2866886845)
> Then how can the user trigger the error being solved here? If it can't be triggered by the user, we're talking about an extra guard rather than a fix — which is fine as well, but it would be better to label the PR differently, since it won't need to be backported.

Agree that the PR can be labeled differently.

> When attempting to add a non-ranged descriptor with a start/end range of [0,0] via AddWalletDescriptor, an error may appear

The issue #31728 description states that it is trigg
...

📝 fanquake opened a pull request: "fs: remove `_POSIX_C_SOURCE` defining"
(https://github.com/bitcoin/bitcoin/pull/32460)
From what I can tell, compilers on Linux systems, will be defining `_GNU_SOURCE`, which results in `glibc` defining `_POSIX_C_SOURCE` to `200809L`; so undefining it, and setting it to an earlier value does not seem like the correct behaviour for us, or even required, to check that this function is usable on Linux. I think there's also the chance that this could have adverse effects, by essentially trying to opt out of more mordern POSIX behaviour?

I think if anything, the project should be se
...

✅ fanquake closed an issue: "cmake inconsistently overriding `-O3` (sometimes)"
(https://github.com/bitcoin/bitcoin/issues/31491)

💬 fanquake commented on issue "cmake inconsistently overriding `-O3` (sometimes)":
(https://github.com/bitcoin/bitcoin/issues/31491#issuecomment-2866893762)
Given the amount of discussion here, we can re-open new issues.

⚠️ l0rinc opened an issue: "test: `acceptstalefeeestimates` failure in `feature_fee_estimation` after duplicate coinbase tx weight reservation fix"
(https://github.com/bitcoin/bitcoin/issues/32461)
### Summary
First encountered in https://github.com/bitcoin/bitcoin/actions/runs/14929268797/job/41941137828?pr=31144

Doing a git bisect reveals the likely culprit is [mining: bugfix: Fix duplicate coinbase tx weight reservation](https://github.com/bitcoin/bitcoin/pull/31384)

---

### Reproducer

> git checkout 6b165f5906fc53bd10bedff85a6ef26e0aabdc5c

```bash
HEAD is now at 6b165f5906 Merge bitcoin/bitcoin#31384: mining: bugfix: Fix duplicate coinbase tx weight reservation
```

> cmake -B bui
...

💬 l0rinc commented on pull request "[IBD] multi-byte block obfuscation":
(https://github.com/bitcoin/bitcoin/pull/31144#issuecomment-2866907838)
Rebased, opened issue for [unrelated test failure](https://github.com/bitcoin/bitcoin/issues/32461)

💬 hebasto commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#discussion_r2081895682)
@maflcko
> Another alternative would be to just require python3, without a way to disable it. Thus, the option `WITH_PYTHON` can be removed.

Here is some historical context: treating the `Python3` package as optional was introduced in the staging [branch](https://github.com/hebasto/bitcoin/pull/15#discussion_r1192711084). In particular, @theuni noted:
> This makes us dependent on python, even if we're not running tests/bench, no? I wouldn't expect python to be a hard requirement for buildi
...

💬 l0rinc commented on pull request "bench: replace benchmark block with more representative one (413567 → 784588)":
(https://github.com/bitcoin/bitcoin/pull/32457#discussion_r2081901172)
Yes, this one definitely, but in the other cases I'm worried about introducing a strong bias.
It's not like we're changing these very often - but I'll investigate anyway, let's see how close we can get without adding 1.5 Mb to the repo.

💬 hebasto commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#discussion_r2081903398)
> I see. I guess I wanted to say the opposite: Can't this be removed, because it seems a bit odd to print a warning that something is disabled, when the users explicitly asked it to be disabled? There is also no warning when a user sets `BUILD_TESTS=OFF`.

Thanks! Implemented.

👋 hebasto's pull request is ready for review: "cmake: Introduce `WITH_PYTHON` build option"
(https://github.com/bitcoin/bitcoin/pull/31669)

💬 brunoerg commented on pull request "test: added fuzz coverage for consensus/merkle.cpp":
(https://github.com/bitcoin/bitcoin/pull/32243#discussion_r2081903903)
`ConsumeTransaction` is fine.

💬 hebasto commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#issuecomment-2866948636)
The [feedback](https://github.com/bitcoin/bitcoin/pull/31669#discussion_r2081903398) from @maflcko has been addressed.

Also rebased.

🤔 fanquake requested changes to a pull request: "cmake: Introduce `WITH_PYTHON` build option"
(https://github.com/bitcoin/bitcoin/pull/31669#pullrequestreview-2828742547)
As I mentioned above, adding more build options/compexity, and forcing builders to opt out of things they don't care about, does not seem like a good, nor generic approach to fixing #31476. Especailly given this is essentially a CI fix, to work around the fact that CMake doesn't have a way to turn warnings into errors?

💬 fanquake commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#discussion_r2081908186)
> That concern still appears to be relevant.

Yea. This is also essentially reintroducing the previous Autotools behaviour of having opt-out dependencies (i.e bdb for a long time), rather than opt-in, which is what we started doing with CMake.

💬 laanwj commented on pull request "bench: replace benchmark block with more representative one (413567 → 784588)":
(https://github.com/bitcoin/bitcoin/pull/32457#discussion_r2081925616)
it's not just the amount of data, we're still scared from the xz backdoor incident :smile:

💬 maflcko commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#issuecomment-2866998704)
> forcing builders to opt out of things they don't care about

I am not sure the current approach of silently skipping tests (with just a warning during configure, not when running the tests) is the right approach.

A third alternative would be to delay the error to when they run the tests.

A fourth alternative would be to just call the two python tests from the functional test runner somehow and remove all this code here?

💬 hebasto commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#issuecomment-2867005648)
> > forcing builders to opt out of things they don't care about
>
> I am not sure the current approach of silently skipping tests (with just a warning during configure, not when running the tests) is the right approach.
>
> A third alternative would be to delay the error to when they run the tests.

FWIW, something similar has been implemented in https://github.com/bitcoin/bitcoin/pull/31233.

💬 fanquake commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#discussion_r2081949565)
I think the commit message should still be fixed to say `When compiling with MSVC`, rather than `On Windows`?

> (I've added a note to the PR description)

Is it a bug in mingw-w64 that it doesn't match the MSVC behaviour? It would be good to an explanation of the difference in the PR description/commit message, as it isn't really clear from going to the link you've provided.

💬 fanquake commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867023954)
> It is documented, and it is pre-defined by CI itself:

It's not in our docs, or in our CI code, which means our CI would "work", because a third party is putting something into the environment, and the fact that this is even happening, is only discoverable if you happen to read a `.cpp` file.

Would someone running these binaries locally also need/want to set this env var to get the same behaviour? If so, how would they figure that out?