| 14 Dec 2025 |
 Emma [it/its] | ./result ./deps.json or whatever | 19:37:02 |
 Corngood | I don't understand what dotnet restore is trying to do though. If it's unable to restore on a read-only tree, why is it blowing up the system?
(though ive also never had the fetch-deps script work without having to explicitly pass the path to the output deps file, because it tries writing into the store by default...)
Yeah, I had to do that too
| 19:37:03 |
| Emma [it/its] | 
Download clipboard.png | 19:37:23 |
| Emma [it/its] | interesting predicament i find myself in lol | 19:37:28 |
 Jan Kvapil | The docs are a bit dated in that regard: https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/dotnet.section.md#generating-and-updating-nuget-dependencies-generating-and-updating-nuget-dependencies
They mention $ nuget-to-json out > deps.json to call explicitly. | 19:37:44 |
| Corngood | for whatever reason you can kill it with SIGINT but not ctrl-c in the terminal... | 19:37:51 |
| Jan Kvapil | kill -9 $(pgrep dotnet) once you check there's only a single dotnet running :D | 19:38:17 |
| Corngood | The docs don't really talk about flakes. You don't need to pass the path if you do an impure eval. | 19:38:52 |
| Jan Kvapil | Hmm | 19:39:26 |
| Jan Kvapil | Could this be caught by type-check in buildDotnetModule? | 19:39:48 |
| Emma [it/its] | dotnet restore /nix/store/85fkamr6na3xjznqa70hasdzrlxqgbrr-NBitcoin.CppBridge.csproj -p:ContinuousIntegrationBuild=
true -p:Deterministic=true -p:NuGetAudit=false --runtime linux-x64 -p:SelfContained=true | 19:39:56 |
| Emma [it/its] | oh no i can just kill it in btop lol | 19:40:47 |
| Emma [it/its] | this didnt work for me | 19:40:52 |
| Emma [it/its] | interestingly, i tried running that command by itself and well... it didnt work :D | 19:41:36 |
| Emma [it/its] | oh interesting, it specifically doesnt work if you try to restore the store path? | 19:42:05 |
| Corngood | Yeah, I was able to run fetch-deps properly after changing it... Very strange | 19:42:29 |
| Jan Kvapil | Thanks a lot. Let's not disclose the amount of time I was banging my head on this. | 19:43:18 |
| Emma [it/its] | oh, i screwd myself over big time | 19:43:25 |
| Corngood | Possibly. I'm not sure if it's 100% always a bad idea though. Like maybe you could do an out-of-tree build by setting the bin/obj dirs? | 19:43:38 |
| Emma [it/its] | had to reconnect cause my shell broke, and.... LOL | 19:43:41 |
| Emma [it/its] | 
Download clipboard.png | 19:43:42 |
| Jan Kvapil | Uf | 19:44:03 |
| Jan Kvapil | Would not be the first time, when Nix filled all my disk spaces and things started to fall apart.. but not on remote 🙈 | 19:45:12 |
| Emma [it/its] | okay, i figured out exactly why it freezes like this! | 19:45:20 |
| Emma [it/its] | you'll never guess LOL | 19:45:30 |
| Emma [it/its] | 
Download clipboard.png | 19:45:47 |
| Emma [it/its] | (dotnet restore is trying to read the entire nix store, lol) | 19:46:02 |
| Corngood | In case it's useful, here's how I debugged it:
nix develop .#modules.nbitcoin.fetch-drv - fetch-drv is the derivation used by fetch-deps, so this gives you a dev shell where genericBuild will do what fetch-deps does before calling nuget-to-json
(set -xe; shopt -s nullglob; genericBuild) - do a build with tracing turned on, so you can see the dotnet restore command where it hangs
| 19:46:30 |
| Jan Kvapil | It IS useful! | 19:47:03 |
| Emma [it/its] | i ended up doing an strace -f --trace=%file on the dotnet restore command itself | 19:47:22 |
