Nix + dotnet | 114 Members | |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 May 2025 | ||
Oh, do you have a specific thought on why I should be using postPatch instead of patchPhase for this? | 23:23:37 | |
I'm also doing more in patchPhase than just what I put above, so if you think moving that rm to postPatch instead is good then I'll probably just move the whole block. | 23:24:50 | |
* I'm also doing more in patchPhase than just what I put above, so if you think moving that rm to postPatch instead is good then I'll probably just rename the whole block. | 23:24:58 | |
overriding patchPhase will break patches iirc | 23:24:58 | |
Eh fair, I'll probably split it into two commits (updating and then swapping to postPatch) - Thanks for the thoughts! | 23:26:04 | |
| 27 May 2025 | ||
| 19:17:22 | ||
| 28 May 2025 | ||
| 15:18:28 | ||
| 15:21:57 | ||
| 29 May 2025 | ||
| Hey, I'm here again to cause issues. :P
| 02:14:32 | |
| Does anyone happen to have any ideas? | 02:14:42 | |
Oh maybe that's my fault for not fully fixing the for project in... section - Lemme see if I can fix it. | 02:16:44 | |
| Yep, silly me - That was it. | 02:17:23 | |
| Now I'm running into NETSDK1004 so that's definitely progress! | 02:38:00 | |
| You might want to look at
| 11:59:28 | |
Thanks for the suggestion! I already am looking at Avalonia and had originally copied runtimeIds and configurePhase without modification, which caused the initial MSB1009 issue that I was getting. Removing the project for loop fixed that, as I only have the one project file. Unfortunately for me, there's no listed fix for NETSDK1004 in the Avalonia package.nix | 13:11:47 | |
* Thanks for the suggestion! I already am looking at Avalonia and had originally copied runtimeIds and configurePhase without modification, which caused the initial MSB1009 issue that I was getting. Removing the project for loop fixed that, as I only have the one project file. Unfortunately for me, there's no listed fix for NETSDK1004 in the Avalonia package.nix. | 13:11:59 | |
| (Or in all of Nixpkgs from what I can tell. I'm not terribly surprised at that, though I was a little hopeful.) | 13:18:44 | |
| I think NETSDK1004 would usually be caused by restore/build not using the same args, or possibly a mismatch between restoring a project and a solution? | 13:34:01 | |
| It seems to be happening with the Nuke setup, so I'm a bit confused then - I'll get a log snippet in a moment as I forgot to last night. | 14:23:12 | |
Here's the failure log. | 14:25:06 | |
Oh wait that is in buildPhase which would be what I'm actually trying to build, I somehow missed that. | 14:27:16 | |
| It looks like `hactoolnet.csproj` hasn't been restored. Can you share the expression source? | 15:54:31 | |
| One slight issue is that Upstream no longer exists, so I wish you luck finding a copy. | 15:56:14 | |
| Download package.nix | 15:56:20 | |
| Download deps.json | 15:56:20 | |
I should have sent package.nix as a code block, and don't know why I didn't. 😅 Sorry about that! | 15:57:21 | |
So it seems that Nix/dotnet really doesn't like it if you run runHook preConfigure in preConfigure. Oops.It's no longer segfaulting! 🎉 | 21:49:08 | |
I never mentioned the issue in here, sorry about that. 😅fetch-deps was segfaulting for some reason, and it looks like I fixed it when I removed the accidentally remaining runHooks. | 21:54:47 | |
| 1 Jun 2025 | ||
| 23:47:40 | ||
| 4 Jun 2025 | ||
| Hey, I was wondering if there were any dotnet 4.8 runtime package definitions lying around. My work currently uses that runtime, and I wasn't able to find the runtime throughout any of the nixpkgs history: https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable&package=dotnet-sdk | 19:50:17 | |