| 12 Nov 2025 |
 just1602 | https://gerrit.lix.systems/c/lix/+/3025/comment/fdf7cf24_c93473f0/
Yeah, that's what peanne were saying here | 17:28:31 |
 raitobezarius | if you are already using async to detect Lix < 2.93, I think you can probably check for one of the usual async helper defined? | 17:28:34 |
| raitobezarius | yep | 17:28:45 |
| raitobezarius | we should definitely start doing that Zoe Z thanks for the ping | 17:28:57 |
|  lavender.pet joined the room. | 19:38:19 |
| 13 Nov 2025 |
 hexa | I'm thankful for how reliably lix tells me when it is waiting on a lock | 02:02:47 |
| raitobezarius | is it actually reliable on that :D ? | 05:39:41 |
 Yureka (she/her) | in staging not staging-next, no? | 07:47:37 |
| Yureka (she/her) | at least I can see staging-next is on curl 8.16.0 and doesn't have any extra patches | 07:47:58 |
| raitobezarius | In reply to @yuka:yuka.dev
at least I can see staging-next is on curl 8.16.0 and doesn't have any extra patches Hm, I am certain I applied patches to curl minimal | 11:14:11 |
| Yureka (she/her) | fix-h2-paused-transfers.patch ? | 11:15:04 |
| Yureka (she/her) | ah then that's trickled down to master as of 17h ago | 11:15:30 |
| 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 |
