| 12 Feb 2025 |
 GGG | Idk, there's an open issue in the source build repo about signing build results | 23:51:13 |
 6pak | actually, you wouldn't even need the private keys on coreclr | 23:52:43 |
| 6pak | because they are not verified there, you can just provide any public key you want | 23:52:52 |
| 6pak | it's only used on .net framework | 23:53:01 |
| 6pak | so my guess is that source builds always had the correct publickeytoken, but werent actually signed until https://github.com/dotnet/source-build/issues/4804 was closed (but it shouldnt matter on coreclr) | 23:53:56 |
| 13 Feb 2025 |
| GGG | I see, I thought this meant it wasn't being signed: https://github.com/dotnet/source-build/issues/3708 | 00:11:32 |
| 15 Feb 2025 |
|  BenjB83 joined the room. | 10:15:13 |
| BenjB83 changed their display name from BenjamÃn Buske to BenjB83. | 10:43:16 |
| 17 Feb 2025 |
|  dgb joined the room. | 22:33:56 |
| dgb | hey everyone, I'm looking at making my first contribution to nixpkgs - what's the best practice for building multiple dotnet modules out of a single git repo? I'd like to add the bicep-langserver package from the same repo as this tool: https://github.com/nixos/nixpkgs/blob/master/pkgs/by-name/bi/bicep/package.nix | 22:39:11 |
 Corngood | I'd say it sort of depends on the structure of the repo and the build process. You could build them together in a single derivation, you could make the language server a separate derivation and inherit src/version, or keep them completely separate. | 23:23:41 |
| Corngood | We have `roslyn-ls`, which uses the main Roslyn repo but builds only the language server. | 23:25:37 |
| dgb | Yeah, they're separate csproj files in the upstream repo. I didn't realize building multiple projects in the same derivation was an option. I think that makes the most sense. Thanks for the advice | 23:38:51 |
| 18 Feb 2025 |
| dgb | https://github.com/NixOS/nixpkgs/pull/382993 alright, well there it is | 01:51:52 |
| 24 Feb 2025 |
|  loudgolem joined the room. | 07:39:16 |
| 1 Mar 2025 |
|  achnazoor left the room. | 12:44:17 |
| 3 Mar 2025 |
|  Jaco joined the room. | 13:21:53 |
| 5 Mar 2025 |
|  lzcunt joined the room. | 21:17:37 |
| lzcunt | Heyy, packaging a dotnet app. It seems to run nuget restore instead of dotnet restore in its makefile, and seemingly fetch-deps doesn't do that | 21:18:09 |
| lzcunt | I have no idea why those two commands are any different, I am not really a dotnet person. Testing manually, it seems dotnet restore fails to find anything to restore at all. What should I do? | 21:18:19 |
| 6pak | nuget would likely call the legacy mono/netfx nuget client | 21:20:34 |
| 6pak | while nixpkgs only really supports the modern dotnet sdk | 21:20:43 |
| lzcunt | Ah, is there a way to get the solution to restore with dotnet instead? | 21:21:14 |
| 6pak | what app is it? | 21:21:24 |
| lzcunt | OpenBVE | 21:21:28 |
| lzcunt | train simulator :3 | 21:21:35 |
| 6pak | "makefile" sounds like it does some custom build logic | 21:21:44 |
| lzcunt | it barely does any logic | 21:21:52 |
| lzcunt | it's checking for dependencies then just calling nuget and msbuild | 21:22:06 |
| 6pak | it uses the legacy project format and packages.config, but it should still work with modern dotnet sdk | 21:22:43 |
