💬 maflcko commented on pull request "guix: update per-host disk-space estimates in build gate":
(https://github.com/bitcoin/bitcoin/pull/33889#discussion_r2536789722)
> I did notice discrepancies for darwin and mingw though, which I've attempted to correct for.

That is fine, but you'll have to properly explain the changes.

https://github.com/kevkevinpal/bitcoin/issues/200 could be an oversight where someone ran the build twice by accident?

💬 maflcko commented on pull request "test, refactor: Embedded ASMap [1/3]: Selected minor preparatory work":
(https://github.com/bitcoin/bitcoin/pull/33026#discussion_r2536798319)
The call should be fully optimized out anyway, no?

💬 Sjors commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#issuecomment-3546154209)
> OTOH, overhauling NewTemplate shouldn't be a blocker for supporting sv2 efficiently, so Approach ACK for this PR in the meantime.

Thanks, I opened https://github.com/stratum-mining/sv2-spec/issues/167 to continue that discussion.

>> replacing m_options.coinbase_output_script with a vector.

See https://github.com/bitcoin/bitcoin/pull/33890

💬 Sjors commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2536880741)
Done in the latest push.

💬 Sjors commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#issuecomment-3546216186)
I slightly simplified `ExtractCoinbaseTemplate` by having it assume that the dummy is always the first output. Also TIL about `| std::views::drop(1)`.

💬 janb84 commented on pull request "guix: update per-host disk-space estimates in build gate":
(https://github.com/bitcoin/bitcoin/pull/33889#discussion_r2536950754)
It was my remark, and I was still researching it. My Guix build is using GiB than before, but it's not related to 33181. I noticed it on that PR but a master compile (sans 33181) was also consuming more space than before.

💬 fanquake commented on pull request "depends: update xcb-util packages to latest versions":
(https://github.com/bitcoin/bitcoin/pull/33851#issuecomment-3546351254)
Guix Build (x86_64):
```bash
3a70d632167f9e57328d9b8373a5eb9936428148feddf5bc1f9834f412ea4248 guix-build-daafaef87fee/output/aarch64-linux-gnu/SHA256SUMS.part
ca1c7ad00632d0ee3fdfad498a7c6cb5246240a9e49c89bee508355ee7dbb832 guix-build-daafaef87fee/output/aarch64-linux-gnu/bitcoin-daafaef87fee-aarch64-linux-gnu-debug.tar.gz
a5a5c5a22159a912f573915727b5a4cdbb1b270fdf099f8b465c3ef940496e20 guix-build-daafaef87fee/output/aarch64-linux-gnu/bitcoin-daafaef87fee-aarch64-linux-gnu.tar.gz
a660c55
...

💬 laanwj commented on issue "guix build fails on RISC-V due to python-py-cpuinfo test failure":
(https://github.com/bitcoin/bitcoin/issues/33873#issuecomment-3546355023)
> It builds fine for me on an instance from the same provider:

Okay, now i'm confused. What operating system? Also debian forky/sid?

It could be that they got me a faulty server? i can't imagine having done anything wrong here, just followed basic GUIX build steps.

💬 laanwj commented on issue "guix build fails on RISC-V due to python-py-cpuinfo test failure":
(https://github.com/bitcoin/bitcoin/issues/33873#issuecomment-3546364000)
Looks like it stopped an error in the `-rust-1.65.0.drv.gz` build this night. The "faulty server" hypothesis definitely disproven 😄 Why do i always have this little luck with RISC-V devices lol.
```
...
patch-cargo-checksums: generate-checksums for vendor/winapi
patch-cargo-checksums: generate-checksums for vendor/windows-sys-0.28.0
patch-cargo-checksums: generate-checksums for vendor/windows-sys
patch-cargo-checksums: generate-checksums for vendor/windows_aarch64_msvc-0.28.0
Fatal glibc error
...

🚀 fanquake merged a pull request: "net: Remove unused `local_socket_bytes` variable in `CConnman::GetAddresses()`"
(https://github.com/bitcoin/bitcoin/pull/33894)

💬 hodlinator commented on pull request "build: Embedded ASMap [3/3]: Build binary dump header file":
(https://github.com/bitcoin/bitcoin/pull/28792#discussion_r2537150160)
Related: #33896

💬 hebasto commented on issue "guix build fails on RISC-V due to python-py-cpuinfo test failure":
(https://github.com/bitcoin/bitcoin/issues/33873#issuecomment-3546510385)
> > It builds fine for me on an instance from the same provider:
>
> Okay, now i'm confused. What operating system? Also debian forky/sid?

Yes, debian forky/sid.

👍 hodlinator approved a pull request: "clang-format: Set InsertNewlineAtEOF: true"
(https://github.com/bitcoin/bitcoin/pull/33896#pullrequestreview-3476584168)
ACK fa1bf6818f0910f997e5235a197ff51f2e18780d

Makes sense for this project to conform to the UNIXy style of ending all lines with `\n`.

Previous setting of having it `false` comes from 13f36c020f0329b5e975282b45292fdf2a495e31 which just added a bunch of newer settings to src/.clang-format with default clang-format values, rather than being a conscious decision by this project.

Have recently been discussing how GitHub and Git also seem to agree on this: https://github.com/bitcoin/bitcoin/pull/2
...

💬 Sjors commented on issue "IPC via TCP Sockets":
(https://github.com/bitcoin/bitcoin/issues/32802#issuecomment-3546616865)
RPC connections are not encrypted either and I'm not aware of any plans for changing that.

Maybe virtio socket support would be the easiest approach for getting Docker setups to work? That might be useful for RPC too.

💬 l0rinc commented on pull request "clang-format: Set InsertNewlineAtEOF: true":
(https://github.com/bitcoin/bitcoin/pull/33896#discussion_r2537251411)
llvm@17 has a `KeepEmptyLinesAtEOF: false` as well - added exactly to avoid the problem we're trying to avoid here: https://github.com/llvm/llvm-project/issues/56054
Should we make it explicit here?
```patch
diff --git a/src/.clang-format b/src/.clang-format
--- a/src/.clang-format (revision 9d5bad11b6cbf50c776f9e9a583ac1fb79271fe8)
+++ b/src/.clang-format (date 1763460129408)
@@ -123,7 +123,7 @@
IndentWidth: 4
IndentWrappedFunctionNames: false
InsertBraces: false
-InsertNewlineAtEOF:
...

💬 fanquake commented on pull request "build: Embedded ASMap [3/3]: Build binary dump header file":
(https://github.com/bitcoin/bitcoin/pull/28792#discussion_r2537289781)
> a new creation process

What is the "new creation process":
* Who is involved (and has the permissions needed to merge into the required repos).
* How many total people are required?
* Can it happen at anytime, or does it require coordination days ahead of time?
* What should happen if the process creates data that isn't usable?

💬 rustaceanrob commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#issuecomment-3546665825)
> moreover, I'm not sure what to expect in case getCoinbase doesn't exist? I guess capnp-rpc would bubble up some kind of error? does @rustaceanrob know?

I would assume a new client requesting `getCoinbase` of an old server would result in the [`ErrorKind::Unimplemented`](https://docs.rs/capnp/0.23.0/capnp/enum.ErrorKind.html). In the case of this response then a `getCoinbaseTx` could be used as a fallback.

As far as updating the `capnp` files in the Rust types, I can do so on a developmen
...

⚠️ Sjors opened an issue: "rfc: virtio-vsock for RPC and IPC"
(https://github.com/bitcoin/bitcoin/issues/33897)
> virtio-vsock provides a way for applications running on a guest VM and the host system to communicate with each other using the standard socket interface (`socket`, `connect`, `bind`, `listen`, `accept`). It defines a new socket address family (`AF_VSOCK`) and uses a (context id, port) pair of integers for identifying processes. The host system always has 2 as its context id while each guest VM is assigned a unique context id on startup.

https://chromium.googlesource.com/chromiumos/platform2/
...

💬 laanwj commented on issue "guix build fails on RISC-V due to python-py-cpuinfo test failure":
(https://github.com/bitcoin/bitcoin/issues/33873#issuecomment-3546710178)
Could also be a kernel bug:
```
[155604.743750] BUG: using smp_processor_id() in preemptible [00000000] code: guile/662593
[155604.751799] caller is debug_smp_processor_id+0x20/0x2a
[155604.757101] CPU: 3 PID: 662593 Comm: guile Not tainted 5.10.113-scw1 #1
[155604.763806] Call Trace:
[155604.766349] [<ffffffe0002040f0>] walk_stackframe+0x0/0x112
[155604.771928] [<ffffffe000fcd022>] show_stack+0x46/0x62
[155604.777075] [<ffffffe000fd6be2>] dump_stack_lvl+0x7a/0x9a
[155604.782567] [<ffffffe000fd6
...

💬 maflcko commented on pull request "clang-format: Set InsertNewlineAtEOF: true":
(https://github.com/bitcoin/bitcoin/pull/33896#discussion_r2537358027)
> llvm@17 has a `KeepEmptyLinesAtEOF: false` as well - added exactly to avoid the problem we're trying to avoid here: [llvm/llvm-project#56054](https://github.com/llvm/llvm-project/issues/56054)
> Should we make it explicit here?

Not sure I understand the problem you are referring to. `InsertNewlineAtEOF` is already set to `true` in this pull request. Can you add exact steps to reproduce the problem?