💬 rkrux commented on pull request "descriptors: Multipath/PR 22838 follow-ups":
(https://github.com/bitcoin/bitcoin/pull/32134#discussion_r2020423324)
+1 for using `placeholder`, makes it easier to follow.

📝 whitslack opened a pull request: "cmake: support `-DBUILD_GUI=qt6`"
(https://github.com/bitcoin-core/gui/pull/861)
This PR adds support in `CMakeLists.txt` for `-DBUILD_GUI=qt6` to allow building against system-installed Qt6 libraries in distributions that are dropping support for Qt5 (such as [Gentoo](https://bugs.gentoo.org/948836)).

I specify Qt 6.2.4 as a minimum requirement based on the work in bitcoin/bitcoin#24798, but I do not know whether Bitcoin Core currently builds against such an old version of Qt6. I have successfully built v29.0rc2 against Qt 6.8.3.

✅ 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.