💬 maflcko commented on pull request "[PoC] ci: Add FreeBSD GitHub Actions job":
(https://github.com/bitcoin/bitcoin/pull/30164#issuecomment-2175196978)
Looks good to merge to allow devs to enable this for testing in their fork. However, it should not be enabled in this repo, because:

* CI resources are limited, so only tasks that find meaningful errors regularly should be enabled.
* Albeit this seems fine (https://github.com/bitcoin/bitcoin/pull/30164#issuecomment-2130109577), I think adding third-party actions should be limited as well.

💬 maflcko commented on pull request "ci: move ASan job to GitHub Actions from Cirrus CI":
(https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1636810573)
nit: could you link to a failing run? Just to double check that `CI_FAILFAST_TEST_LEAVE_DANGLING` works?

🤔 maflcko reviewed a pull request: "ci: move ASan job to GitHub Actions from Cirrus CI"
(https://github.com/bitcoin/bitcoin/pull/30193#pullrequestreview-2113589885)
found a nit

💬 maflcko commented on pull request "ci: move ASan job to GitHub Actions from Cirrus CI":
(https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1636804002)
nit: Can remove this.

⚠️ rob-scheepens opened an issue: "Porting bcc tools to libbpf"
(https://github.com/bitcoin/bitcoin/issues/30298)
@B10C: reviving this old discussion from some two years ago:

@rob-scheepens agree that BPF CO-RE and libbpf is the way to go for future tracing programs. I've looked into this a while ago, but it seems libbpf doesn't support USDT tracepoints yet (see https://github.com/iovisor/bcc/issues/3007). However, there was a mention of a soon to be open sourced libusdt library developed and used in production at Meta by @anakryiko [here](https://lore.kernel.org/bpf/CAEf4BzYRLxzVHw00DUphqq
...

💬 Sjors commented on pull request "contrib: add tool to convert compact-serialized UTXO set to SQLite database":
(https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-2175491752)
Just tried with the mainnet snapshot from #28553:

```
sha256sum ../utxo-snapshots/utxo-840000.dat
9db649785fcddd8b1fe83a5009fe5c9be1901e8c322298cacc8a2d96ace4807e ../utxo-snapshots/utxo-840000.dat

contrib/utxo-tools/utxo_to_sqlite.py ../utxo-snapshots/utxo-840000.dat ../utxo-snapshots/utxo-840000.sqlite
UTXO Snapshot for Mainnet at block height 840000 [0000000000000000...], contains 176948713 coins
Traceback (most recent call last):
File "/home/sjors/dev/bitcoin/contrib/utxo-tools/
...

💬 TheCharlatan commented on pull request "kernel: De-globalize validation caches":
(https://github.com/bitcoin/bitcoin/pull/30141#issuecomment-2175538120)
Rebased 5b1576bbc664a07e00b5528e13c1928df9bc9b0c -> 63923c8da686da42f522771f338ea8f2a4f4e568 ([noGlobalScriptCache_2](https://github.com/TheCharlatan/bitcoin/tree/noGlobalScriptCache_2) -> [noGlobalScriptCache_3](https://github.com/TheCharlatan/bitcoin/tree/noGlobalScriptCache_3), [compare](https://github.com/TheCharlatan/bitcoin/compare/noGlobalScriptCache_2..noGlobalScriptCache_3))

* Fixed conflict with #30058

💬 theStack commented on pull request "contrib: add tool to convert compact-serialized UTXO set to SQLite database":
(https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-2175547170)
@Sjors: Thanks for testing. Interesting, IIUC it's not possible to compress the serialization of a not-on-the-curve-pubkey, so I strongly assume there must be a bug somewhere in the `decompress_pubkey` routine. Will investigate in a bit, and put the PR into draft state until this is fixed.

> Ideally we'd test this script against every UTXO ever created, but extracting those efficiently requires its own raw block file parsing script :-)

Agree that would be very nice.

📝 theStack converted_to_draft a pull request: "contrib: add tool to convert compact-serialized UTXO set to SQLite database"
(https://github.com/bitcoin/bitcoin/pull/27432)
## Problem description

There is demand from users to get the UTXO set in form of a SQLite database (#24628). Bitcoin Core currently only supports dumping the UTXO set in a binary _compact-serialized_ format, which was crafted specifically for AssumeUTXO snapshots (see PR #16899), with the primary goal of being as compact as possible. Previous PRs tried to extend the `dumptxoutset` RPC with new formats, either in human-readable form (e.g. #18689, #24202), or most recently, directly as SQLite d
...

💬 alfonsoromanz commented on pull request "test: add validation for gettxout RPC response":
(https://github.com/bitcoin/bitcoin/pull/30226#discussion_r1644090971)
Done. Thanks

💬 alfonsoromanz commented on pull request "test: add validation for gettxout RPC response":
(https://github.com/bitcoin/bitcoin/pull/30226#discussion_r1644093301)
Yeah, I agree. I was following the same log structure used by other tests in this file. I changed it to `"Validating gettxout RPC response"`. Let me know if that's better. Thanks

💬 0xB10C commented on issue "Porting bcc tools to libbpf":
(https://github.com/bitcoin/bitcoin/issues/30298#issuecomment-2175564019)
I've been extensively using libbpf (& the libbpf-rs Rust crate) with the Bitcoin Core USDT tracepoints in https://github.com/0xB10C/peer-observer. I would be happy to see the tools being ported and would help to review a port. That being said, the tools (`contrinb/tracing/*`) could also be extracted to a `tracing-tools` repository to be maintained (and tested against Bitcoin Core) there.

More important than the tools is IMO an elegant way of getting rid of the bcc Python dependency, which ha
...

💬 Sjors commented on pull request "Support self-hosted Cirrus workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29274#discussion_r1644119042)
It's indeed a custom variable like `NO_ARM`. I moved the explanation of `NO_BRANCH` up in the documentation. Leaving only the explanation of `skip` vs. `only_if` here, which I also reworded.

💬 Sjors commented on pull request "Support self-hosted Cirrus workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29274#discussion_r1644123429)
Updated.

It serves the same purpose as `NO_BRANCH` on Cirrus, expect that I couldn't find a way to make that behaviour opt-in on Github CI.

💬 Sjors commented on pull request "Support self-hosted Cirrus workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29274#issuecomment-2175605000)
Rebased after #30193, which removes "noble" as a machine type. I previously already removed `NO_NOBLE`, see https://github.com/bitcoin/bitcoin/pull/29274#issuecomment-2134764402. The rebase merely impacts the documented list of persistent workers, which this PR moves.

Addressed review comments.

💬 Sjors commented on pull request "Support self-hosted Cirrus workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29274#discussion_r1644128922)
I moved 063ea4e0da9e1c06cc0f4aec97a03abac66ae59f to be right after 8259a13954878fd6188bb218c3b7320385516596 and expanded the commit message to explain why they don't use the same mechanism.

📝 m3dwards opened a pull request: "ci: remove unused bcc variable from workflow"
(https://github.com/bitcoin/bitcoin/pull/30299)
Fixes https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1636804002

💬 m3dwards commented on pull request "ci: move ASan job to GitHub Actions from Cirrus CI":
(https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1644131995)
https://github.com/bitcoin/bitcoin/pull/30299

💬 Sjors commented on pull request "Support self-hosted Cirrus workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29274#discussion_r1644133891)
Improved the comment, see below.

🚀 fanquake merged a pull request: "Revert "contrib: macdeploy: monkey-patch gen-sdk to be deterministic""
(https://github.com/bitcoin/bitcoin/pull/30282)