| 5 Feb 2026 |
 antifuchs | In reply to @piegames:flausch.social
Okay so, + is not addition, it is string concatenation :) Nice, that’s even more cursed | 01:03:54 |
 koaledu | Every day we stray further from God. | 01:06:09 |
 Emma [it/its] | hm, is there a way to parallelise a flake update? | 02:04:30 |
| Emma [it/its] | given that -j doesn't seem to be applicable here | 02:04:58 |
 Coca | I thought flakes updated concurrently already but that's probably not true | 02:15:57 |
| Emma [it/its] | they dont (can check with -v) | 02:19:21 |
| Coca | Hm, that makes npins the only pinner that's concurrent then in the nix ecosystem then I think | 02:20:56 |
| Coca | Weird nobody has done it before | 02:21:17 |
| Coca | * Hm, that makes npins the only pinner that's concurrent then in the nix ecosystem I think | 02:21:26 |
 Sofie 🏳️⚧️ (she/her) | https://github.com/sofiedotcafe/luminarie/blob/068213a191113d3691f7c226e42bc3d360a6780c/hosts/tailstack/disko.nix | 17:20:14 |
| Sofie 🏳️⚧️ (she/her) | module.tailstack.module.disko.null_resource.disko (remote-exec): + cryptsetup status crypt-dpool-hdd0
module.tailstack.module.disko.null_resource.disko (remote-exec): + cryptsetup open /dev/disk/by-partlabel/disk-hdd0-dpool crypt-dpool-hdd0 --key-file /dev/fd/63
module.tailstack.module.disko.null_resource.disko (remote-exec): ++ set +x
module.tailstack.module.disko.null_resource.disko (remote-exec): Device /dev/disk/by-partlabel/disk-hdd0-dpool does not exist or access denied.
╷
│ Error: remote-exec provisioner error
│
│ with module.tailstack.module.disko.null_resource.disko,
│ on ../../modules/nixos_host/submodules/disko/main.tf line 14, in resource "null_resource" "disko":
│ 14: provisioner "remote-exec" {
│
│ error executing "/tmp/terraform_508773335.sh": Process exited with status 4
╵ | 17:20:18 |
| Sofie 🏳️⚧️ (she/her) | hmmmmm | 17:20:20 |
| Sofie 🏳️⚧️ (she/her) | ah | 17:22:40 |
| Sofie 🏳️⚧️ (she/her) | a state thing? | 17:22:43 |
| Sofie 🏳️⚧️ (she/her) | yeah, it was it | 17:23:46 |
 raitobezarius | Feels like you got the channel wrong again | 17:26:45 |
| raitobezarius | How can we avoid this reoccurring every time and now? | 17:26:58 |
| Sofie 🏳️⚧️ (she/her) | ooppss | 17:27:51 |
| Sofie 🏳️⚧️ (she/her) | i have to switch clients | 17:27:55 |
| Sofie 🏳️⚧️ (she/her) | they look so same | 17:27:58 |
| Sofie 🏳️⚧️ (she/her) | sorry | 17:28:00 |
| Sofie 🏳️⚧️ (she/her) | really ;3 | 17:28:01 |
 neobrain | Is there any inherent reason that Lix doesn't indicate percentual progress when fetching flakes but instead only shows an absolute in-progress download size? | 20:42:41 |
 delroth | yes-ish as there's a freeze on any development related to flakes in Lix which makes it unlikely for such improvements to get done, but other than that probably not? it might use a different download infrastructure from the rest of the downloads in Lix because flakes code tends to be a bit weird and sectioned off | 21:19:14 |
| neobrain | Aw, fair enough. Do the non-flake code paths show a percentual progress? It didn't actually occur to me that flakes might be different and just used the term as a shorthand for "fetching [e.g.] nixpkgs" | 21:29:58 |
| neobrain | * Aw, fair enough. But are you implying that the non-flake code paths already do show a percentual progress? It didn't actually occur to me that flakes might be different and just used the term as a shorthand for "fetching [e.g.] nixpkgs" | 21:30:23 |
| neobrain | Redacted or Malformed Event | 21:41:35 |
| neobrain | * eh, looks like it does show the expected total size in contrast to flakes, just that the expected total size is wrong 😅
❯ nix eval --raw github:NixOS/nixpkgs/nixos-25.05#hello
[21.7 MiB/2.3 KiB DL] downloading 'https://github.com/NixOS/nixpkgs/archive/ac62194c3917d5f474c1a844b6fd6da2db95077d.tar.gz'`
| 21:42:08 |
| neobrain | Ah well, fetching via non-flake (took me a while to figure out how to do that) indeed prints the normal git clone output and by extension a percentual progress | 21:54:47 |
| delroth | I'd recommend filing a feature request anyway - it might be it's trivial to fix and someone just needs to know it needs to be fixed, Lix is in general trying to improve the UX so this kind of feedback can always be useful | 22:32:47 |
