dpc

You can use `-L` (like `nix build -L ...`) to capture full output. Oftentimes 10 last lines is not enough to tell what's wrong.

``` reasponse -> response ```

``` [profile.release] debug = "line-tables-only" ``` and ``` [target.x86_64-unknown-linux-gnu] rustflags = ["-C", "link-arg=-Wl,--compress-debug-sections=zlib"] ``` is a combo that became available in some recent Rust release I've been using nowadays that...

> This can be fixed with -- --test-threads=2. Shall we add? Why not increase [bitcoind's rpc threads and work queue](https://github.com/fedimint/fedimint/blob/32bac957b23c0facfaff32baaa427d4898bce06d/devimint/src/cfg/bitcoin.conf#L9C10-L10C10) from the potato-like defaults instead?

So just the dev shells, no crane etc.? Seems reasonable. Dev shells are like 80% of benefits for very little Nix involvment.

> 64 threads is way too much. I think the ideal is to have 1 thread per CPU core. I think a good compromise is 4 (between desktop and CI)....

I was on my phone before, so let me elaborate. > I didn't realize it was io-bounded. However, in our test environment, I doubt there will be 64 concurrent calls....

> these are http errors in the cargo-audit check. I am running these fine in my local machine and also in GitHub CI. Maybe your machine is offline or you...

FWIW. In our CI we're doing: ``` # Build only deps, but with llvm-cov so `workspaceCov` can reuse them cached workspaceDepsCov = craneLib.buildDepsOnly (commonArgsDepsOnly // { pnameSuffix = "-lcov-deps"; version...

We never run it locally, AFAICT. So with, in our CI. But by calling `cargo llvm-cov` directly, no with `crane.cargoLlvmCov`