✅ fanquake closed a pull request: "cmake: support `-DBUILD_GUI=qt6`"
(https://github.com/bitcoin-core/gui/pull/861)

💬 fanquake commented on pull request "cmake: support `-DBUILD_GUI=qt6`":
(https://github.com/bitcoin-core/gui/pull/861#issuecomment-2765196621)
Thanks, however the changes to switch to Qt6 are being done in https://github.com/bitcoin/bitcoin/pull/30997.

💬 fanquake commented on pull request "cmake: support `-DBUILD_GUI=qt6`":
(https://github.com/bitcoin-core/gui/pull/861#issuecomment-2765197200)
(There are no plans to support both qt 5 & 6 at the same time.

💬 laanwj commented on pull request "torcontrol: Define tor reply code as const to improve our maintainability":
(https://github.com/bitcoin/bitcoin/pull/32166#issuecomment-2765213135)
> Could probably be cherry-picked into https://github.com/bitcoin/bitcoin/pull/31973, so that there is only a single pull with doc/refactor fixups of the same file?

Probably this was meant the other way around: cherry-pick this change into that PR, to not have to open a new one. But this works too.

💬 whitslack commented on pull request "cmake: support `-DBUILD_GUI=qt6`":
(https://github.com/bitcoin-core/gui/pull/861#issuecomment-2765215050)
Oh balls. When I searched the issue tracker for Qt6 progress, I had `is:issue` in my query, so I didn't find the new PR. :man_facepalming:

Thanks for the pointer.

💬 laanwj commented on pull request "torcontrol: Define tor reply code as const to improve our maintainability":
(https://github.com/bitcoin/bitcoin/pull/32166#discussion_r2020460428)
nit: Please use the same comment syntax as the other comments

💬 eval-exec commented on pull request "torcontrol: Define tor reply code as const to improve our maintainability":
(https://github.com/bitcoin/bitcoin/pull/32166#discussion_r2020461693)
Thank you, fixed.

💬 maflcko commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#issuecomment-2765256363)
Are you still working on this?

💬 saikiran57 commented on pull request "wallet: removed duplicate call to GetDescriptorScriptPubKeyMan":
(https://github.com/bitcoin/bitcoin/pull/32023#issuecomment-2765272443)
Hi @maflcko could you please ACK if your okay with response.

💬 laanwj commented on pull request "torcontrol: Define tor reply code as const to improve our maintainability":
(https://github.com/bitcoin/bitcoin/pull/32166#discussion_r2020484368)
It's strange that the only torproject.org link for the C Tor manual is a 2019 backup of the site, but haven't found anything better either.
The only up-to-date canonical source is the manual page, which isn't particularly readable on the web https://gitlab.torproject.org/tpo/core/tor/-/blob/main/doc/man/tor.1.txt
(nothing to do here really, just noting)

👍 laanwj approved a pull request: "torcontrol: Define tor reply code as const to improve our maintainability"
(https://github.com/bitcoin/bitcoin/pull/32166#pullrequestreview-2728361165)
Code review ACK f31ce35966bb84608938b0ba2272b415bcd42618

💬 eval-exec commented on pull request "torcontrol: Define tor reply code as const to improve our maintainability":
(https://github.com/bitcoin/bitcoin/pull/32166#discussion_r2020488844)
Yes the web url link is old, but the `IsolateSOCKSAuth` explaination content is same with https://gitlab.torproject.org/tpo/core/tor/-/blob/main/doc/man/tor.1.txt

💬 laanwj commented on pull request "torcontrol: Define tor reply code as const to improve our maintainability":
(https://github.com/bitcoin/bitcoin/pull/32166#discussion_r2020497489)
Oh yes the site is correct, i'm just a bit worried about it going offline at some point, so was trying to find a more up-to-date official link. But it doesn't exist.

💬 Bue-von-hon commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#issuecomment-2765314756)
> Are you still working on this?

sure!

💬 laanwj commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#discussion_r2020506583)
No strong opinion on XX-bit versus XX bit, but mind that i made the opposite change (for consistently) recently in a0c9595810c7d8bb17d8b5bea8d916db194b5239

💬 laanwj commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#discussion_r2020508512)
i've always been confused about the `-pc-` in the architecture tuple-is it directly related to use (or non-use) of multilib?

💬 laanwj commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#issuecomment-2765334131)
Concept ACK, multilib is more or less specific to x86, it's better if multi-platform is handled in a more agnostic and consistent way.

💬 hebasto commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#discussion_r2020523649)
I referred to the following sources:
- https://en.wikipedia.org/wiki/32-bit_computing
- https://en.wikipedia.org/wiki/64-bit_computing

Happy to revert if requested.

💬 hebasto commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#discussion_r2020536135)
It's hard to say.

Referring to `x86_64-pc-linux-gnu` is still necessary when building depends natively on `x86_64`, because:
```
$ uname -m
x86_64
$ ./depends/config.sub $(./depends/config.guess)
x86_64-pc-linux-gnu
```

However, dropping the `-pc-` infix [helped](https://github.com/google/oss-fuzz/pull/13187) to with Clang's paths in the OSS-Fuzz environment.

💬 laanwj commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#discussion_r2020564681)
No it's fine with me let's just not get into an edit war 😄

🤔 rkrux requested changes to a pull request: "test: create assert_not_equal util"
(https://github.com/bitcoin/bitcoin/pull/29500#pullrequestreview-2728485178)
Concept ACK be71af3cc0b0bcb7d917cc6f2e5fda119f1b1bd6

Requesting changes mainly because an additional comma is printed in case of an assertion error when the error message is not passed, which can be confusing for the reader later.

```
2025-03-31T07:28:44.958000Z TestFramework (INFO): Test fundrawtxn with locked wallet and hardened derivation
2025-03-31T07:28:46.455000Z TestFramework (ERROR): Assertion failed
Traceback (most recent call last):
File "/Users/rkrux/projects/bitcoin/test/
...