| 8 Aug 2025 |
Ellie she/they | Same thing | 11:10:29 |
Ellie she/they | Seems worse even | 11:10:34 |
Ellie she/they | What the heck | 11:10:51 |
Rein | In reply to @rein:rein.icu I have programs.steam.enable set to true and I don't have Steam in systemPackages. I've read the wiki, it worked for some time, after one of the updates it stopped working I have, however, steam-run in runtime inputs of a custom package that packages NixOS' script from theNizo's linux_rocksmith repo now that I think about it. Could that be causing any issues with compatibility packages? | 11:14:32 |
Rein | * I have, however, steam-run in runtime inputs of a custom package that packages NixOS script from theNizo's linux_rocksmith repo now that I think about it. Could that be causing any issues with compatibility packages? | 11:14:51 |
Rein | In reply to @witchlliee:matrix.org What the heck Did you try getting rid of CachyOS's ananicy rules? | 11:22:03 |
Ellie she/they | Ya | 11:22:51 |
Rein | Then I have no idea what could be the cause. You can try also disabling things such as ananicy, power-profiles-daemon etc. and looking if there's any difference, but I doubt that's really the case | 11:25:31 |
Rein | * Then I have no idea what could be the cause. You can try also disabling things such as ananicy, power-profiles-daemon etc. and checking if there's any difference, but I doubt that's really the case | 11:26:50 |
| Carbsta (they/them) joined the room. | 13:01:35 |
Rein | In reply to @rein:rein.icu I have, however, steam-run in runtime inputs of a custom package that packages NixOS' script from theNizo's linux_rocksmith repo now that I think about it. Could that be causing any issues with compatibility packages? After removing it, I think it does not affect that at all. I have no idea why extraCompatPackages | 17:23:30 |
Rein | * After removing it, I think it does not affect that at all. I have no idea why extraCompatPackages don't work | 17:28:59 |
| Carbsta (they/them) changed their display name from carbsta to Carbsta (they/them). | 18:13:51 |
aidalgol | K900: The steam container change seems to have caused a regression in heroic: https://github.com/NixOS/nixpkgs/issues/432037 | 19:16:22 |
aidalgol | I haven't yet had a chance to look into it, but does anything leap out at you as a likely cause? | 19:16:38 |
K900 | Hmm | 19:16:51 |
K900 | Somehow dbus something? | 19:16:56 |
K900 | I don't know how it implements single instance stuff | 19:17:02 |
K900 | ...oh god it's not privateTmp is it | 19:17:09 |
aidalgol | This gets weird. I can't reproduce the issue with heroic on master. It just runs a second instance. But if I override privateTmp to false, then I get the symptom described in the issue. | 20:48:19 |
K900 | I think it's intended to not run a second instance? | 20:49:22 |
aidalgol | correct | 20:49:35 |
aidalgol | but before the steam wrapper change, trying to run a second instance would just raise the existing instance's window. | 20:50:10 |
K900 | As in, the "runs two instances" behavior is wrong | 20:50:21 |
K900 | And the expected behavior is to activate the existing one | 20:50:29 |
aidalgol | actually, that might be an intentional change. | 20:50:40 |
aidalgol | OK, how the hell do I build a Windows executable? I need to package this thing for GOG Galaxy support in Heroic to work properly.
https://github.com/imLinguin/comet/tree/main/dummy-service | 22:10:14 |
aidalgol | None of the guides for normal cross-compilation in nixpkgs quite fit this odd scenario. | 22:10:54 |
aidalgol | i.e. https://wiki.nixos.org/wiki/Cross_Compiling and https://nix.dev/tutorials/cross-compilation.html by my reading are describing setting up a dev environment for cross compiling using nixpkgs, not packaging, say, a Windows executable for use in an x86_64-linux NixOS package. | 22:15:33 |
aidalgol | Comet's upstream releases include GalaxyCommunication-dummy.exe, but our comet-gog package does not. I think this .exe was added upstream sometime since the nixpkgs package was added. | 22:18:14 |