| 6 Sep 2025 |
 K900 | Supposedly fixed in v6 but I'm not going to find out | 13:18:55 |
| K900 | Possibly ever | 13:18:59 |
 aloisw | Well integrated in what sense? | 13:19:10 |
 raitobezarius | in the sense of supporting multiple interfaces | 13:19:26 |
| aloisw | What do you mean by "supporting multiple interfaces"? | 13:20:13 |
| raitobezarius | DNS server per link | 13:20:24 |
| aloisw | Also weird timeouts when the machine is offline. | 13:20:36 |
| aloisw | I'm not sure I understand what you would like to do there? | 13:22:59 |
| raitobezarius | systemd-resolved supports answering to DNS queries which are meant for a specific link with a DNS server specific to that link | 13:23:25 |
| raitobezarius | useful when you have a VPN with its own DNS server for internal zones | 13:23:37 |
| aloisw | So basically multiplexing between different upstreams, with both the zone and the upstream server assigned to the link in some way? | 13:29:06 |
| raitobezarius | yep | 13:29:12 |
| aloisw | Yeah I'd not really expect unbound or knot-resolver to support that in a nice way indeed. Their expected use case seems more to let them do recursion themselves. | 13:31:00 |
| aloisw | I guess if the links are static, you could configure the forwarding manually. But it's going to be annoying if they can come and go dynamically. | 13:39:46 |
| 7 Sep 2025 |
 emily | raitobezarius: do you have an estimate for how soon you plan to amend the drop PR in Nixpkgs? | 02:35:38 |
| emily | would be great to move forward with toml11 and if 2.93 is all that's required there it would be convenient | 02:35:54 |
| emily | (or I could just mark the other ones broken :P) | 02:37:40 |
| aloisw | What do I have to enter into buildkite to manually start a job for a given CL again? I forgot whether to put the commit hash into its field and what to put in the branch. | 09:32:28 |
| aloisw | What the heck is going on here? That's nixpkgs 24.11 before the toml11 bump: https://buildkite.com/lix-project/lix/builds/4357#01992389-f64c-4437-a922-998d418e1dec/38-47 | 09:57:16 |
 Sergei Zimmerman (xokdvium) | 24.11 nixpkgsLibTests evalutated the misc.nix tests with the host nix, not the one that's being tested. Might be that the CI is dogfooding a recent build of Lix? | 10:06:29 |
| aloisw | Still happening on 25.05: https://buildkite.com/lix-project/lix/builds/4358#019923aa-4e21-4225-bfca-d98763a1e5da/30-39 | 10:55:39 |
| aloisw | Also aarch64-linux only, what the heck. | 10:56:01 |
| Sergei Zimmerman (xokdvium) |
- Which lix is the CI running and 2. Nixpkgs input probably needs https://github.com/NixOS/nixpkgs/pull/434761
| 11:12:15 |
| aloisw |
- is for the infra folks to answer. 2. should probably be done on all branches then?
| 11:34:07 |
| aloisw | I guess a different Lix running on the x86_64-linux and aarch64-linux builders could explain the difference. | 11:34:42 |
| Sergei Zimmerman (xokdvium) | I imagine some runners are running newer Lix that has emily’s stack merged. That issue is exactly why we had to revert the initial patch to nix and only reapplied it only when that PR backport landed. | 11:40:35 |
| aloisw | Yeah I just don't have the insights into the infra to be sure this is indeed the case. | 11:41:47 |
| Sergei Zimmerman (xokdvium) | Everything points to that tbh. In cppnix we are dogfooding all PR GHA CI with the top of trunk as the host nix | 11:42:50 |
| Sergei Zimmerman (xokdvium) | And the exact issue immediately surfaced | 11:44:52 |
| raitobezarius | We don't do the same because the host Nix in the Buildkite agents is not dynamic | 11:59:56 |
