| 24 Oct 2023 |
 raitobezarius | and I'm not so sure about | 01:02:24 |
| raitobezarius | (a) adding overrideAttrs to lazyDerivation | 01:02:29 |
| raitobezarius | (b) making lazyDerivation overridable | 01:02:33 |
| raitobezarius | (c) removing lazyDerivation from test | 01:02:37 |
| raitobezarius | I feel like this defeat the whole purpose of lazyDerivation to override it | 01:03:31 |
| raitobezarius | Maybe I should hack a way to do "test build failure" inside of the test itself directly… | 01:03:54 |
 Robert Hensing (roberth) | raitobezarius: lazyDerivation has a passthru argument where you can put more stuff if really needed, but I think it'd be cleaner to expose it through the config attribute. ie create a new option that contains the raw test driver without lazyDerivation | 10:03:36 |
| Robert Hensing (roberth) | that way we keep all the internals behind a single attribute, config | 10:03:51 |
| raitobezarius | In this instance I only need a drv that can have overrideAttrs for the test itself | 10:05:11 |
| raitobezarius | So should I do raw test to be the drv and test to be the lazy derivation? | 10:05:36 |
| Robert Hensing (roberth) | https://github.com/hercules-ci/nixpkgs/commit/fbe79d17fb5fdea4777640f353a80b5f1196c1cc | 10:10:49 |
| Robert Hensing (roberth) | is what I had in mind | 10:10:52 |
| Robert Hensing (roberth) | that should give you <test>.config.rawTestDerivation to feed into testBuildFailure | 10:11:11 |
| raitobezarius | OK this is also what I understood | 10:11:31 |
| raitobezarius | Perfect | 10:11:33 |
| 25 Oct 2023 |
|  @federicodschonborn:matrix.org changed their profile picture. | 00:13:16 |
 l0b0 | What's the "Guest root shell did not produce any data yet..." message when running NixOS tests? I think I understand the basic principle (something is waiting for output), but Google wasn't helpful in figuring out what. | 07:02:15 |
| raitobezarius | In reply to @vengmark2:matrix.org
What's the "Guest root shell did not produce any data yet..." message when running NixOS tests? I think I understand the basic principle (something is waiting for output), but Google wasn't helpful in figuring out what. it means that the test driver is waiting for bytes from the guest via the serial socket | 11:45:11 |
| raitobezarius | the spam was recently fixed | 11:45:27 |
| raitobezarius | it happens whenever the serial socket returns empty bytes | 11:45:33 |
| raitobezarius | hm | 11:45:52 |
| raitobezarius | or maybe not | 11:45:54 |
| raitobezarius | it also happens when there is no output for a while | 11:45:58 |
| raitobezarius | e.g. long computations | 11:46:04 |
| l0b0 | Thanks, that leaves the question of why this has suddenly started happening. The obvious one would be OOM killed, but I don't see any mention in the logs of that triggering. | 19:09:18 |
| 26 Oct 2023 |
| Robert Hensing (roberth) | don't kernel panics just hang, or do we configure the kernel not to do that and halt instead? | 15:10:46 |
| Robert Hensing (roberth) | OOM on the host would give an EOF, not hang | 15:10:58 |
| raitobezarius | no kernel panic will just hang | 15:11:00 |
| raitobezarius | UEFI panic would hang too | 15:11:11 |
| l0b0 | In reply to @raitobezarius:matrix.org
UEFI panic would hang too It's pretty random (~80% of runs), so it would be really weird if somehow I managed to trigger something that low-level. | 19:29:28 |
