| 18 Aug 2025 |
 emily | Nixpkgs has some problems with this too. (where two parties in a PR will deadlock waiting for the other to hit the button) | 15:36:33 |
 raitobezarius | (I'd also prefer that but the merge queue situation means that I have more people demanding why something is not merged than anything and teaching everyone about Gerrit's etiquette takes a lot of energy) | 15:36:39 |
| raitobezarius | (so I have a more complicated hybrid strategy where I do take care of things and do merge things) | 15:36:50 |
| emily | merge queues would be very nice | 15:36:55 |
| emily | having two stacks that you have to babysit the rebase ordering of to get the tests happy to merge is tedious | 15:37:10 |
| emily | does the Snix thing for that not work well? | 15:37:16 |
| raitobezarius | It has bugs and it would take much more energy to take care of these bugs or cleanup after a massive disaster in production | 15:37:36 |
| raitobezarius | So until I have a window of opportunity for removing this painpoint, manual and tedious is fine as I have a bird view of everything and I know my way through all the ecosystem easily | 15:38:27 |
| raitobezarius | The only problem are well, these situations :) | 15:38:32 |
| raitobezarius | * The only problems are well, these situations :) | 15:38:35 |
| raitobezarius | In reply to @raitobezarius:matrix.org
It has bugs and it would take much more energy to take care of these bugs or cleanup after a massive disaster in production (which are not a virtual problem, they happened.) | 15:40:38 |
| raitobezarius | emily i verified what i wanted on cl/3852 | 15:43:19 |
| raitobezarius | emily also consider abandoning the alternative path at this point | 15:43:47 |
| raitobezarius | it confuse me always when i encounter while looking at the relation chain | 15:43:56 |
| raitobezarius | (we can always un-abandon it if needed) | 15:44:02 |
| emily | 3869 you mean? can do when I get back to the stack. possibly later today. still have some thoughts I need to post about 3870 (but I've been running it and it's been fine) | 15:56:01 |
| emily | need to get the reproducibility stuff sent out to Nixpkgs but hopefully I will get to that part of the backlog today | 15:56:30 |
| raitobezarius | dw | 17:47:03 |
| raitobezarius | emily does https://git.lix.systems/lix-project/lix/issues/966#issue-14037 ring a bell to you? | 22:34:58 |
| raitobezarius | sounds like something related to the range we just merged | 22:35:06 |
| raitobezarius | it's a no sandboxing case so… | 22:35:12 |
| raitobezarius | actually, the range is larger | 22:35:48 |
| emily | what's the tests right after the ones reported | 22:41:55 |
| emily | the flake ones are really slow but I guess not hours slow | 22:42:04 |
| raitobezarius | obviously this would be too easy if the ordering was consistent | 22:43:51 |
| raitobezarius | i don't know | 22:43:57 |
| raitobezarius | asking more info | 22:44:26 |
| 19 Aug 2025 |
 Kira | hi! i noticed that libsodium, one of the crypto libraries needed for lix, is lead by someone who thinks that vibe coding is an effective way of building software: https://www.reddit.com/r/vibecoding/comments/1kmptbo/my_first_significant_100_vibecoded_project.
i don't know that much about libsodium, but just that fact that lix relies on a crypto library managed by one person already makes me nervous.
it looks like it was added to support ed25519 signing keys in 2015 for binary caches (https://git.lix.systems/lix-project/lix/commit/e0def5bc4b41ad09ce3f188bf522814ef3389e1f), but it looks like openssl supports them now too. would it be worth it to replace it with openssl and drop the dependency? | 01:42:40 |
| Kira | (i was mainly looking into jedisct1 because i was looking more into who works on dnscrypt-proxy2, but also noticed he maintains libsodium) | 01:46:47 |
| Kira | * (i was mainly looking into jedisct1 because i was looking more into who works on dnscrypt-proxy2, but also noticed he built & maintains libsodium) | 01:48:49 |
