💬 alexanderwiederin commented on pull request "assumeutxo (2)":
(https://github.com/bitcoin/bitcoin/pull/27596#discussion_r1210212400)
Missing the second "t" of "Starting"
```suggestion
echo "-- Starting the server node to provide blocks to the client node..."
```
(https://github.com/bitcoin/bitcoin/pull/27596#discussion_r1210212400)
Missing the second "t" of "Starting"
```suggestion
echo "-- Starting the server node to provide blocks to the client node..."
```
💬 hebasto commented on pull request "guix: fix CURL disable flag in osslsigncode":
(https://github.com/bitcoin/bitcoin/pull/27779#issuecomment-1568365679)
Btw, do we still need this line https://github.com/bitcoin/bitcoin/blob/f467b28ac35add304442f30c2a05ef5d9df496e2/contrib/guix/manifest.scm#L14 at all?
(https://github.com/bitcoin/bitcoin/pull/27779#issuecomment-1568365679)
Btw, do we still need this line https://github.com/bitcoin/bitcoin/blob/f467b28ac35add304442f30c2a05ef5d9df496e2/contrib/guix/manifest.scm#L14 at all?
💬 pablomartin4btc commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#issuecomment-1568366234)
> I'm in favour of doing the `replySent` refactoring in a separate commit, but it makes more sense to have that be the first commit imo, to avoid adding logic and then removing it in the very next commit.
Yeah, true, I agree... let me revert the order of the commits.
(https://github.com/bitcoin/bitcoin/pull/27253#issuecomment-1568366234)
> I'm in favour of doing the `replySent` refactoring in a separate commit, but it makes more sense to have that be the first commit imo, to avoid adding logic and then removing it in the very next commit.
Yeah, true, I agree... let me revert the order of the commits.
💬 pablomartin4btc commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1210218266)
Let me check again when I do revert the order of the commits, when I tested before those were needed as the fuzz was complaining about memory leaks.
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1210218266)
Let me check again when I do revert the order of the commits, when I tested before those were needed as the fuzz was complaining about memory leaks.
💬 willcl-ark commented on issue "Libbitcoinkernel Project Tracking":
(https://github.com/bitcoin/bitcoin/issues/27587#issuecomment-1568419077)
Would it make sense to update the project page to https://github.com/orgs/bitcoin/projects/3/views/1 (which if I'm not mistaken seems to be the current one)?
Could keep a link to the old project https://github.com/bitcoin/bitcoin/projects/18 for reference?
(https://github.com/bitcoin/bitcoin/issues/27587#issuecomment-1568419077)
Would it make sense to update the project page to https://github.com/orgs/bitcoin/projects/3/views/1 (which if I'm not mistaken seems to be the current one)?
Could keep a link to the old project https://github.com/bitcoin/bitcoin/projects/18 for reference?
💬 Sjors commented on issue "Spurious (?) valgrind failure for p2p_compactblocks.py":
(https://github.com/bitcoin/bitcoin/issues/27741#issuecomment-1568421101)
I made a note to try with clang instead.
(https://github.com/bitcoin/bitcoin/issues/27741#issuecomment-1568421101)
I made a note to try with clang instead.
💬 Sjors commented on issue "rpc_getblockfrompeer.py intermittent failure: assert_equal(pruneheight, 248); not(249 == 248)":
(https://github.com/bitcoin/bitcoin/issues/27749#issuecomment-1568429590)
cc @fjahr since he worked on the prune part of this test.
(https://github.com/bitcoin/bitcoin/issues/27749#issuecomment-1568429590)
cc @fjahr since he worked on the prune part of this test.
👍 furszy approved a pull request: "wallet, bench: Move commonly used functions to their own file and fix a bug"
(https://github.com/bitcoin/bitcoin/pull/27666#pullrequestreview-1450932691)
ACK c61d3f02
(https://github.com/bitcoin/bitcoin/pull/27666#pullrequestreview-1450932691)
ACK c61d3f02
💬 furszy commented on pull request "wallet, bench: Move commonly used functions to their own file and fix a bug":
(https://github.com/bitcoin/bitcoin/pull/27666#discussion_r1210268191)
Not for this PR as it touches the wallet internals but the duplicated `AddToWallet` calls shouldn't be needed if the wallet wtx state is equal to the one in the event.
(https://github.com/bitcoin/bitcoin/pull/27666#discussion_r1210268191)
Not for this PR as it touches the wallet internals but the duplicated `AddToWallet` calls shouldn't be needed if the wallet wtx state is equal to the one in the event.
💬 Sjors commented on pull request "build: produce a .zip for macOS distribution":
(https://github.com/bitcoin/bitcoin/pull/27099#issuecomment-1568433362)
Happy to leave that to later PR.
tACK e82e73103ce81159f6f1a51408ce5411b88a12b2
(https://github.com/bitcoin/bitcoin/pull/27099#issuecomment-1568433362)
Happy to leave that to later PR.
tACK e82e73103ce81159f6f1a51408ce5411b88a12b2
💬 TheCharlatan commented on issue "Libbitcoinkernel Project Tracking":
(https://github.com/bitcoin/bitcoin/issues/27587#issuecomment-1568433462)
Re https://github.com/bitcoin/bitcoin/issues/27587#issuecomment-1568419077
> Would it make sense to update the project page to https://github.com/orgs/bitcoin/projects/3/views/1 (which if I'm not mistaken seems to be the current one)?
Thanks for the notice, updated to the new one.
> Could keep a link to the old project https://github.com/bitcoin/bitcoin/projects/18 for reference?
There is no useful extra information on the old board that is not in the new one, so I don't thi
...
(https://github.com/bitcoin/bitcoin/issues/27587#issuecomment-1568433462)
Re https://github.com/bitcoin/bitcoin/issues/27587#issuecomment-1568419077
> Would it make sense to update the project page to https://github.com/orgs/bitcoin/projects/3/views/1 (which if I'm not mistaken seems to be the current one)?
Thanks for the notice, updated to the new one.
> Could keep a link to the old project https://github.com/bitcoin/bitcoin/projects/18 for reference?
There is no useful extra information on the old board that is not in the new one, so I don't thi
...
💬 fanquake commented on pull request "wallet, bench: Move commonly used functions to their own file and fix a bug":
(https://github.com/bitcoin/bitcoin/pull/27666#issuecomment-1568469989)
@furszy looks like you ACK'd the wrong commit here.
(https://github.com/bitcoin/bitcoin/pull/27666#issuecomment-1568469989)
@furszy looks like you ACK'd the wrong commit here.
💬 instagibbs commented on issue "24.0.1 crash on restart":
(https://github.com/bitcoin/bitcoin/issues/27088#issuecomment-1568481549)
no intention to chase after this, close?
(https://github.com/bitcoin/bitcoin/issues/27088#issuecomment-1568481549)
no intention to chase after this, close?
🚀 fanquake merged a pull request: "kernel: Remove util/system from kernel library, interface_ui from validation."
(https://github.com/bitcoin/bitcoin/pull/27636)
(https://github.com/bitcoin/bitcoin/pull/27636)
💬 furszy commented on pull request "wallet, bench: Move commonly used functions to their own file and fix a bug":
(https://github.com/bitcoin/bitcoin/pull/27666#issuecomment-1568486957)
oops, fixed. That was the one from the comment. Thanks @fanquake.
(https://github.com/bitcoin/bitcoin/pull/27666#issuecomment-1568486957)
oops, fixed. That was the one from the comment. Thanks @fanquake.
💬 MarcoFalke commented on pull request "ci: Prune dangling images on RESTART_CI_DOCKER_BEFORE_RUN":
(https://github.com/bitcoin/bitcoin/pull/27777#discussion_r1210324682)
Do dangling image (layer)s have a label? Anyway, this isn't for local runs, only for the persistent runners, guarded via `RESTART_CI_DOCKER_BEFORE_RUN`. Happy to rename `RESTART_CI_DOCKER_BEFORE_RUN` to `DANGER_RESTART_CI_DOCKER_BEFORE_RUN`?
(https://github.com/bitcoin/bitcoin/pull/27777#discussion_r1210324682)
Do dangling image (layer)s have a label? Anyway, this isn't for local runs, only for the persistent runners, guarded via `RESTART_CI_DOCKER_BEFORE_RUN`. Happy to rename `RESTART_CI_DOCKER_BEFORE_RUN` to `DANGER_RESTART_CI_DOCKER_BEFORE_RUN`?
✅ MarcoFalke closed an issue: "24.0.1 crash on restart"
(https://github.com/bitcoin/bitcoin/issues/27088)
(https://github.com/bitcoin/bitcoin/issues/27088)
👍 dergoegge approved a pull request: "ci: Enable float-divide-by-zero check"
(https://github.com/bitcoin/bitcoin/pull/27778#pullrequestreview-1451049584)
ACK fa3ab4520317f48d4700b81dab023c4e639bbd68
(https://github.com/bitcoin/bitcoin/pull/27778#pullrequestreview-1451049584)
ACK fa3ab4520317f48d4700b81dab023c4e639bbd68
💬 fanquake commented on pull request "ci, iwyu: Update mappings":
(https://github.com/bitcoin/bitcoin/pull/27710#discussion_r1210341923)
What's the reason for leaving certain mappings out of this list, i.e `#include <boost/operators.hpp>`?
I'm guessing it's because those same includes are recommended for non-test code, and mapping them to Boost Test here would just produce nonsense recommendations for other files? If so, how are you planning on working around that in future? If not, or that isn't a problem, why not do the mapping now?
(https://github.com/bitcoin/bitcoin/pull/27710#discussion_r1210341923)
What's the reason for leaving certain mappings out of this list, i.e `#include <boost/operators.hpp>`?
I'm guessing it's because those same includes are recommended for non-test code, and mapping them to Boost Test here would just produce nonsense recommendations for other files? If so, how are you planning on working around that in future? If not, or that isn't a problem, why not do the mapping now?
👍 stickies-v approved a pull request: "refactor: Add [[nodiscard]] where ignoring a Result return type is an error"
(https://github.com/bitcoin/bitcoin/pull/27774#pullrequestreview-1451069282)
ACK fa5680b7520c340952239c4e25ebe505d16c7c39
I looked at all sites where `Result` is either of type `void` or some other descriptive/status type, and could not find any other places where the return value can never be ignored.
(https://github.com/bitcoin/bitcoin/pull/27774#pullrequestreview-1451069282)
ACK fa5680b7520c340952239c4e25ebe505d16c7c39
I looked at all sites where `Result` is either of type `void` or some other descriptive/status type, and could not find any other places where the return value can never be ignored.