| 12 Nov 2025 |
 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 |
| 13 May 2024 |
|  zrsk joined the room. | 13:37:30 |
|  dariof4 joined the room. | 14:16:05 |
|  abbe joined the room. | 14:42:22 |
 mjm | lix is now in nixos-unstable, what's the best way to use it in a NixOS config? | 15:47:41 |
 K900 | nix.package = pkgs.lix | 15:47:54 |
| K900 | Probably | 15:47:58 |
| K900 | Or just keep using the module | 15:48:02 |
 puck | you can use nix.package = pkgs.lix; if you want; but using the overlay will guarantee more updates (tho less binary cache) | 15:48:44 |
| mjm | well, the module/overlay doesn't easily support using the one from nixpkgs | 15:48:44 |
