💬 Sjors commented on pull request "build: suggest -DENABLE_IPC=OFF when missing capnp":
(https://github.com/bitcoin/bitcoin/pull/33290#issuecomment-3249033527)
@maflcko the log is very verbose, but in indeed useful, so I opened #33291.
(https://github.com/bitcoin/bitcoin/pull/33290#issuecomment-3249033527)
@maflcko the log is very verbose, but in indeed useful, so I opened #33291.
📝 Sjors converted_to_draft a pull request: "build: suggest -DENABLE_IPC=OFF when missing capnp"
(https://github.com/bitcoin/bitcoin/pull/33290)
Since #31802, when existing users upgrade to a recent version of master, or the upcoming v30 release, they'll be treated by an error that CapnProto is missing. Unless they read the release notes :-)
This error is generated by `src/ipc/libmultiprocess/CMakeLists.txt` which is a git subtree and so it doesn't have context of our project, and doesn't know about the `-DENABLE_IPC` option.
This pull request adds a simple pre-check in own CMake file to see if Cap'n Proto is missing. For ease of m
...
(https://github.com/bitcoin/bitcoin/pull/33290)
Since #31802, when existing users upgrade to a recent version of master, or the upcoming v30 release, they'll be treated by an error that CapnProto is missing. Unless they read the release notes :-)
This error is generated by `src/ipc/libmultiprocess/CMakeLists.txt` which is a git subtree and so it doesn't have context of our project, and doesn't know about the `-DENABLE_IPC` option.
This pull request adds a simple pre-check in own CMake file to see if Cap'n Proto is missing. For ease of m
...
💬 fanquake commented on issue "build: secp256k1 warnings not turned into errors in MSAN job":
(https://github.com/bitcoin/bitcoin/issues/33284#issuecomment-3249065390)
My expectation would be that the CI shouldn't produce any spurious output, and any unexpected output would be an error. That way, any output is either fixed, or documented/suppressed. Otherwise anyone looking at the CI can't know what is expected, what should be fixed, or what doesn't matter, and we avoid issues like this, #33256, etc.
(https://github.com/bitcoin/bitcoin/issues/33284#issuecomment-3249065390)
My expectation would be that the CI shouldn't produce any spurious output, and any unexpected output would be an error. That way, any output is either fixed, or documented/suppressed. Otherwise anyone looking at the CI can't know what is expected, what should be fixed, or what doesn't matter, and we avoid issues like this, #33256, etc.
💬 maflcko commented on pull request "ci: cd into BASE_BUILD_DIR for GetCMakeLogFiles":
(https://github.com/bitcoin/bitcoin/pull/33291#issuecomment-3249067521)
I haven't checked, but it seems plausible that I introduced this bug in commit fad191ff48b15832a90c19d560a7c0525c146be3, which fixed two other bugs.
Regardless, it seems better to specify the dir explicitly, than to silently/implicitly depend on it.
lgtm ACK 9b76eef2d2b42703e2a30952d4c3474b533e360a 💽
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -
...
(https://github.com/bitcoin/bitcoin/pull/33291#issuecomment-3249067521)
I haven't checked, but it seems plausible that I introduced this bug in commit fad191ff48b15832a90c19d560a7c0525c146be3, which fixed two other bugs.
Regardless, it seems better to specify the dir explicitly, than to silently/implicitly depend on it.
lgtm ACK 9b76eef2d2b42703e2a30952d4c3474b533e360a 💽
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -
...
🤔 janb84 reviewed a pull request: "build: set ENABLE_IPC to OFF when fuzzing"
(https://github.com/bitcoin/bitcoin/pull/33235#pullrequestreview-3180445284)
ACK af4156ab75565acc5a71b68e70da5e2cf407df80
PR sets the option `ENABLE_IPC` to `OFF` when building for fuzzing. This seems reasonable for now, because we do not have any fuzz testing on IPC code. Setting ENABLE_IPC` to `OFF` will reduce a dependency (capnp).
- build and tested ✅
(https://github.com/bitcoin/bitcoin/pull/33235#pullrequestreview-3180445284)
ACK af4156ab75565acc5a71b68e70da5e2cf407df80
PR sets the option `ENABLE_IPC` to `OFF` when building for fuzzing. This seems reasonable for now, because we do not have any fuzz testing on IPC code. Setting ENABLE_IPC` to `OFF` will reduce a dependency (capnp).
- build and tested ✅
💬 jmoik commented on issue "build: secp256k1 warnings not turned into errors in MSAN job":
(https://github.com/bitcoin/bitcoin/issues/33284#issuecomment-3249078560)
from CmakeLists.txt:
# The core_interface library aims to encapsulate common build flags.
# It is a usage requirement for all targets except for secp256k1, which
# gets its flags by other means.
We can simply add a section for WERROR to the cmake file just like for other flags like BUILD_TESTS, to inherit the WERROR setting.
(https://github.com/bitcoin/bitcoin/issues/33284#issuecomment-3249078560)
from CmakeLists.txt:
# The core_interface library aims to encapsulate common build flags.
# It is a usage requirement for all targets except for secp256k1, which
# gets its flags by other means.
We can simply add a section for WERROR to the cmake file just like for other flags like BUILD_TESTS, to inherit the WERROR setting.
💬 jesterhodl commented on pull request "Release: 30.0 translations update":
(https://github.com/bitcoin/bitcoin/pull/33275#issuecomment-3249083029)
> checkpoints
Don't see it yet, I suppose it needs a sync?
<img width="587" height="187" alt="image" src="https://github.com/user-attachments/assets/9efcb5a1-8b8c-4544-ab53-af574f2784c7" />
(https://github.com/bitcoin/bitcoin/pull/33275#issuecomment-3249083029)
> checkpoints
Don't see it yet, I suppose it needs a sync?
<img width="587" height="187" alt="image" src="https://github.com/user-attachments/assets/9efcb5a1-8b8c-4544-ab53-af574f2784c7" />
💬 maflcko commented on pull request "build: suggest -DENABLE_IPC=OFF when missing capnp":
(https://github.com/bitcoin/bitcoin/pull/33290#issuecomment-3249086372)
> @maflcko the log is very verbose, but in indeed useful, so I opened #33291.
for reference, this specific warning was also printed without the verbose log: https://cirrus-ci.com/task/4516741763563520?logs=ci#L894 :
```
...
[03:43:58.798] CMake Error at /usr/lib/x86_64-linux-gnu/cmake/CapnProto/CapnProtoTargets.cmake:213 (add_executable):
[03:43:58.798] add_executable cannot create imported target "CapnProto::capnpc_cpp"
[03:43:58.798] because another target with the same name alre
...
(https://github.com/bitcoin/bitcoin/pull/33290#issuecomment-3249086372)
> @maflcko the log is very verbose, but in indeed useful, so I opened #33291.
for reference, this specific warning was also printed without the verbose log: https://cirrus-ci.com/task/4516741763563520?logs=ci#L894 :
```
...
[03:43:58.798] CMake Error at /usr/lib/x86_64-linux-gnu/cmake/CapnProto/CapnProtoTargets.cmake:213 (add_executable):
[03:43:58.798] add_executable cannot create imported target "CapnProto::capnpc_cpp"
[03:43:58.798] because another target with the same name alre
...
💬 theStack commented on issue "tracing: test `interface_usdt_net.py` fails due to garbage message type in `net:outbound_message` tracepoint":
(https://github.com/bitcoin/bitcoin/issues/33246#issuecomment-3249097001)
> > ```
> > Arguments: -8@x21 8@x24 8@[sp, 136] 8@[x0] 8@x1 8@x2
> > ```
>
> Are these the same if you build with `-DAPPEND_CXXFLAGS='-fno-inline'`?
They are quite different on a `-fno-inline` build:
```
Name: outbound_message
Location: 0x000000000012ed28, Base: 0x000000000111c6d8, Semaphore: 0x00000000016594d0
Arguments: -8@x23 8@x24 8@x25 8@x26 8@x27 8@x0
```
(https://github.com/bitcoin/bitcoin/issues/33246#issuecomment-3249097001)
> > ```
> > Arguments: -8@x21 8@x24 8@[sp, 136] 8@[x0] 8@x1 8@x2
> > ```
>
> Are these the same if you build with `-DAPPEND_CXXFLAGS='-fno-inline'`?
They are quite different on a `-fno-inline` build:
```
Name: outbound_message
Location: 0x000000000012ed28, Base: 0x000000000111c6d8, Semaphore: 0x00000000016594d0
Arguments: -8@x23 8@x24 8@x25 8@x26 8@x27 8@x0
```
💬 Sjors commented on pull request "build: suggest -DENABLE_IPC=OFF when missing capnp":
(https://github.com/bitcoin/bitcoin/pull/33290#issuecomment-3249117834)
Using `find_program` instead of `find_package` as suggested by an AI overlord, seems to do the trick.
Another issue was that the depends build also threw this warning, which I added a check for.
(https://github.com/bitcoin/bitcoin/pull/33290#issuecomment-3249117834)
Using `find_program` instead of `find_package` as suggested by an AI overlord, seems to do the trick.
Another issue was that the depends build also threw this warning, which I added a check for.
👋 Sjors's pull request is ready for review: "build: suggest -DENABLE_IPC=OFF when missing capnp"
(https://github.com/bitcoin/bitcoin/pull/33290)
(https://github.com/bitcoin/bitcoin/pull/33290)
💬 jmoik commented on issue "build: secp256k1 warnings not turned into errors in MSAN job":
(https://github.com/bitcoin/bitcoin/issues/33284#issuecomment-3249143680)
I actually cannot reproduce the exact warning of this macro, not on clang or g++. But adding an explicitly undefined variable produces a warning and is properly turned into an error with -DWERROR=ON after adding the inheritance.
(https://github.com/bitcoin/bitcoin/issues/33284#issuecomment-3249143680)
I actually cannot reproduce the exact warning of this macro, not on clang or g++. But adding an explicitly undefined variable produces a warning and is properly turned into an error with -DWERROR=ON after adding the inheritance.
💬 stickies-v commented on pull request "cmake: make missing Python interpreter behaviour more explicit":
(https://github.com/bitcoin/bitcoin/pull/33278#discussion_r2318903859)
> If they are independent, maybe give them independent default values?
Done, thanks. I used the default `BUILD_TESTS` value because I suspect in most cases if people don't want to build the unit tests, they also don't want to build the functional tests, but perhaps if we do want that logic it's best to have a `BUILD_TESTS` that acts like an umbrella setting, with `cmake_dependent_options` `BUILD_UNIT_TESTS` and `BUILD_FUNCTIONAL_TESTS`. That seems out of scope for this PR, so I've just change
...
(https://github.com/bitcoin/bitcoin/pull/33278#discussion_r2318903859)
> If they are independent, maybe give them independent default values?
Done, thanks. I used the default `BUILD_TESTS` value because I suspect in most cases if people don't want to build the unit tests, they also don't want to build the functional tests, but perhaps if we do want that logic it's best to have a `BUILD_TESTS` that acts like an umbrella setting, with `cmake_dependent_options` `BUILD_UNIT_TESTS` and `BUILD_FUNCTIONAL_TESTS`. That seems out of scope for this PR, so I've just change
...
💬 stickies-v commented on pull request "cmake: make missing Python interpreter behaviour more explicit":
(https://github.com/bitcoin/bitcoin/pull/33278#issuecomment-3249158729)
Force-pushed to default `BUILD_FUNCTIONAL_TESTS` to `ON` instead of to `BUILD_TESTS`, reducing behaviour change and addressing @purpleKarrot's [feedback](https://github.com/bitcoin/bitcoin/pull/33278#discussion_r2318148580).
(https://github.com/bitcoin/bitcoin/pull/33278#issuecomment-3249158729)
Force-pushed to default `BUILD_FUNCTIONAL_TESTS` to `ON` instead of to `BUILD_TESTS`, reducing behaviour change and addressing @purpleKarrot's [feedback](https://github.com/bitcoin/bitcoin/pull/33278#discussion_r2318148580).
👋 fanquake's pull request is ready for review: "[29.x] finalise v29.1"
(https://github.com/bitcoin/bitcoin/pull/33271)
(https://github.com/bitcoin/bitcoin/pull/33271)
💬 0xB10C commented on issue "tracing: test `interface_usdt_net.py` fails due to garbage message type in `net:outbound_message` tracepoint":
(https://github.com/bitcoin/bitcoin/issues/33246#issuecomment-3249195811)
These arguments translate to the `net:outbound_message` tracepoint arguments.
| arg | broken | `-fno-inline` working |
|-------------------------------------------|-------------|-----------------------|
| `pnode->GetId()` | -8@x21 | -8@x23 |
| `pnode->m_addr_name.c_str()` | 8@x24 | 8@x24 |
| `pnode->ConnectionTypeAsString().c_str()` | 8@[sp, 136] | 8@x25 |
|
...
(https://github.com/bitcoin/bitcoin/issues/33246#issuecomment-3249195811)
These arguments translate to the `net:outbound_message` tracepoint arguments.
| arg | broken | `-fno-inline` working |
|-------------------------------------------|-------------|-----------------------|
| `pnode->GetId()` | -8@x21 | -8@x23 |
| `pnode->m_addr_name.c_str()` | 8@x24 | 8@x24 |
| `pnode->ConnectionTypeAsString().c_str()` | 8@[sp, 136] | 8@x25 |
|
...
🤔 rkrux reviewed a pull request: "wallet: Identify transactions spending 0-value outputs, and add tests for anchor outputs in a wallet"
(https://github.com/bitcoin/bitcoin/pull/33268#pullrequestreview-3180181577)
Concept ACK 69eeb11bc585e92a3b56811c3251f13dba05aa5f
Agree with the intent. Nit in PR description because specifically `IsFromMe` is updated in the PR:
```diff
- One of the ways that the wallet would determine if a transaction belonged to the wallet was by checking
+ One of the ways that the wallet would determine if a transaction was sent from the wallet was by checking
```
(https://github.com/bitcoin/bitcoin/pull/33268#pullrequestreview-3180181577)
Concept ACK 69eeb11bc585e92a3b56811c3251f13dba05aa5f
Agree with the intent. Nit in PR description because specifically `IsFromMe` is updated in the PR:
```diff
- One of the ways that the wallet would determine if a transaction belonged to the wallet was by checking
+ One of the ways that the wallet would determine if a transaction was sent from the wallet was by checking
```
💬 rkrux commented on pull request "wallet: Identify transactions spending 0-value outputs, and add tests for anchor outputs in a wallet":
(https://github.com/bitcoin/bitcoin/pull/33268#discussion_r2318702489)
In 69eeb11bc585e92a3b56811c3251f13dba05aa5f "wallet: Add m_cached_from_me to cache "from me" status"
Maybe switch the order of the last 2 commits so that this commit also has coverage?
(https://github.com/bitcoin/bitcoin/pull/33268#discussion_r2318702489)
In 69eeb11bc585e92a3b56811c3251f13dba05aa5f "wallet: Add m_cached_from_me to cache "from me" status"
Maybe switch the order of the last 2 commits so that this commit also has coverage?
💬 rkrux commented on pull request "wallet: Identify transactions spending 0-value outputs, and add tests for anchor outputs in a wallet":
(https://github.com/bitcoin/bitcoin/pull/33268#discussion_r2318698691)
In 009b273df8ad8a7470276a31f3cb900e480aa99b "test: Test wallet 'from me' status change"
Are these necessary? The test passes without them even with a re-scan.
```diff
if confirm:
self.generate(self.nodes[0], 1, sync_fun=self.no_op)
- # Mock time forward and generate blocks so that the import does not rescan the transaction
- self.nodes[0].setmocktime(int(time.time()) + MAX_FUTURE_BLOCK_TIME + 1)
- self.generate(s
...
(https://github.com/bitcoin/bitcoin/pull/33268#discussion_r2318698691)
In 009b273df8ad8a7470276a31f3cb900e480aa99b "test: Test wallet 'from me' status change"
Are these necessary? The test passes without them even with a re-scan.
```diff
if confirm:
self.generate(self.nodes[0], 1, sync_fun=self.no_op)
- # Mock time forward and generate blocks so that the import does not rescan the transaction
- self.nodes[0].setmocktime(int(time.time()) + MAX_FUTURE_BLOCK_TIME + 1)
- self.generate(s
...
💬 rkrux commented on pull request "wallet: Identify transactions spending 0-value outputs, and add tests for anchor outputs in a wallet":
(https://github.com/bitcoin/bitcoin/pull/33268#discussion_r2318656200)
In 009b273df8ad8a7470276a31f3cb900e480aa99b "test: Test wallet 'from me' status change"
Probably can also assert on any detail entry being in send category after the descriptor is imported in the concerned wallet and not so before the import. Makes testing more explicit imho.
```diff
diff --git a/test/functional/wallet_listtransactions.py b/test/functional/wallet_listtransactions.py
index a19a1a32b1..0c60d4839d 100755
--- a/test/functional/wallet_listtransactions.py
+++ b/test/function
...
(https://github.com/bitcoin/bitcoin/pull/33268#discussion_r2318656200)
In 009b273df8ad8a7470276a31f3cb900e480aa99b "test: Test wallet 'from me' status change"
Probably can also assert on any detail entry being in send category after the descriptor is imported in the concerned wallet and not so before the import. Makes testing more explicit imho.
```diff
diff --git a/test/functional/wallet_listtransactions.py b/test/functional/wallet_listtransactions.py
index a19a1a32b1..0c60d4839d 100755
--- a/test/functional/wallet_listtransactions.py
+++ b/test/function
...