💬 beirut-boop commented on pull request "wallet: unify “allow/block other inputs“ concept":
(https://github.com/bitcoin/bitcoin/pull/25118#issuecomment-1481263469)
@furszy thank you, appreciated! :+1:

@fanquake I understand but the implication would be that there could be a bug in this project. If @furszy had responded differently after a quick glance, my next step would be to create a test case using Bitcoin Qt.

💬 hebasto commented on pull request "depends: fontconfig 2.14.2":
(https://github.com/bitcoin/bitcoin/pull/27301#issuecomment-1481267420)
> Looks like we can't drop the patch, as we'd still end up needing gperf, however just adapting our current patch to the new code also doesn't build, so we'll need to do more there. In any case, even if fontconfig builds, Qt doesn't work (out of the box) with clang-16, so this seems like a waste of time.

✅ hebasto closed a pull request: "depends: fontconfig 2.14.2"
(https://github.com/bitcoin/bitcoin/pull/27301)

💬 stickies-v commented on pull request "test: fix race condition in encrypted wallet rescan tests":
(https://github.com/bitcoin/bitcoin/pull/27199#discussion_r1146259525)
It seems (?) we want this test to fail if `walletlock` succeeds, but that's not currently the case - is that on purpose? Apologies if I'm misunderstanding, I didn't dive super deep yet so feel free to keep your answer brief.

📝 hebasto reopened a pull request: "depends: fontconfig 2.14.2"
(https://github.com/bitcoin/bitcoin/pull/27301)
We need to bump this as the current version doesn't compile under `clang-16`, which is blocking upgrading sanitizer/fuzzing infrastructure (see #27298).

Untested. Need to double-check the gperf/patch dropping.

👍 stickies-v approved a pull request: "test: Replace threading with concurrent.futures"
(https://github.com/bitcoin/bitcoin/pull/27287)
ACK fa0696e7863af03efbffa026c2060ff2b5720fb1

💬 stickies-v commented on pull request "test: Replace threading with concurrent.futures":
(https://github.com/bitcoin/bitcoin/pull/27287#discussion_r1146243249)
nit: I think `thread` is a misnomer, even with just 1 worker it's still a `pool` or `executor`.

⚠️ Sjors opened an issue: "Millisecond log timestamp (option)"
(https://github.com/bitcoin/bitcoin/issues/27313)
### Please describe the feature you'd like to see added.

For some events, like two blocks at the same height being announced by multiple peers at the same time, it's nice to have millisecond precision on the log entries.

### Is your feature related to a problem, if so please describe it.

E.g. one of the ForkMonitor nodes saw two blocks at height 782,129 within the same second: https://twitter.com/BitMEXResearch/status/1638875082943520769

Other nodes saw those blocks in the opposite order.

...

💬 furszy commented on pull request "wallet: unify “allow/block other inputs“ concept":
(https://github.com/bitcoin/bitcoin/pull/25118#issuecomment-1481289311)
> @fanquake I understand but the implication would be that there could be a bug in this project. If @furszy had responded differently after a quick glance, my next step would be to create a test case using Bitcoin Qt.

What fanquake pointed out, which I agree, is about linking other repositories issues here. Which isn't the best. We don't know what you have there (nor people are going to get deeper trying to find it). Time is a scarce resource for everyone.

But happy to help if you create a
...

💬 fanquake commented on issue "Millisecond log timestamp (option)":
(https://github.com/bitcoin/bitcoin/issues/27313#issuecomment-1481296969)
Does `-logtimemicros` not work

💬 ishaanam commented on pull request "test: fix race condition in encrypted wallet rescan tests":
(https://github.com/bitcoin/bitcoin/pull/27199#discussion_r1146291614)
> I suppose the main difficulty here is that walletlock can succeed if the rescan has already finished by the time walletlock is called
Yes, this issue here is that the rescan could have finished. For more context see: https://github.com/bitcoin/bitcoin/pull/27199#discussion_r1135849437

> then I think maybe the test needs a different setup?
It would be great if there was a way that this test could behave the same regardless of speed. We haven't been able to find a way to make that happen ye
...

💬 Sjors commented on issue "Millisecond log timestamp (option)":
(https://github.com/bitcoin/bitcoin/issues/27313#issuecomment-1481307041)
Ah oops, I only searched for documented options. Yes that works.

✅ Sjors closed an issue: "Millisecond log timestamp (option)"
(https://github.com/bitcoin/bitcoin/issues/27313)

📝 hebasto opened a pull request: "build, qt: Fix handling of `CXX=clang++` when building `qt` package"
(https://github.com/bitcoin/bitcoin/pull/27314)
On the master branch (f380bb93e854b24cec4ef020235340f5186deded):
```
$ cd depends
$ make qt CC=clang CXX=clang++
...
Project ERROR: failed to parse default search paths from compiler output
make: *** [funcs.mk:292: /home/hebasto/git/bitcoin/depends/x86_64-pc-linux-gnu/.qt_stamp_configured] Error 3
```

Fixes https://github.com/bitcoin/bitcoin/pull/27301#issuecomment-1479622034.

💬 Sjors commented on issue "Millisecond log timestamp (option)":
(https://github.com/bitcoin/bitcoin/issues/27313#issuecomment-1481317723)
Might be worth promoting this from `OptionsCategory::DEBUG_TEST` to `OptionsCategory::OPTIONS`, since it's useful beyond debugging the software.

⚠️ fanquake opened an issue: "tidy: enable `cppcoreguidelines-pro-type-member-init`"
(https://github.com/bitcoin/bitcoin/issues/27315)
https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines/pro-type-member-init.html
> The check flags user-defined constructor definitions that do not initialize all fields that would be left in an undefined state by default construction, e.g. builtins, pointers and record types without user-provided default constructors containing at least one such type. If these fields aren’t initialized, the constructor will leave some of the memory in an undefined state.

Have been multiple calls t
...

💬 mzumsande commented on pull request "p2p: Improve diversification of new connections":
(https://github.com/bitcoin/bitcoin/pull/27264#issuecomment-1481322628)
> Moreover I guess doing any kind of "netgroup"-based diversification for these peers doesn't make sense, since for those addresses, our group assignments are arbitrary and there's no relationship between the address and our route? (If that understanding is correct then that is a separate issue from the improvement here, so could be picked up in another PR.)

I agree, and I think there is another problem that is exacerbated by this PR:

The grouping is not just arbitrary for these networks,
...

💬 fanquake commented on pull request "[DEMO] Integrate `bitcoin-tidy` clang-tidy plugin - warn on uninitialized members of aggregate types":
(https://github.com/bitcoin/bitcoin/pull/26296#issuecomment-1481323268)
Going to close this for now. Opened #27315 in regards to adding `cppcoreguidelines-pro-type-member-init` to clang-tidy.

✅ fanquake closed a pull request: "[DEMO] Integrate `bitcoin-tidy` clang-tidy plugin - warn on uninitialized members of aggregate types"
(https://github.com/bitcoin/bitcoin/pull/26296)

💬 hebasto commented on pull request "guix: import/sync python-lief (0.12.3) package definition from upstream":
(https://github.com/bitcoin/bitcoin/pull/27296#issuecomment-1481341580)
Guix builds:
```
2780a866c6a930a413cab8de3840d01c3166712d12d2f17693f30cb162eb4b92 guix-build-24f26e08cc0d/output/aarch64-linux-gnu/SHA256SUMS.part
13ccce6016de14a892b2cfac52d0a412e2c348862871a8b38498ceaf352cf48a guix-build-24f26e08cc0d/output/aarch64-linux-gnu/bitcoin-24f26e08cc0d-aarch64-linux-gnu-debug.tar.gz
3e7c7ea6fde2cdf50f4a8c66baf5ae86295f4b426fef62f32d91839a770149ce guix-build-24f26e08cc0d/output/aarch64-linux-gnu/bitcoin-24f26e08cc0d-aarch64-linux-gnu.tar.gz
9a25be8a68331fb4fa9
...