| 13 Nov 2025 |
 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 | "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 |
