| 12 Nov 2025 |
 Zoe Z | yeah, that was what I was struggling with | 17:27:18 |
 raitobezarius | yeah i think preprocessor doesn't offer any way | 17:27:44 |
| raitobezarius | we need to define this in meson directly i guess | 17:27:51 |
 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 |
