feat(nix): rewrite nix stuff

[Libadoxon]

Ok this is what I got so far. I changed a bit of the c code as well, so it is now possible to read the session directories from a environment variable. But it seems I fucked something up, because it fails when I try to login. It finds them correctly but when I login it errors out with: execl error: No such file or directory. So perhaps you can shine some light onto this.
Also is there a reason your using tty7 instead of just tty1?

[Libadoxon]

I'm very very proud of my nix serializer but I already know someone's gonna come and say "its not pure nix, it depends on the header keys file, thats not necessary, if you really want the "enums" thing you should hardcode them, not read the file" 🤓 ☝️

That's me by the way

I'm going to sleep now, so it will take a while before I respond

[grialion]

I changed a bit of the c code as well, so it is now possible to read the session directories from a environment variable. But it seems I fucked something up, because it fails when I try to login. It finds them correctly but when I login it errors out with: execl error: No such file or directory.

Looks fine to me at first glance. However it used to be that way for a reason, which I don't understand, but I remember javalsai made it like that when he fixed up the nix package: 6cac2f9
Easiest way to debug would be strace and just look for the execl syscall. I don't currently have a nix system, so it'd speed things up if you (or javalsai) could do that.

[Libadoxon]

I did some more debugging. There isn't any execl in the strace output other than the self re-execute. The error is somehow related to pam because I also get error on pam authentication(1): Operation not permitted. I might note that logging into shell works. The issue is the same when using a custom pam file or the standard login one. I also think that logging doesn't work (or I'm just stupid?).

[Libadoxon]

Okay I'm stupid logs work

[Libadoxon]

The problem seems to be that there aren't any environment variables set. For example PATH, DBUS_SESSION_BUS_ADDRESS and XDG_RUNTIME_DIR are all not set. This is seems to be at least a semi known issue since PATH gets deliberately set in auth.c at 208. I know to to little about c and pam to understand the issue here. Also why does this seem to only happen on NixOs or is this happening on other distros too?

[Libadoxon]

I just added a vm configuration, see flake.nix how to get a quick testing vm with some DE's

[javalsai]

I'm very very proud of my nix serializer but I already know someone's gonna come and say "its not pure nix, it depends on the header keys file, thats not necessary, if you really want the "enums" thing you should hardcode them, not read the file" 🤓 ☝️

That's me by the way

Knew this time would come 😎

Ok this is what I got so far. I changed a bit of the c code as well, so it is now possible to read the session directories from a environment variable. But it seems I fucked something up, because it fails when I try to login. It finds them correctly but when I login it errors out with: execl error: No such file or directory. So perhaps you can shine some light onto this.

Xorg? I think that's broken or needs some extra fancy config in nix. I think wayland sessions set the Exec key to the nix store path and shouldn't have any issues.

Also is there a reason your using tty7 instead of just tty1?

Noh not really, feel free to put this into standard.

The problem seems to be that there aren't any environment variables set. For example PATH, DBUS_SESSION_BUS_ADDRESS and XDG_RUNTIME_DIR are all not set. This is seems to be at least a semi known issue since PATH gets deliberately set in auth.c at 208. I know to to little about c and pam to understand the issue here. Also why does this seem to only happen on NixOs or is this happening on other distros too?

Yes PAM is a bit sketchy and I think there's some assumptions on the auth.c file setting some initial env and etc. But I think now it should be pretty close to standard, most env should be set by pam and I think there's only some hardcoded PATH set.

---

Anyhow, will be back from holidays the 20th so I can take a deeper look at everything and debug some things myself too, good luck meanwhile.

[javalsai]

Also about the PR checks don't mind about aarch64 build failures. make literally segfaults randomly in that VM, I'll rerun it once the PR is ready to merge.

[grialion]

I just tested your changes on Void Linux, and this line was necessary.
Without explicitly setting the path, it produces weird issues:

[javalsai]

Was a hotfix back when I wrote it, there should be another proper way to get PATH env...

[Libadoxon]

I'm a bit low on time the next days, but eventually I will look into how ly and lemur get the envs. Both run on NixOs so I hope they can shed some light onto this

[javalsai]

Reviewing this without getting too deep into the nix logic, 10/10 contribution, everything looks perfect. 👏 👏

About the github actions. I made them thinking I need to make ship the module.nix separately and somehow pull the source from releases or whatever. Shipping it with the source code makes much more sense though, but it will need some documentation changes on INSTALLATION.md.

If you prefer, I can do that myself, just explain a bit how's the best way to install now, the one in my head doesn't feel all that modular. Or maybe it's just better to try getting this into nix-pkgs, you decide.

[javalsai]

And just to make sure, nix run .#nixosConfigurations.x86_64-linux.vm.config.system.build.vm would only work on nixos systems right? Trying it on other systems with nix just fails because I'm guessing it depends directly on system nix internals.

[Libadoxon]

And just to make sure, nix run .#nixosConfigurations.x86_64-linux.vm.config.system.build.vm would only work on nixos systems right? Trying it on other systems with nix just fails because I'm guessing it depends directly on system nix internals.

No this should work on any system with nix that is able to run qemu (doesn't need to be installed)

Shipping it with the source code makes much more sense though, but it will need some documentation changes on INSTALLATION.md.

I plan to add/update all documentation when everything works so I don't have to rewrite it if I change something

Or maybe it's just better to try getting this into nix-pkgs, you decide.

I think getting this into nixpkgs isn't so import when there is a working flake. Especially since the project is quite small currently

[javalsai]

No this should work on any system with nix that is able to run qemu

I'll look more into it later then.

I plan to add/update all documentation when everything works so I don't have to rewrite it if I change something

Perfect, if you don't mind I'm going to request changes about it just so we don't accidentally forget about it before merging (wouldn't the first time). Don't want it to feel too pushy, take your time.

[grialion]

Just my thoughts on this:

The VM part should either be removed or moved from flake.nix after merging this pull request, because as far as I can see, it's only for testing locally (not even automated), which doesn't really have much to do with the project itself (e.g you can always spin up a VM the way you want and test it).

Nixpkgs should be the final goal. It is at least in my eyes. It would be way more convenient for both packagers and users. I'm pretty sure this project is mature and popular enough to be there. And you definitely have the skills to make it happen. Not pushing you, actually I'm really thankful for your work so far, but I already package it for Void Linux, and I would like seeing this project get into nixpkgs as well :)

