| 1 Nov 2022 |
|  emilytrau (she/her) joined the room. | 21:43:23 |
| 2 Nov 2022 |
|  @benoitj:matrix.org left the room. | 00:22:20 |
 myme | How do people handle that WSL doesn't launch into a login shell by default? It's fairly trivial to have Windows Terminal start bash -l. But it's more of a hassle with the .desktop app launchers, which also won't launch with a proper environment. | 16:01:13 |
| 4 Nov 2022 |
|  find me at @ryan:freumh.org joined the room. | 01:06:33 |
|  ジータ joined the room. | 03:54:09 |
 @steve:trout.rocks | In reply to @myme:matrix.org
How do people handle that WSL doesn't launch into a login shell by default? It's fairly trivial to have Windows Terminal start bash -l. But it's more of a hassle with the .desktop app launchers, which also won't launch with a proper environment. Adding on to this, couldn't syschemd.sh make the default command login (actually login -p IIRC) instead of looking up the user's shell? I've experimented with that and it seems to work well. | 15:21:03 |
| @steve:trout.rocks | * Adding on to this, couldn't syschdemd.sh make the default command `login` (actually `login -p` IIRC) instead of looking up the user's shell? I've experimented with that and it seems to work well. | 15:21:26 |
 K900 | Ideally we'd remove the whole thing | 15:41:04 |
| K900 | And let WSL's native systemd support handle things | 15:41:21 |
| K900 | But it's still kinda buggy | 15:41:42 |
 p10r | Hello! after setting wsl.nativeSystemd = true; sysctl stopped working for home-manager services.. Anythig obvious I missed? | 15:43:46 |
| p10r | 
Download image.png | 15:44:02 |
| K900 | Yes | 15:52:05 |
| K900 | Well | 15:52:08 |
| K900 | No | 15:52:09 |
| K900 | But yes | 15:52:11 |
| K900 | It doesn't run user systemd instances currently | 15:52:22 |
| K900 | This is something I really don't want to work around because it'll be hard to get all the small details right | 15:52:59 |
| K900 | And upstream seems to be interested in fixing it correctly | 15:53:08 |
| p10r | fair enough. Would you recommend just keeping the old thing for now instead of switching to nativeSystemd? | 15:58:38 |
| K900 | Yes | 15:59:27 |
| p10r | Thanks! | 16:03:21 |
| K900 | nativeSystemd is to be considered very experimental both upstream and on the NixOS side | 16:03:48 |
| K900 | Though the NixOS side is rather tiny | 16:03:54 |
| p10r | In reply to @k900:0upti.me
Though the NixOS side is rather tiny yeah, the size of commit fooled me :) | 16:05:34 |
 Sandro 🐧 | In reply to @k900:0upti.me
But it's still kinda buggy and not available on w10 | 16:55:43 |
|  @kranzes:matrix.org left the room. | 21:42:39 |
| 6 Nov 2022 |
 nzbr (they/it) | In reply to @myme:matrix.org
How do people handle that WSL doesn't launch into a login shell by default? It's fairly trivial to have Windows Terminal start bash -l. But it's more of a hassle with the .desktop app launchers, which also won't launch with a proper environment. Can you create an issue for this? I think the best idea is to somehow run all commands through the user's shell with --login -c "$command", though I'm not sure if that will work with all non posix-compliant shells | 04:55:30 |
| myme |
Can you create an issue for this?
Sure, I can do that! I wanted to hear people's thoughts first. Not really something that feels like solely a NixOS WSL issue. But until native systemd is stable I guess it's nice to work around these things (e.g. if it's configurable in case people don't want this default behavior).
I guess having things like https://github.com/microsoft/WSL/issues/8842 and related things resolved so that systemd "just handles everything". Like, I also have to do an systemctl --user import-environment SSH_AUTH_SOCK WSLENV to get this into my user service environments.
| 13:50:18 |
| K900 | I don't think we should keep piling on workarounds for upstream issues | 13:53:04 |
