| 13 Nov 2025 |
 raitobezarius | Yes, good | 11:19:02 |
 lillecarl | When developing my registrationtime updating code I consistently hit https://git.lix.systems/lix-project/lix/src/branch/main/lix/libstore/local-store.cc#L784 until I moved the update query around a little bit so I'm not so sure. Database was never corrupted. As far as I'm able to comprehend I'm trying to lock the correct way. I don't know what the takeaway here is but it was curious to troubleshoot 😆 | 12:19:43 |
| raitobezarius | maybe you incorrectly expired entries from the DB? | 12:20:34 |
| lillecarl | I just update the time, never remove anything. But actually looking at it again. Why is there no RETRY_SQLITE around https://git.lix.systems/lix-project/lix/src/branch/main/lix/libstore/local-store.cc#L780 like all other query functions in this class? 🤔 | 12:21:39 |
| raitobezarius | because it's probably up to the caller to do the retry and there might be some optimistic querying happening here? | 12:22:08 |
| lillecarl | Possibly, but moving my own query to execute after rather than before whatever the daemon op was doing worked. I'll check the paths that call queryValidPathId | 12:24:43 |
| lillecarl | * Possibly, but moving my own query to execute after rather than before whatever the daemon op was doing worked. I'll check the paths that call queryValidPathId
Edit: Yep all of them are from within retry SQLite lambdas | 12:25:23 |
| lillecarl | I believe there's something lurking here, while I'm doing updates in "query code" I don't see how running update before a select could trigger this | 12:27:35 |
| 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 |
