| 29 Aug 2025 |
 Corngood | yeah that's certainly an option. maybe it can even use bin\Release\net8.0\*\*.dll or something? or maybe there's a way to make it use the default packing logic? | 00:13:41 |
| Corngood | like if you make a dotnet new classlib and pack it with --runtime it works as expected. the dll is in bin/Release/net8.0/$rid/, but it ends up in lib/net8.0/ in the package. | 00:14:41 |
 Whovian9369 | ╭─whovian@nixos-wsl /nix/store/9j2s8kna0g37970d3s29blw20c6d5961-source/src/lib
╰─$ rg -NI "file src" | sort | uniq
<file src="bin\Debug\net8.0\*.dll" target="lib\net8.0\"/>
<file src="bin\Release\net8.0\*.dll" target="lib\net8.0\"/>
<file src="..\..\..\kuriimu2icon.png" target="kuriimu2icon.png"/>
It looks like all of the nuspec files seem to use the same path, so if the others worked then Komponent should too?
| 00:59:38 |
| Whovian9369 | You seemed to signal out Komponent as the odd one out here, so that's a touch surprising to me. | 00:59:59 |
| Corngood | Oh it was just the first one that caused a build failure in another package because it was empty | 01:00:55 |
| Whovian9369 | Ah fair enough | 01:01:09 |
|  @luna-null:matrix.org left the room. | 02:40:25 |
| 4 Sep 2025 |
| Whovian9369 | I think that I got Kuriimu2 working, and it was overall surprisingly painless once I figured out PackageReference versus ProjectReference. A friend's warning me against doing it this way though, so I have something theoretically "working" at least, but the next step is seeing if I can make the build any cleaner in the process. | 00:25:13 |
| 8 Sep 2025 |
|  Inayet set a profile picture. | 02:16:17 |
| 9 Sep 2025 |
|  PhiliPdB joined the room. | 18:43:00 |
| 10 Sep 2025 |
|  @jolman:matrix.org joined the room. | 00:25:13 |
 Samuel | Any plans on upgrading to .NET 10 RC1? | 11:10:07 |
| Corngood | In reply to @samuel:mnzn.dev
Any plans on upgrading to .NET 10 RC1? Assuming that's the one that came out this week, I've got updates running now | 15:05:17 |
| Corngood | https://github.com/NixOS/nixpkgs/pull/441849 (still not tested much) | 18:27:39 |
| 11 Sep 2025 |
| Samuel | Awesome, thanks | 06:29:57 |
| 13 Sep 2025 |
|  zenware joined the room. | 14:58:23 |
| 23 Sep 2025 |
|  kenji changed their display name from a-kenji to kenji. | 10:40:16 |
| @jolman:matrix.org left the room. | 20:12:34 |
| 24 Sep 2025 |
| Whovian9369 | Here to cause trouble again - I'm trying to bump a project from NET 8 to NET 9 in a derivation (without code changes, dev says it should work), but that Nuke build process seems to fail due to using a dynamically linked executable... Hapen to have any immediate ideas?
Could not start dynamically linked executable: /tmp/fetch-deps-hactoolnet-2024.08.29.Pzmhk6/source/build/bin/Debug/_build
(Then the message is about stub-ld etc)
| 02:39:09 |
| Whovian9369 | * Here to cause trouble again - I'm trying to bump a project from NET 8 to NET 9 in a derivation (without code changes, dev says it should work), but that Nuke build process seems to fail due to using a dynamically linked executable... Hapen to have any immediate ideas?
Could not start dynamically linked executable: /tmp/fetch-deps-hactoolnet-2024.08.29.Pzmhk6/source/build/bin/Debug/_build
(Then the message is about stub-ld etc)
| 02:39:19 |
| Whovian9369 | Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing. | 02:39:55 |
| Whovian9369 | * Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.
The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.
preConfigure = ''
dotnet --version > DotnetCliVersion.txt
patchShebangs --build build.sh
for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
./build.sh Codegen --configuration ${buildType}
'';
| 02:42:47 |
| Whovian9369 | * Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.
The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.
{
preConfigure = ''
dotnet --version > DotnetCliVersion.txt
patchShebangs --build build.sh
for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
./build.sh Codegen --configuration ${buildType}
'';
}
| 02:43:03 |
| Whovian9369 | * Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.
The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.
{
preConfigure = ''
dotnet --version > DotnetCliVersion.txt
patchShebangs --build build.sh
for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
./build.sh Codegen --configuration ${buildType}
'';
}
| 02:43:22 |
| Corngood | In reply to @whovian9369:matrix.org
Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.
The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.
{
preConfigure = ''
dotnet --version > DotnetCliVersion.txt
patchShebangs --build build.sh
for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
./build.sh Codegen --configuration ${buildType}
'';
}
There should be a fetch-drv attribute which you can run nix develop on to do the fetch in a dev shell. | 02:50:08 |
| Whovian9369 | Oh thank you, I wasn't aware of that! | 02:59:19 |
| Corngood | Not sure about the executable thing. It must be pulling that in from somewhere? | 03:03:23 |
| Whovian9369 | If you mean the dynamic linked executable, then that's part of the Nuke build. | 03:07:21 |
| Whovian9369 | I'm expecting the failing step to be the ./build.sh Codegen --configuration ${buildType} one from preConfigure that I posted above | 03:08:46 |
