| 15 Jul 2021 |
 niksnut | Please make an issue about it. We should switch to unlinkat() and friends... | 10:32:34 |
 andi- | Will do. Just don't have my GH creds here right now. | 10:47:45 |
 Mic92 | I also beliefe that nix-serve does not work with ca-derivations | 16:11:51 |
| Mic92 | I have to check again | 16:11:58 |
| Mic92 | But after enabling I got 500er errors I believe | 16:12:17 |
 Regnat | In reply to @mic92:nixos.dev
I also beliefe that nix-serve does not work with ca-derivations Yeah it most certainly doesn’t, if only because it doesn’t provide /realisations | 16:38:01 |
| 16 Jul 2021 |
| Mic92 | Regnat: Thanks. Logged it here: https://github.com/edolstra/nix-serve/issues/20 | 06:56:17 |
|  nixinator joined the room. | 23:34:38 |
| 18 Jul 2021 |
|  aanderse joined the room. | 15:55:47 |
| aanderse changed their display name from Aaron Andersen to aanderse. | 15:58:49 |
|  disrupt_the_flow joined the room. | 20:21:42 |
| 20 Jul 2021 |
|  Vladimír Čunát joined the room. | 14:53:43 |
| Vladimír Čunát | A quick question in case you know: I now switched to using nixUnstable utils (so that I can try new nix flake and similar stuff) while keeping stable nix daemon. But it seems that -Q flag got somehow broken by that. Am I doing something wrong? | 14:56:34 |
 balsoft | What does -Q even do? | 15:21:43 |
| Vladimír Čunát | Now it was nix-shell -Q mainly (= --no-build-output). | 15:35:58 |
| balsoft | Ah | 15:36:29 |
|  continuouswave changed their display name from cw (Vi/Vim) to continuouswave. | 20:34:53 |
 pamplemousse | Hey,
I am writing a harness function for an in-process fuzzer (https://llvm.org/docs/LibFuzzer.html#fuzz-target), that constructs a state, builds an expression from the Data parameter, and evaluates and parses it.
It seemed to be okay, except this harness function is called in a loop, and it seems to cause errors when called on the second time.
To make the matter more mysterious, the expression crashing ^ does not crash when run by the harness independently (the loop runs once, on this entry). | 23:20:33 |
| pamplemousse | I am led to believe that there is some global state that I should be clearing manually at the end of the loop body. | 23:21:19 |
| pamplemousse | Any ideas / pointers about global state in nix? | 23:21:55 |
| pamplemousse | * Any ideas / pointers about whether there is a global state in nix? | 23:22:09 |
| 21 Jul 2021 |
| Mic92 | pamplemousse: you probably already disabled BoehmGC, I think libutil/serialise.cc has some global state. All parsed command line arguments are static and spread over the modules. Machines in libstore/machines.cc are static. | 05:36:27 |
| Mic92 | I wonder if there is a generic way of clearing out statics by resetting BSS of a library | 05:37:13 |
| Mic92 | This is probably still faster than a full fork | 05:37:37 |
| Mic92 | You can find all global variables in gdb easily (info variables). Maybe there is a way to filter by library | 05:39:02 |
| Mic92 | * You can find all global variables in gdb easily (info variables). Maybe there is a way to filter by library | 05:39:13 |
| 22 Jul 2021 |
 tomberek | Looking at: https://github.com/NixOS/nix/pull/1565 (maybe discussion here can help unblock). Are there reservations or issues unresolved? | 17:44:07 |
 abathur | In reply to @tomberek:matrix.org
Looking at: https://github.com/NixOS/nix/pull/1565 (maybe discussion here can help unblock). Are there reservations or issues unresolved? erg | 17:56:16 |
| abathur | tomberek: Some thoughts on 1565 itself:
- My understanding, from accidentally stepping into ~this (but, in a courtesy PR to another project he works on) anton is profoundly (and understandably) unhappy/frustrated with how this PR went.
- It's unfortunate people keep finding that and commenting on it. When it comes up, it triggers a frustrated outburst (or a whole flurry of them). IMO the discussion should be locked regardless of who closes it.
- Per the above (and having been in roughly this position myself), I would be extremely surprised if he will do any more work on it. Even if he did, I think it would be a bad idea to try. He'll be agitated. It'll probably be testy and delicate. I can't imagine this moving forward without someone else picking it up in one or more new PRs.
| 18:19:56 |
| abathur | General scattered thoughts on the installer:
- The installer has moved on since 1565 was done. Even if it isn't enough to merit re-doing it from scratch, it's enough to require thinking through how the PR's intent should affect those changes.
- My ~feelings on it are vaguely in line with what Anton expresses. I find the ongoing installer pain as a little embarrassing. I find it frustrating that the project needlessly-squanders good-will on first encounters, and even more frustrating that I don't see much interest in fixing it. I find responding to people having trouble with stuff that's already fixed in master but unreleased frustrating. Everyone's squeamish about touching it. If someone wants to make a larger change, there's no obvious group of stakeholders to seek buy-in from.
- I'd like it to be a lot better. And I don't actually think it'd be that hard. But I'm also not looking to adopt it, so I'm trying to just put it out of mind until some others are stepping up.
- After basic support for testing it in CI merged in March, it should be much easier to work on the installer now than it used to be.
- I (personally) see the obvious next step as investing in an installer test suite that stakes out both what the installer does and should support (including whatever portability issues matter). I've been trying to fish for interest in this (ex: https://discourse.nixos.org/t/installer-test-suite-small-project-s-high-leverage-help-wanted/13662) without much luck so far.
- I think a predictable release cadence as Eelco describes in https://discourse.nixos.org/t/nix-release-schedule-and-roadmap/14204/2 will help with improving the installer. It'll provide a stronger feedback signal on whether old issues have actually been fixed, and a commitment to maintain a releasable master branch could make an installer test suite a good lever for focusing attention on fixing broken scenarios.
| 19:14:43 |
