| 13 Nov 2025 |
 lillecarl | I've never touched async C++ before fiddling with Lix though but my intuition says I'm not doing something overly wrong, unsupported for sure but not "database is corrupt" wrong | 12:29:29 |
| lillecarl | I didn't open an immediate txn 💡 | 12:36:53 |
|  Alicia joined the room. | 22:59:09 |
|  adam joined the room. | 23:28:32 |
| 14 Nov 2025 |
 Waldemar Tomme (they/them) | A bit out of the blue but I currently have the problem that lix eval (but I think also other commands) times out downloading sources but if I invoke curl directly (or in the browser) everything works fine. Does anyone know why this might happen? (verison 2.93.3)
It also seems kinda random for what sources because some do work but others not. Temporarly using nix (from nixpkgs which miracously worked) works as intended at least for the templates flake.
> nix eval github:NixOS/templates#templates
warning: error: unable to download 'https://github.com/NixOS/templates/archive/2557dc639215476df149ae6842a1ae94d60a884c.tar.gz': Resolving timed out after 5001 milliseconds (curl error code=28); retrying in 256 ms (attempt 1/5)
warning: error: unable to download 'https://github.com/NixOS/templates/archive/2557dc639215476df149ae6842a1ae94d60a884c.tar.gz': HTTP error 302 () (curl error code=28: Resolving timed out after 5001 milliseconds)
| 09:35:49 |
 K900 | Sounds like DNs | 10:02:43 |
| K900 | * | 10:02:47 |
 raitobezarius | Yep | 10:16:31 |
| raitobezarius | Check that you can resolve things under 5s, that is, check the first DNS server is not dysfunctional in your resolv conf | 10:16:59 |
| raitobezarius | This behavior is fixed in HEAD and there should be a much more graceful timeout mechanism | 10:17:19 |
| Waldemar Tomme (they/them) | I currently have 3 nameserver in my resolv.conf and all of them resolve github.com in ~0.05s but lix eval still timeouts | 10:20:04 |
|  afajl joined the room. | 10:55:52 |
 hexa | could also be stuck at e.g. tls handshake | 12:10:33 |
|  Michaili K joined the room. | 13:56:08 |
| Michaili K | hi everyone! i stumbled upon what seems to be a lix-specific bug when trying to evaluate flakes from non-writable path (e.g. github urls.) i get different outcomes when evaluating github:mrshmllow/affinity-nix#v3 from Nix vs Lix:
$ nix run github:NixOS/nixpkgs/nixos-unstable#nix eval github:mrshmllow/affinity-nix#v3
«derivation /nix/store/8yysj7jqfk1d1cbn529zr6drl3lvbd0w-Affinity-v3-.drv»
$ nix run github:NixOS/nixpkgs/nixos-unstable#lix eval github:mrshmllow/affinity-nix#v3
error:
… while updating the lock file of flake 'github:mrshmllow/affinity-nix/f07c94d5771a07cb63b7010870ae49a5956b4b01'
error: cannot write modified lock file of flake 'github:mrshmllow/affinity-nix' (use '--no-write-lock-file' to ignore)
It seems to be caused by our CI running Nix, which is renaming rev -> ref in the flake.lock https://github.com/mrshmllow/affinity-nix/commit/f07c94d5771a07cb63b7010870ae49a5956b4b01
When evaluating anything locally with Lix, I can observe that Lix rewrites the flake.lock to rename rev -> ref. Likewise, when I evaluate with Nix again locally, I can observe Nix rewriting the flake.lock to rename ref -> rev again. Q: Is this an issue in Lix or is there anything we should change ourselves?
| 14:03:59 |
| Michaili K | something i just figured out: this happens when using ?ref in a flake's input url, e.g. github:nixos/nixpkgs?ref=nixos-unstable, this issue does not occur with github:nixos/nixpkgs/nixos-unstable | 14:14:56 |
| Michaili K | * something i just figured out: this happens when using ?ref in a flake's input url, e.g. inputs.nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable", this issue does not occur with inputs.nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable" | 14:15:19 |
| Michaili K | * something i just observed: this happens when using ?ref in a flake's input url, e.g. inputs.nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable", this issue does not occur with inputs.nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable" | 14:16:07 |
| Michaili K | at this point this could also be a Nix bug for all i know lol | 14:17:00 |
 aloisw | In reply to @hexa:lossy.network
could also be stuck at e.g. tls handshake That wouldn't normally be "resolving". | 15:40:02 |
| aloisw | In reply to @michailik:matrix.org
something i just observed: this happens when using ?ref in a flake's input url, e.g. inputs.nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable", this issue does not occur with inputs.nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable" There has been some regression around ref around 2.91, uncaught and unfixed because no one cares about flakes enough. | 15:46:59 |
| raitobezarius | aloisw do you remember the issue number for this one? | 19:48:03 |
| raitobezarius | i think it's time we mark it release blocker | 19:48:07 |
| raitobezarius | but i hate being responsible for these ones :'( | 19:48:20 |
| raitobezarius | but i should probably touch flakes code to execute on out of core extraction | 19:48:37 |
| raitobezarius | https://git.lix.systems/lix-project/lix/issues/520 | 19:54:21 |
| aloisw | https://git.lix.systems/lix-project/lix/issues/841 is the one I had in mind. | 19:54:23 |
| aloisw | Contrary to the comment that caused me to get pinged on it, I do not think it was me who broke it. | 19:54:46 |
| raitobezarius | yeah, nw | 19:55:09 |
| raitobezarius | I think the 2.94.0 train will depart soon | 19:55:19 |
