| 9 Oct 2024 |
 V. 🏳️⚧️ | ----------------------------------- stdout -----------------------------------
Running main() from /build/source/googletest/src/gtest_main.cc
../tests/unit/libexpr/trivial.cc:216: Failure
Expected: eval("let add = l: r: l + r; in ''a'' |> add ''b''") throws an exception of type Error.
Actual: it throws nothing.
| 18:01:16 |
 K900 | The tests depending on global config is a known problem | 18:02:05 |
 piegames | There's a CL for it I think CC @jade_:matrix.org | 18:09:42 |
| V. 🏳️⚧️ | In reply to @vigress9:matrix.org
These tests have been broken for a few weeks now. Is this known / expected?
82/163 lix:installcheck / functional-build-remote-input-addressed FAIL 0.30s exit status 1
93/163 lix:installcheck / functional-build-remote-content-addressed-fixed FAIL 0.39s exit status 1
94/163 lix:installcheck / functional-build-remote-content-addressed-floating FAIL 0.38s exit status 1
95/163 lix:installcheck / functional-build-remote-trustless-should-pass-0 FAIL 0.42s exit status 1
96/163 lix:installcheck / functional-build-remote-trustless-should-pass-1 FAIL 0.38s exit status 1
97/163 lix:installcheck / functional-build-remote-trustless-should-pass-2 FAIL 0.43s exit status 1
98/163 lix:installcheck / functional-build-remote-trustless-should-fail-0 FAIL 0.29s exit status 100
99/163 lix:installcheck / functional-build-remote-trustless-should-pass-3 FAIL 0.43s exit status 1
115/163 lix:installcheck / functional-supplementary-groups FAIL 0.15s exit status 1
116/163 lix:installcheck / functional-linux-sandbox FAIL 0.26s exit status 100
119/163 lix:installcheck / functional-shell FAIL 0.65s exit status 1
153/163 lix:installcheck / functional-nested-sandboxing FAIL 0.30s exit status 1
These tests fail since at least https://git.lix.systems/lix-project/lix/commit/5f298f74c92402a8390b01c736463b17b36277e3 | 18:14:59 |
| V. 🏳️⚧️ | The earliest I've tried | 18:15:16 |
| V. 🏳️⚧️ | * The oldest commit I've tried | 18:16:24 |
| piegames | "Error while fetching results for checks: Error message from plugin 'checks': {}" is CI broken for everyone or just me? | 19:01:15 |
 puck | you're not signed into buildbot; somehow noone bothered fixing that error, i should've really done that at some point | 19:07:16 |
| puck | or, hrm | 19:07:47 |
| puck | no, it's a misconfiguration of buildbot | 19:08:01 |
| puck |
access-control-allow-origin: https://*.lix.systems
| 19:08:16 |
| piegames | CC raitobezarius, I think you were touching buildbot things recently? | 19:10:59 |
 raitobezarius | oopsie | 19:12:02 |
| raitobezarius | yeah | 19:12:04 |
| raitobezarius | wildcards are not supported | 19:12:08 |
 jade_ | In reply to @piegames:flausch.social
There's a CL for it I think CC @jade_:matrix.org correct. i wonder why that has not got merged, i will have to look at it again | 19:54:43 |
| piegames | can you link to it again please? lost the link | 19:55:34 |
| jade_ | In reply to @vigress9:matrix.org
nix-build --attr packages.x86_64-linux.default
And just setup / build / install / test both result in this
you can use --keep-failed and it will keep the build-dir that failed and give you more meson logs, but...
this is really weird that it's consistently broken on your machine and on gha and that not really anyone else seems to be hitting it
| 19:55:50 |
 KFears (tragedy arc) | For Lix, are Flakes and 2.4 CLI still considered "experimental" features in the broad sense? | 20:09:08 |
| K900 | Yes | 20:18:22 |
| jade_ | in my personal opinion (not necessarily that of everyone working on lix), working on and near flakes code has made me rather strongly opposed to stabilization because the code is so fragile that it is nearly impossible to make any changes to, and without serious changes in the dynamics of how everyone deals with flake.lock files, stabilization is impossible. | 20:20:35 |
| jade_ | does this mean we will break it? no. we can't break it. we also can't change it. we can't improve it. | 20:21:07 |
| jade_ | i would have to check on our history of flake refactors and the percentage that have caused incompatibilities but it is way too high. this is in turn because the lock file code is busted, which is in turn substantially because the entire idea of a flake ref as a url with no separation of flake specific parameters from other url parameters is busted, which also infects libfetchers and fetchTree at the very foundation of flakes.
cppnix wants to stabilize fetchTree and i am not sure how they propose to do that without themselves signing up for years of tears | 20:23:24 |
| jade_ | lock files have to be sufficiently specified in a vendor neutral way but also sufficiently loosely checked for equivalence that implementations are allowed to be different | 20:26:56 |
 just1602 | Would there be a way for lix to versioned the flake spec and implementation, stay compatible with the actual state of this mess, but iterate and improve in a v2 of the spec / implementation? | 20:30:40 |
| jade_ | we have other things that are higher priority than redesigning flakes but redesigning flakes is certainly a possibility | 20:32:12 |
| jade_ | but the thing is that all of the internals are so tangled with the lock file format that you can't really change the internals without copy pasting vast amounts of code | 20:32:34 |
| jade_ | and preserving interop with cppnix | 20:32:41 |