[javalsai]

The VM part should either be removed or moved from flake.nix

Pretty sure it's just an "optional nested target" that you need to manually call and not bad to be put in flake.nix, it's just a dead path for the default run of it.

for testing locally (not even automated)

Could be automated, a VM is the first step and this is just setting the blueprints of a minimal nixos machine for lidm, can be moved into more automated stuff when needed. Otherwise, testing the nix config works properly is a mess, keeping it does more good than bad.

Nixpkgs should be the final goal. It is at least in my eyes. It would be way more convenient for both packagers and users.

Yes but you need a packager with nix knowledge to be willing of taking the responsibility of the package, it will come naturally as the project grows and I don't think lidm is popular enough for it yet.

Sure he can make it happen but taking responsibility of the package and that's not all that easy. Again, I just think a packager should come naturally, not be requested. So as long as the included nix code doesn't go against the future process of getting this into nixpkgs it's all fine.

[itpropro]

Any updates on getting this merged @javalsai ? It's pretty hard to get lidm to work on nix currently...

[javalsai]

Any updates on getting this merged @javalsai ? It's pretty hard to get lidm to work on nix currently...

It's still a draft and iirc someone wanted to pick up the work on it (I'm not sure though, flaky memory). Idk how usable it is and I don't really use nixos but I can merge some changes if yall think its somewhat usable for now.

[javalsai]

@itpropro, I'd talk it with @Libadoxon and @elliott-farrall, not sure how the work on this is going, I'm open to merging anything usable but idk how this is going.

[Libadoxon]

yeah sorry for disappearing. I'm currently low on time, exams coming up. Main issue is, that some environment variables aren't getting handled correctly. If this gets fixed the rest should just work.

[javalsai]

yeah sorry for disappearing. I'm currently low on time, exams coming up. Main issue is, that some environment variables aren't getting handled correctly. If this gets fixed the rest should just work.

No worries, im on the same boat rn 😔, just checking the state of this and if someone wants to work on this I think its fine

[elliott-farrall]

Also quite busy atm. I'm using lidm on my NixOS laptop though so will definitely be looking into this when I get some time.