| 12 Feb 2025 |
GGG | But I'm not entirely shure | 21:25:18 |
6pak | fyi the "private" keys for strong-signing runtime/official assemblies are public | 23:24:13 |
6pak | and afaik source build uses them | 23:24:34 |
6pak | * fyi the "private" keys for strong-named signing runtime/official assemblies are public | 23:25:02 |
6pak | * fyi the "private" keys for strong-name signing runtime/official assemblies are public | 23:25:12 |
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 |