| 26 Oct 2025 |
Sofie 🏳️⚧️ (she/her) | like | 19:54:13 |
Sofie 🏳️⚧️ (she/her) | I dont wanna fork it just for that | 19:54:18 |
thubrecht | If you don't care about ifd, you can use pkgs.applyPatches on the nixpkgs source | 19:57:13 |
Sofie 🏳️⚧️ (she/her) | I mean, how can I do that if I cant modify it staright from the the inputs.<> | 20:31:29 |
| @.esy:matrix.org left the room. | 21:42:43 |
lillecarl | I figured I should try using a ssh cache since that's what I'm using to push
build-mg8m24gjsc1fvfqnr344xpmfb001ihfc-cfc7j build 2025-10-26T23:21:20.209437622+01:00 error: cannot connect to 'nix@nix-cache'
| 22:22:53 |
lillecarl | * I figured I should try using a ssh cache since that's what I'm using to push
build-mg8m24gjsc1fvfqnr344xpmfb001ihfc-cfc7j build 2025-10-26T23:21:20.209437622+01:00 error: cannot connect to 'nix@nix-cache'
...........
build-mg8m24gjsc1fvfqnr344xpmfb001ihfc-cfc7j build 2025-10-26T23:23:01.585515702+01:00 error: cannot connect to 'nix@nix-cache'
| 22:23:21 |
lillecarl | The logic for fetching really wants things to be online 😄 | 22:24:01 |
lillecarl | * The logic for fetching really wants things to be online 😄 Edit: (It keeps looping forever) | 22:32:39 |
| 27 Oct 2025 |
522 it/its ⛯ΘΔ | i was searching for colmena and noticed that it's also in nixpkgs as nixpkgs.lixPackageSets.{latest, git}.colmena: should i assume that this is "colmena but built to use lix" (and i should use that over nixpkgs.colmena if i use lix?). And i guess use git since i also use lix on main? | 00:34:10 |
just1602 | I don't know if it's gonna rebuild it if your build on main isn't the same as the one in the package set, but personaly I build the package from source directly with my lix build. Like I have this in my flake devShell colmena.defaultPackage."${system}". | 00:38:29 |
just1602 | But the one from the lix packgeSets should work, tho. | 00:38:47 |
@dawnofmidnight:catgirl.cloud | if you use the lix module, that automatically applies overlays so that nixpkgs.colmena will do the right thing | 02:03:18 |
@dawnofmidnight:catgirl.cloud | * if you use the lix nixos-module (https://git.lix.systems/lix-project/nixos-module/), that automatically applies overlays so that nixpkgs.colmena will do the right thing | 02:03:27 |
@dawnofmidnight:catgirl.cloud | lixPackageSets.git is updated periodically, but it's the same as lix-on-main (it's probably a couple of days behind), and you'll end up pulling the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want the newest possible lix while still benefiting from the binary cache | 02:07:40 |
@dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind), and you'll end up pulling the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want the newest possible lix while still benefiting from the binary cache | 02:07:50 |
@dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind). you'll end up pulling both the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want the newest possible lix while still benefiting from the binary cache | 02:08:03 |
@dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind). you'll end up pulling both the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want a new-ish lix while still benefiting from the binary cache | 02:12:36 |
@dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind). you'll end up pulling both the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want a new-ish lix while still benefiting from the binary cache. using it if you also use lix-on-main is decidedly the wrong behavior. | 05:30:55 |
@dawnofmidnight:catgirl.cloud | * lixPackageSets.git is updated periodically, but it's not the same as lix-on-main (it's probably a couple of days behind). you'll end up pulling both the version of lix that nixpkgs has and the lix-on-main that you're using. aiui that mostly exists for folks who want a new-ish lix while still benefiting from the binary cache. using it if you also use lix-on-main is almost certainly the wrong behavior. | 05:32:05 |
| νεολαμπής [he/him] joined the room. | 12:36:50 |
| splurged changed their profile picture. | 16:08:28 |
| 28 Oct 2025 |
somasis | what's the correct way to get pure evaluation when using nix repl? when not evaluating a flake, specifically. using --option pure-eval true doesn't seem to have an effect as builtins.currentSystem still returns "x86_64-linux" | 14:14:11 |
somasis | what's the correct way to get pure evaluation when using nix repl? when not evaluating a flake, specifically. using --option pure-eval true doesn't seem to have an effect as, builtins.currentSystem still returns "x86_64-linux" | 14:14:24 |
hexa | --pure-eval? | 14:23:07 |
somasis | didn't know that flag exists, but same result, builtins.currentSystem gives "x86_64-linux" :/ | 14:23:44 |
somasis | didn't know that flag existed, but same result, builtins.currentSystem gives "x86_64-linux" :/ | 14:23:49 |
jappie | $> nix repl --pure-eval
Lix 2.93.3
Type :? for help.
nix-repl> builtins.currentSystem
error: attribute 'currentSystem' missing
at «string»:1:10:
1| builtins.currentSystem
| ^
nix-repl>
| 14:24:21 |