| 9 Jan 2026 |
donn | * is nixpkgs-review for packages with a lot of dependents? genuinely asking i may have a mistaken impression about it | 13:02:10 |
K900 | nixpkgs-review is for testing everything that depends on the package still builds | 13:02:37 |
donn | gotcha | 13:02:45 |
K900 | It makes no sense when you're adding a leaf package | 13:02:50 |
K900 | Except the comments look pretty and some people have github actions set up to spam that shit on their PRs | 13:03:01 |
K900 | Which is bad, by the way | 13:03:05 |
donn | oh. darwin wasn't even in the supported systems. that would do it | 13:07:46 |
sterni | Is there prior discussion on making the default Nix version for Nixpkgs configurable I can read up on? This is obviously a long standing problem since you always wind up with multiple Nix versions if you don't stick to pkgs.nix even if it's not strictly necessary (due to use of the API etc.) and more urgent with Lix existing now… | 17:44:16 |
K900 | This was never a thing I believe | 17:45:38 |
K900 | Well technically that's why nixForLinking was introduced | 17:45:47 |
K900 | But eventually we'll probably see things targeting the Lix APIs instead | 17:46:12 |
K900 | Which means there will have to be a lixForLinking I guess? | 17:46:24 |
K900 | But like fundamentally you can't just overlay { nix = final.lix } and have that work | 17:46:38 |
K900 | Because the APIs have diverged enough | 17:46:43 |
sterni | what I was thinking about to begin with was the low hanging fruits, i.e. just stable-ish CLI use. E.g. if you have pkgs.nix in your wrapper for prefetch scripts etc. | 17:49:15 |
raitobezarius | for flags, we are not planning to break existing CLI flags (except if completely buggy / no usage / etc.) in existing CLIs | 17:49:44 |
sterni | We kind of need a config option for a mostly compatible use of Nix precisely because you can't overlay pkgs.nix properly anymore. | 17:49:49 |
raitobezarius | we would do nix4 for the new CLI | 17:49:49 |
K900 | IMO CLIs should really just use the ambient nix cli | 17:49:48 |
K900 | * IMO CLIs should really just use the ambient nix CLI | 17:49:50 |
raitobezarius | for outputs in CLI, we would introduce flags for versioning the outputs | 17:49:59 |
sterni | Yes, this seems to be the best option at the moment. | 17:50:11 |
raitobezarius | but then they absolutely need versioned output flag they can rely on | 17:50:35 |
K900 | Well yes | 17:50:40 |
raitobezarius | ex: https://git.lix.systems/lix-project/lix/issues/901 | 17:50:42 |
K900 | Ideally we'd have that | 17:50:51 |
K900 | But overlaying will give you the same problem except worse | 17:50:59 |
| νεολαμπής [NSAolampis] changed their profile picture. | 18:19:24 |
| νεολαμπής [NSAolampis] changed their profile picture. | 18:21:50 |
guiniol | In reply to @guiniol:matrix.org I seem to have borked my system enough that systemd isn't responding via DBUS or something and can't nixos-rebuild switch anymore. So my plan is to boot of a live USB and use nixos-enter to get back into the system with a working systemd. Is there an option to nixos-rebuild switch that will let it rebuild from scratch? Ie, I am fine using the remote cache but I want it to overwrite all the local files that it would normally re-use. Is there an option for that? I don't see it in the man page. Just another quick update on this: what borked my system was enabling RocM (AMD's competitor to CUDA) on an older APU. They're not supported anymore but they still kinda work. Until the system gets soft locked, and you need to hard reset while you're doing a nixos-rebuild switch, pegging the CPU at 100% for long enough that the SSD heats up and gives you a smart alert about it. So you spend time running so the tests you can think of on the SSD since it was still unstable after the full system rebuild. So, now, RocM is only enabled for btop to get the usage and temperature, via an overlay. And the system is stable, and cool. So, don't be like me and don't enable RocM on an unsupported chip globally. I wanted it for btop but immich also started using it and that's where it went wrong. | 19:24:18 |