👋 tdb3's pull request is ready for review: "rpc: add `revelant_blocks` to `scanblocks status`"
(https://github.com/bitcoin/bitcoin/pull/30713)

💬 tdb3 commented on pull request "rpc: add `revelant_blocks` to `scanblocks status`":
(https://github.com/bitcoin/bitcoin/pull/30713#issuecomment-2339214391)
Will add release notes when incorporating reviewer comments.

💬 tdb3 commented on pull request "rpc: add `revelant_blocks` to `scanblocks status`":
(https://github.com/bitcoin/bitcoin/pull/30713#discussion_r1750990127)
While leaving `scanblocks()` without resetting `g_relevant_blocks` isn't ideal, resetting `g_relevant_blocks` just before `BlockFiltersScanReserver` is used by the `start` branch seemed to be a good way to prevent `status` from accidentally seeing an empty `g_relevant_blocks` (at least in common cases). Please let me know if I'm overlooking a likely concurrency case, and it can be adjusted.

📝 theStack opened a pull request: "build: drop obj/ subdirectory for generated build.h"
(https://github.com/bitcoin/bitcoin/pull/30856)
As indicated by the TODO, the obj subdirectory is not needed anymore now for the generated build.h header, since autotools are gone and we don't have in-source builds anymore.

💬 mzumsande commented on pull request "rpc, rest: Improve block rpc error handling, check header before attempting to read block data.":
(https://github.com/bitcoin/bitcoin/pull/30410#discussion_r1751038732)
I can break this up, but I think the suggestion doesn't work because we still need to feed the result into `have_undo` so that if `UndoReadFromDisk` fails for an unexpected reason, we don't attempt to access `blockUndo` below and segfault.

💬 mzumsande commented on pull request "rpc, rest: Improve block rpc error handling, check header before attempting to read block data.":
(https://github.com/bitcoin/bitcoin/pull/30410#discussion_r1751038941)
done

💬 mzumsande commented on pull request "rpc, rest: Improve block rpc error handling, check header before attempting to read block data.":
(https://github.com/bitcoin/bitcoin/pull/30410#discussion_r1751039102)
renamed to `CheckBlockDataAvailability()`

💬 mzumsande commented on pull request "rpc, rest: Improve block rpc error handling, check header before attempting to read block data.":
(https://github.com/bitcoin/bitcoin/pull/30410#issuecomment-2339321767)
[041b78c ](https://github.com/bitcoin/bitcoin/commit/041b78ccede9974117dac5d8623fedec2f32471d)to [92236f4](https://github.com/bitcoin/bitcoin/commit/92236f43ff92c931f3a099e03d7851b890bff263): addressed feedback by @fjahr

📝 sipa opened a pull request: "cluster mempool: extend DepGraph (multiple dependencies, removing transactions, parents/children)"
(https://github.com/bitcoin/bitcoin/pull/30857)
This adds:
* `DepGraph::AddDependencies` to add 0 or more dependencies to a single transaction at once (identical to calling `DepGraph::AddDependency` once for each, but more efficient).
* `DepGraph::RemoveTransactions` to remove 0 or more transactions from a depgraph.
* `DepGraph::GetReducedParents` (and `DepGraph::GetReducedChildren`) to get the (reduced) direct parents a children of a transaction in a depgraph.

This is the result of fleshing out the design for the "intermediate layer" (
...

⚠️ Freks24 opened an issue: "Fishy F g"
(https://github.com/bitcoin/bitcoin/issues/30858)
Fish he to her try hit u rh F my F re try

💬 Freks24 commented on issue "Fishy F g":
(https://github.com/bitcoin/bitcoin/issues/30858#issuecomment-2339451319)
Hi

✅ achow101 closed an issue: "Fishy F g"
(https://github.com/bitcoin/bitcoin/issues/30858)

:lock: achow101 locked an issue: "Fishy F g"
(https://github.com/bitcoin/bitcoin/issues/30858)

📝 LarryRuane opened a pull request: "doc: cmake: prepend "build" to functional/test_runner.py"
(https://github.com/bitcoin/bitcoin/pull/30859)
This is a small follow-on to #30741. Also, improve the error message if someone runs the functional tests the old way (outside of the build directory).

💬 LarryRuane commented on pull request "doc: cmake: prepend "build" to functional/test_runner.py":
(https://github.com/bitcoin/bitcoin/pull/30859#issuecomment-2339578313)
This patch would have helped me; I'm new to `cmake`; after building it for the first time, I tried to run the functional tests (the way I was used to), and it failed in a strange way:
```
$ test/functional/test_runner.py
Traceback (most recent call last):
File "/sd/g/bitcoin/test/functional/test_runner.py", line 950, in <module>
main()
File "/sd/g/bitcoin/test/functional/test_runner.py", line 465, in main
config.read_file(open(configfile, encoding="utf8"))

...

🤔 tdb3 reviewed a pull request: "doc: cmake: prepend "build" to functional/test_runner.py"
(https://github.com/bitcoin/bitcoin/pull/30859#pullrequestreview-2291346092)
Thanks for noticing this. I'd support the documentation change without changing the python programs.

💬 tdb3 commented on pull request "doc: cmake: prepend "build" to functional/test_runner.py":
(https://github.com/bitcoin/bitcoin/pull/30859#discussion_r1751241259)
This extra line seems like overkill if the proceeding line is being updated to include "build"

💬 tdb3 commented on pull request "doc: cmake: prepend "build" to functional/test_runner.py":
(https://github.com/bitcoin/bitcoin/pull/30859#discussion_r1751243701)
Seems like it might be enough to update the instructions rather than change `test_framework.py` or `test_runner.py`

💬 achow101 commented on issue "Increasing self-hosted runner raw performance":
(https://github.com/bitcoin/bitcoin/issues/30852#issuecomment-2339623497)
Not really that much faster: https://cirrus-ci.com/build/5557255590903808, but possibly also misconfigured as everything was setup to run on that one machine simultaneously, although it should enough cores and memory.

💬 maflcko commented on issue "Increasing self-hosted runner raw performance":
(https://github.com/bitcoin/bitcoin/issues/30852#issuecomment-2339651980)
Hmm, you could also try to re-run the tasks individually to see the best possible performance (which is what was tested above as well).

Otherwise, my suggestion would be to go with one of the AMD CPUs mentioned above. (I can give this a try in the coming days)