 | Nix + dotnet | 112 Members |
| 23 Servers |
| Nix + dotnet | 112 Members |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 13 Nov 2025 | ||
 Corngood | I generally start on it when I get the release announcement. Unfortunately the update bot doesn't really work because of how the source and binary packages are coupled, but update.nix does usually work. | 11:34:32 |
| Corngood | Mine is here: https://github.com/NixOS/nixpkgs/pull/461246 It would be great to get the update bot working. It actually does manage to update the binary packages most of the time, but we currently build the top level packages (e.g. dotnet-sdk_8) as a composite of the binary SDK and source-built runtime. This means that you need to update them at the same time, or it'll fail a version assert. So like: It' | 13:59:42 |
| Corngood | * Mine is here: https://github.com/NixOS/nixpkgs/pull/461246 It would be great to get the update bot working. It actually does manage to update the binary packages most of the time, but we currently build the top level packages (e.g. dotnet-sdk_8) as a composite of the binary SDK and source-built runtime. This means that you need to update them at the same time, or it'll fail a version assert. So like: | 13:59:56 |
 Samuel | running nixpkgs-review now | 14:01:48 |
| Corngood | I had a brief look for examples of update scripts that deal with this sort of coupling, but I didn't find anything obvious. One method would be to make the composite SDK have an update script that calls both of the child ones. | 14:02:02 |
| Samuel | Dang, that's a chonky rebuild, pulling ≈20GB from the cache, that's ≈60GB uncompressed | 14:06:17 |
| Corngood | Building all this stuff is too expensive for nixpkgs-review-gha, so I'm not sure if the update bot would even be able to do it... I'm also running a review btw, on x86_64-linux. | 14:06:42 |
| Corngood | And then I usually do a darwin one from the community builder after that. | 14:07:02 |
| Samuel | I'm running on an 8C/16T ryzen server and it still takes a long time every update 🙃 | 14:08:19 |
| Samuel | Mostly due to a full webkit build somewhere down the dependency graph | 14:09:34 |
| Corngood | VMR 10 already failed for me... Looks like some sort of change to the output structure :| Why is there a webkit build? Something that's currently broken on master? | 14:10:55 |
| Samuel | No webkit was last time, this time it's just opencv for now | 14:16:42 |
| Samuel |  Download image.png | 14:16:47 |
| Samuel | Still annoying but not that bad | 14:17:07 |
 qsevers23 joined the room. | 14:20:50 | |
| qsevers23 | Thanks for getting the new dotnet releases wrapped up, running nixpkgs-review on aarch64-darwin now | 14:24:04 |
| qsevers23 changed their display name from gorillaman43 to qsevers23. | 14:24:24 | |
| Corngood | VMR failed because it now outputs dotnet-sdk-10.0.100-rtm.25523.111-linux-x64, but the sdkVersion field in release.json is just '10.0.100'. I guess in the past this always matched, ugh | 15:46:15 |
| Samuel | Had to pause the build for a while, but I'm now building the rest of the packages | 17:16:20 |
| Samuel | Ok, the builds are done. I think most of the stuff not related to the vmr failure built correctly. | 19:09:42 |
| Corngood | I'm still working on the buildid thing. If I remove the 'officialBuildId' from the manifest, I get e.g. dotnet-sdk-10.0.100-dev-linux-x64.tar.gz, but it's still sticking that -dev in there. This wasn't a problem in the preview builds because the manifest had the full suffix on the versions | 19:19:56 |
| Corngood | How does this become You take YY * 1000 + (M * 50) + D for the first part (for reasons I guess?), and for the second part you arbitrarily add 100 to it. | 19:26:12 |
| Corngood | I think it's fixed now. I had to change the build flags from pre-release and didn't notice it in the release notes. I'll run all the SDK tests again and then kick off a review | 20:42:19 |
| 14 Nov 2025 | ||
 Whovian9369 | I believe it was Corn that first introduced fetch-drv to me and I will be forever appreciative of that since I can --dry-run that to make fetch-deps itself just a tiny bit more convenient! Thank you, Corn! | 16:53:45 |
| Corngood | I'm curious how you're using the dry run. The only thing I've ever used fetch-drv for is to run the fetch in a dev shell (e.g. nix develop -f. package.fetch-drv). | 18:18:48 |
| Whovian9369 | In reply to @corngood:corngood.comI mainly use --dry-run to build specific derivations before other ones, for example to build dependencies before building the main bulk of a software later.In the case of fetch-drv, I normally use it to build the dependencies so the normal fetch-deps script doesn't have to wait around before getting to the proper dependencies. | 18:31:52 |
| Whovian9369 | ("Base dependencies" versus "Program dependencies" I suppose?) | 18:32:34 |
| Whovian9369 | Just checked - Mainly packages like Microsoft.AspNetCore.App.Ref, Microsoft.AspNetCore.App.Runtime, Microsoft.NETCore.App.Host, etc for Linux/macOS of various architectures | 18:40:37 |
| 15 Nov 2025 | ||
| Corngood | Anyone want to review the backport of the november releases? https://github.com/NixOS/nixpkgs/pull/461696 | 15:04:24 |
| Corngood | In reply to @corngood:corngood.comI already ran the builds and tests, so I don't need anyone to do that. I just prefer to get a +1 from someone else before merging. | 17:10:12 |