| 13 Nov 2025 |
 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 | "officialBuildId": "20251023.11"
How does this become 25523.111?
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.
<!-- Add 100 to the revision number to avoid clashing with the existing msft official builds. -->
| 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.com
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). I 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.com
Anyone want to review the backport of the november releases? https://github.com/NixOS/nixpkgs/pull/461696 I 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 |
| 16 Nov 2025 |
 Emma [it/its] | just updated to the latest nixpkgs unstable and im still seeing VMR in regular buildDotnetModule builds | 19:33:56 |
| Emma [it/its] | just thought i'd mention it, though i wouldnt have expected that to change :) | 19:34:23 |
| Emma [it/its] | copying path '/nix/store/cv5rbkic7ghfbxwf5jsihgv27i3ai5wz-dotnet-vmr-10.0.0-rc.2' from 'https://cache.nixos.org'... | 19:34:39 |
| Corngood | I just made a PR with my idea for a fix: https://github.com/NixOS/nixpkgs/pull/462339 | 19:53:17 |
| Emma [it/its] | oh is that the fix for the vmr thing? | 20:03:47 |
| Emma [it/its] | im not sure how i'd go about testing this given i'd still have to build vmr for dotnet itself? | 20:07:32 |
| Corngood | You cant really because it'll only stop downloading them once they are in the binary cache. | 20:16:30 |
| Corngood | I still need to wrap my head around why they aren't in the cache based on what hydra is currently building | 20:17:32 |
| Emma [it/its] | my guess would be the fact that they're in the output tree - but that doesnt explain how it even figures that out? | 20:19:28 |
| Emma [it/its] | but i could totally be imagining stuff too | 20:19:46 |
| Corngood | That sounds right. I suppose the hydra jobs just push the closure of the outputs to the cache? | 21:23:50 |
| 17 Nov 2025 |
| Emma [it/its] | that's what i'd assume it does, yeah | 10:15:20 |
| 20 Nov 2025 |
 Samuel | Interesting blog post: https://devblogs.microsoft.com/dotnet/reinventing-how-dotnet-builds-and-ships-again | 21:54:29 |
| Samuel | Explains why the source build was always breaking 🙃 | 21:58:11 |
| 25 Nov 2025 |
| Corngood | Emma [it/its]: this should be working now. Would you like to review? | 16:14:12 |
| Emma [it/its] | nixpkgs-review looking good 👀
is there a particular way i can test this? | 16:15:12 |
| Emma [it/its] | because i'd guess binary cache is still a no lol | 16:16:18 |
| Corngood | Nah there's not really a way to test it, but the eval looks good | 17:42:20 |
| Emma [it/its] | i see, alright then | 22:39:10 |
| Emma [it/its] | i suppose the only thing we can really do is, well, find out i suppose | 22:41:33 |
