| 16 Jun 2025 |
 emily | right | 04:33:42 |
| emily | assertion = !config.networking.useHostResolvConf;
| 04:33:43 |
 hexa | by fighting I mean kresd enabling useLocalResolver | 04:33:45 |
 @emma:rory.gay | me confingufing DNS via etc."resolv.conf" bypassing both resolved and resolvconf 👀 | 04:33:45 |
| emily | this should probably be extended | 04:33:48 |
| hexa | and not winning | 04:33:50 |
| @emma:rory.gay | * me configuring DNS via etc."resolv.conf" bypassing both resolved and resolvconf 👀 | 04:33:59 |
| hexa | so the fight is somewhere in the nixos logic | 04:34:01 |
| hexa | not necessarily in the resolvconf logic | 04:34:06 |
| emily | right | 04:34:10 |
| emily | I don't know if resolvconf + resolved is supported at all. if it's not, then the latter should probably assert on all of the former's options it doesn't implement | 04:34:26 |
| emily | hmm, resolvconf has default = !(config.environment.etc ? "resolv.conf");, but no hard assertion against enabling it anyway | 04:35:06 |
| emily | and the resolved module does networking.resolvconf.package = pkgs.systemd; | 04:35:14 |
| hexa | does resolved just bypass the module system for resolv.conf? | 04:35:20 |
| emily | (for the resolvconf command) | 04:35:30 |
| emily | no, it uses the module system to link it to the /run path | 04:35:52 |
| emily | resolvconf bypasses it entirely | 04:35:55 |
| emily | I think that we need an assertion preventing both services.resolved.enable and networking.resolvconf.enable | 04:37:25 |
| emily | however I suspect in your case stuff is setting networking.resolvconf.useLocalResolver but not networking.resolvconf.enable explicitly | 04:37:37 |
| hexa | right | 04:37:38 |
| emily | so there's not an actual conflict, just networking.resolvconf.enable defaulting off because there's an explicit resolv.conf symlink because of services.resolved.enable | 04:38:00 |
| emily | and I'm not sure if asserting on networking.resolvconf.useLocalResolver when !networking.resolvconf.enable makes sense | 04:38:11 |
| emily | since usually module options are meant to be inert if the module is not enabled | 04:38:18 |
| emily | (agreed that there's a UX issue here I'm just not sure what the best solution is) | 04:38:36 |
| emily | it might be best to move the useLocalResolver outside of the resolver services altogether | 04:40:10 |
| emily | since arguably enabling a service changing your resolv.conf is a bit action-at-a-distance to begin with | 04:40:35 |
| emily | alternatively, lift useLocalResolver outside of networking.resolvconf, have services.resolved.enable either handle it or assert on it | 04:41:09 |
| 17 Jun 2025 |
|  jopejoe1 (4094@39c3) changed their display name from jopejoe1 (4094@eh22) to jopejoe1 (4094@GPN23). | 12:06:53 |
 Zhaofeng Li | by the way, has anyone tried one of those smart SFP optics? | 15:53:38 |
| Zhaofeng Li | not a new thing (might have even mentioned this in this channel), but never really got to give it a try | 15:53:58 |
