🤔 glozow reviewed a pull request: "cluster mempool: extend DepGraph functionality"
(https://github.com/bitcoin/bitcoin/pull/30857#pullrequestreview-2360504869)
ACK 0b3ec8c59b2b6d598531cd4e688eb276e597c825, reviewed range-diff from aab53ddcd8fcbc3c0be0da9383f8e06abe5badda and `clusterlin_depgraph_sim`

💬 glozow commented on pull request "cluster mempool: extend DepGraph functionality":
(https://github.com/bitcoin/bitcoin/pull/30857#discussion_r1795548751)
Nice, no more naming clash for `Cluster` in my mind

🚀 glozow merged a pull request: "cluster mempool: extend DepGraph functionality"
(https://github.com/bitcoin/bitcoin/pull/30857)

⚠️ maflcko opened an issue: " scriptpubkeyman fuzz target TopUp is slow (3/N)"
(https://github.com/bitcoin/bitcoin/issues/31066)
Follow-up to https://github.com/bitcoin/bitcoin/issues/30476 and https://github.com/bitcoin/bitcoin/issues/30541:

Found by OSS-Fuzz: https://issues.oss-fuzz.com/issues/369374541

Probably a duplicate of, or similarity with https://github.com/bitcoin/bitcoin/issues/30498

File: [clusterfuzz-testcase-scriptpubkeyman-6582005385461760.not.txt](https://github.com/user-attachments/files/17330258/clusterfuzz-testcase-scriptpubkeyman-6582005385461760.not.txt)



```
$ FUZZ=scriptpubkeyman pe
...

💬 vasild commented on issue "build: RFC Coverage build type":
(https://github.com/bitcoin/bitcoin/issues/31047#issuecomment-2405471187)
> I liked the summary stats per folder produced by the current approach, but if others like other stuff better, I don't mind.

Maybe I misunderstand, but somehow the above implies that we have to commit to one and give up on the other method. But one can create gcc or clang coverages regardless of what is integrated into the cmake build system. That integration would be just a convenience and we could have no integration, or just gcc (the current `master`), or just clang or both gcc and clang.
...

👋 danielabrozzoni's pull request is ready for review: "rest: Support transaction broadcast in REST interface"
(https://github.com/bitcoin/bitcoin/pull/31065)

👍 vasild approved a pull request: "netinfo: add peer services column and outbound-only peers list"
(https://github.com/bitcoin/bitcoin/pull/30930#pullrequestreview-2360849799)
ACK 683b558a020f1632b0a3cbdaa165adbd1423281c

💬 vasild commented on pull request "netinfo: add peer services column and outbound-only peers list":
(https://github.com/bitcoin/bitcoin/pull/30930#discussion_r1795748339)
Before these numbers somehow designated increasing verbosity and more columns. Whereas now the newly added "5" does not add more columns, but _removes rows_ compared to "4".

I am not sure how to improve that. It is a different dimension, maybe use a different option "outonly". Then one could have either one of the 0-4 modes in "outonly" mode or in full mode (in + out).

(non-blocker, just something to consider)

💬 maflcko commented on issue "build: RFC Coverage build type":
(https://github.com/bitcoin/bitcoin/issues/31047#issuecomment-2405561186)
Yeah. I guess I don't really mind either way. As long as there is at least one documented, tested and working solution.

📝 maflcko opened a pull request: "test: Print CompletedProcess object on error"
(https://github.com/bitcoin/bitcoin/pull/31067)
It would be good to know the output on `Error parsing command output`. Otherwise test failures are meaningless: https://github.com/bitcoin/bitcoin/issues/30792#issuecomment-2325911157

Fix it by just printing the full `CompletedProcess` object.

Also, use the modern `subprocess.run` to simplify the code.

💬 jonatack commented on pull request "netinfo: add peer services column and outbound-only peers list":
(https://github.com/bitcoin/bitcoin/pull/30930#discussion_r1795801949)
I see, but think it's simpler and more convenient for the user (i.e. me) to type 5 rather than 4, or vice versa.

I did maintain the "high details levels = maximum" behavior preferred by @laanwj in https://github.com/bitcoin/bitcoin/pull/21192 for values above 5.

💬 jonatack commented on pull request "netinfo: add peer services column and outbound-only peers list":
(https://github.com/bitcoin/bitcoin/pull/30930#discussion_r1795804652)
Also, I find myself only using level 4 or 5. Perhaps other reviewers would prefer the option to apply, as you suggest, to all the other levels. Happy to do that (here or in a follow-up) if people prefer.

💬 sipa commented on pull request "Cluster linearization: separate tests from tests-of-tests":
(https://github.com/bitcoin/bitcoin/pull/30605#issuecomment-2405669097)
Rebased after the merge of #30857.

⚠️ ArmchairCryptologist opened an issue: "Consider making 27.x Long-Term Support (LTS)"
(https://github.com/bitcoin/bitcoin/issues/31068)
### Please describe the feature you'd like to see added.

As mentioned in the patch notes for 28.x, since this release drops support for glibc older than 2.31, it will not run on several widely used Linux distros, including RHEL 8 and the RHELatives that base off of this, such as AlmaLinux 8 and Rocky Linux 8.

In case anyone is unaware, RHEL 8 and its derivatives are still supported, and will in fact not be EOL until 2029. While I don't have exact install numbers, I would not be surprised if
...

💬 TheCharlatan commented on pull request "kernel: Handle fatal errors through return values":
(https://github.com/bitcoin/bitcoin/pull/29642#issuecomment-2405736255)
I'm going to leave this in draft a little while longer. I think we should first focus on ryanofsky's #29700 though. If that is merged, there is always opportunity to revisit the approach taken here.

🤔 instagibbs reviewed a pull request: "p2p: When close to the tip, download blocks in parallel from additional peers to prevent stalling"
(https://github.com/bitcoin/bitcoin/pull/29664#pullrequestreview-2360728484)
I took a bit of time to work on test coverage, with a rough branch here: https://github.com/instagibbs/bitcoin/commits/mzumsande_202403_near_tip_stalling/

last commit needs some clean up, but demonstrates some of the interplay of parallel blocks both compact and non-compact

💬 instagibbs commented on pull request "p2p: When close to the tip, download blocks in parallel from additional peers to prevent stalling":
(https://github.com/bitcoin/bitcoin/pull/29664#discussion_r1795674296)
It'd be better if this test(and others) actually complete the "chain sync" successfully up to known headers to e2e the test case. Perhaps it requests the next stalled block correctly, but it could fall over after.

💬 maflcko commented on issue "Consider making 27.x Long-Term Support (LTS)":
(https://github.com/bitcoin/bitcoin/issues/31068#issuecomment-2405740263)
My understanding is that RHEL-8-like are still supported, if you manage to run a recent enough compiler on them and use that to compile Bitcoin Core yourself.

💬 maflcko commented on issue "ci: failure in win64 unit tests":
(https://github.com/bitcoin/bitcoin/issues/30792#issuecomment-2405785925)
Couldn't reproduce so far after https://github.com/bitcoin/bitcoin/pull/31067, but I'll keep trying.

💬 mzumsande commented on pull request "p2p: When close to the tip, download blocks in parallel from additional peers to prevent stalling":
(https://github.com/bitcoin/bitcoin/pull/29664#issuecomment-2405892467)
> I took a bit of time to work on test coverage, with a rough branch here: https://github.com/instagibbs/bitcoin/commits/mzumsande_202403_near_tip_stalling/
>
> last commit needs some clean up, but demonstrates some of the interplay of parallel blocks both compact and non-compact

Thanks!
I also worked on this yesterday/today and wrote a similar test, but added that as an `at_tip_stalling` subtest to `p2p_ibd_stalling.py` - while your test covering the logic in a similar way is in `p2p_co
...