| 18 Mar 2026 |
 raitobezarius | In reply to @piegames:flausch.social
I restate my position here that retriggering CI builds should not be a gated permission and instead be accessible to all logged-in users I did not buy the Buildkite company yet alas | 23:20:31 |
| raitobezarius | (and I am not sure that a bot would make things more discoverable but maybe, not sure) | 23:21:50 |
 delroth | CI failure UI on the gerrit side could include instructions on how to retrigger via bot | 23:22:39 |
| delroth | (and I presume besadii could listen for gerrit CL comments, for example?) | 23:23:03 |
| raitobezarius | Yup | 23:24:24 |
| 19 Mar 2026 |
 sky1e | When I encounter a spurious CI failure, what I do is wait until someone else merges a cl and rebase my change on top and push. Not always the fastest, but doesn't involve asking anyone for help, which I'm rather bad at 🙃 | 02:00:05 |
 Winter | raitobezarius doing a bit of maintenance to the lix package set in nixpkgs, i remember mention of some weird self ref in nix-direnv. when trying to repro that, it appears that… all packages in the set are currently infreccing? e.g.:
(import ./. {
overlays = [(f: p: { inherit (p.lixPackageSets.latest) nixpkgs-review; })];
}).nixpkgs-review
| 03:29:31 |
| Winter | is this known? | 03:29:35 |
 aloisw | Yes, it is known that overlaying like this does not work. The only things it works for are Lix itself and its nix-eval-jobs. | 05:24:19 |
| Winter | i was under the (i guess false!) impression that it was only for a handful of bad derivations (e.g. nix-direnv), but i guess it’s actually never worked at all? it should probably be removed from the website then if this is indeed true | 05:35:14 |
| Winter | there was a Lix discussion at the time, but https://git.lix.systems/lix-project/lix-website/commit/26676b416a334fb69a7f6a2ac3d8464f321f4cca is what i remember | 05:37:38 |
| raitobezarius | https://git.lix.systems/lix-project/lix/issues/980#issue-14093 it's known for the past 6 months | 09:08:57 |
| raitobezarius | with no resolution yet | 09:08:59 |
| raitobezarius | we are planning to delete these instructions | 09:09:04 |
 Lisanna | is there a process for cloning a cppnix issue into the lix issue tracker? or does it happen automatically | 20:17:19 |
| raitobezarius | there's no automation of the sort as we have diverged quite | 20:24:39 |
| raitobezarius | so we usually want people to open their own issues they encountered on lix | 20:24:53 |
| raitobezarius | (mentions of cppnix sharing the same issue are welcome but are not super useful these days imho except if it's certain by the reporter there's a shared subsystem there) | 20:25:10 |
| sky1e | I noticed when hacking on lix's JSON parser that it silently accepts duplicate json object keys, throwing away all but the last one. Is this known and desired behavior? I tried making it crash instead and it seemed to still pass all of the tests, so this behavior isn't being tested for.
nix eval --expr 'builtins.fromJSON '"''"'{"a":"a","a":"b"}'"''"
{ a = "b"; }
| 23:17:47 |
| *  piegames sighs | 23:38:57 |
| piegames | This language truly is a gift | 23:39:07 |
| sky1e | Shall I file an issue then? | 23:39:42 |
 Sergei Zimmerman (xokdvium) | In reply to @piegames:flausch.social
This language truly is a gift I wouldn’t be surprised if that changed from 2.3 when nlohmann was introduced | 23:47:32 |
| piegames | In reply to @sky1e:mildlyfunctional.gay
Shall I file an issue then? Yes please | 23:47:55 |
| raitobezarius | In reply to @sky1e:mildlyfunctional.gay
Shall I file an issue then? Please do so | 23:48:25 |
| 20 Mar 2026 |
| sky1e | https://git.lix.systems/lix-project/lix/issues/1162 | 00:10:00 |
 thubrecht | Looking at the previous json parser, it also silently ignored duplicates and kept only the last value | 09:01:28 |
| thubrecht | https://github.com/NixOS/nix/blob/0baf7dc25e0a5fcd25dcd9d9cb737c682d01e4e7/src/libexpr/json-to-value.cc#L69-L92 | 09:01:59 |
| delroth | https://www.rfc-editor.org/rfc/rfc8259#section-4 "The names within an object SHOULD be unique." not "MUST", so a parser should support duplicate keys anyway | 09:26:35 |
| delroth | though the RFC also says "lol it's unpredictable what parsers will do and some throw errors" | 09:26:59 |
