| 15 Aug 2021 |
 @ultranix:matrix.org | * kraftnix: thank's a lot for your help | 17:34:06 |
| @ultranix:matrix.org | still, strangest thing ever | 18:20:34 |
| @ultranix:matrix.org | the profile directory cannot be named users/profiles/emacs so i have to refer to it as users/profiles/e-macs or similar | 18:21:55 |
| @ultranix:matrix.org | i wonder if its because of the emacs-overlay included from nix-community | 18:22:35 |
| @ultranix:matrix.org | what is digga.overlay.patchedNix for? | 19:08:41 |
 David Arnold (blaggacao) | In reply to @ultranix:matrix.org
what is digga.overlay.patchedNix for? It's nix with the pending follows patch. | 23:04:16 |
| David Arnold (blaggacao) | In reply to @kraftnix:matrix.org
i essentially have scripts for this for zfs/btrfs (which aren't currently supported 🤔, so may be worth contributing). one problem i see for install automation (unless your deploy-rs PR handles this for install) is if you are using luks and/or zfs you need some hashes for your new host (hostId for zfs, uuid for luks devices), i tend to just let this be auto-generated by nixos-generate-config but it's been a barrier for me in terms of further automation. my PR to deploy-rs esentially does just add the capability to install onto a mountpoint and changes the nixos activation script to do the work that otherwise nixos-install does.. | 23:05:41 |
| @ultranix:matrix.org | In reply to @blaggacao:matrix.org
It's nix with the pending follows patch. i had to comment it out because it was failing | 23:33:44 |
| David Arnold (blaggacao) | Yeah, I wanted to do a fix but got cought in a time eating chore loop today... 🤣 | 23:36:15 |
| David Arnold (blaggacao) | If anyone has a standing wire to elco, maybe it's time to reiterate that the situation w.r.t. https://github.com/NixOS/nix/pull/4641 is becoming unbearable... | 23:37:33 |
| David Arnold (blaggacao) | https://github.com/NixOS/nix/pull/4641#issuecomment-899128614 | 23:42:17 |
| David Arnold (blaggacao) | Gytis Ivaskevicius: is your wire still standing? | 23:42:40 |
 @gytis-ivaskevicius:matrix.org | How about you ask about it in rfc96 channel? | 23:47:38 |
| @gytis-ivaskevicius:matrix.org | Or just dm him | 23:57:22 |
| 16 Aug 2021 |
|  tomberek joined the room. | 01:33:35 |
| @ultranix:matrix.org | I didn't start using follows until devos, what's good about it? every flake follows one nixpkgs commit for example? and you wont need to download a separate one for every flake? | 01:52:07 |
| David Arnold (blaggacao) | Exactly, follows are a necessary consequence of coercing inputs. Remember that overlays is not a language level implementation, but a nixpkgs idiom. | 01:55:03 |
| @ultranix:matrix.org | yes | 01:55:26 |
 @timdeh:matrix.org | I mean follows help keep the closure size under control, which is fine for the flake developer, but it can cause cache misses when used unexpectedly by the consumer | 02:04:31 |
| @timdeh:matrix.org | which is why I debate in my head whether nix even need such a notion (since it also complicates the design a bit) | 02:04:59 |
| @timdeh:matrix.org | In my mind, it might be better to simply cache "hot" flakes like nixpkgs locally and allow flakes to remain immutable. Follows can be seen as an unexpected contract breach, since changing the inputs changes everything about the hash, and I suspect that this may even start to cause bigger headaches when CA becomes a thing. | 02:09:59 |
| David Arnold (blaggacao) | Yeah, with heavy use of follows upstream caches get essentially useless. I think there is only a very nascent push to make the use of release channels more feasible at large (backporting bot). To mitigate the problems you describe, the community at large must also increasingly play by some sort of release heart beat. | 02:15:55 |
