!VRULIdgoKmKPzJZzjj:nixos.org

Nix Hackers

856 Members
For people hacking on the Nix package manager itself187 Servers

Load older messages


SenderMessageTime
15 Jul 2021
@niksnut:matrix.orgniksnutPlease make an issue about it. We should switch to unlinkat() and friends...10:32:34
@andi:kack.itandi-Will do. Just don't have my GH creds here right now.10:47:45
@mic92:nixos.devMic92I also beliefe that nix-serve does not work with ca-derivations16:11:51
@mic92:nixos.devMic92I have to check again16:11:58
@mic92:nixos.devMic92But after enabling I got 500er errors I believe16:12:17
@theophane:hufschmitt.netRegnat
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:nixos.devMic92 Regnat: Thanks. Logged it here: https://github.com/edolstra/nix-serve/issues/20 06:56:17
@nixinator:nixos.devnixinator joined the room.23:34:38
18 Jul 2021
@aanderse:nixos.devaanderse joined the room.15:55:47
@aanderse:nixos.devaanderse changed their display name from Aaron Andersen to aanderse.15:58:49
@disrupt_the_flow:matrix.orgdisrupt_the_flow joined the room.20:21:42
20 Jul 2021
@vcunat:matrix.orgVladimír Čunát joined the room.14:53:43
@vcunat:matrix.orgVladimí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:balsoft.rubalsoft What does -Q even do? 15:21:43
@vcunat:matrix.orgVladimír Čunát Now it was nix-shell -Q mainly (= --no-build-output). 15:35:58
@balsoft:balsoft.rubalsoftAh15:36:29
@cw:kernelpanic.cafecontinuouswave changed their display name from cw (Vi/Vim) to continuouswave.20:34:53
@pamplemouss_:matrix.orgpamplemousse 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
@pamplemouss_:matrix.orgpamplemousseI 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
@pamplemouss_:matrix.orgpamplemousse Any ideas / pointers about global state in nix? 23:21:55
@pamplemouss_:matrix.orgpamplemousse * Any ideas / pointers about whether there is a global state in nix? 23:22:09
21 Jul 2021
@mic92:nixos.devMic92 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:nixos.devMic92I wonder if there is a generic way of clearing out statics by resetting BSS of a library05:37:13
@mic92:nixos.devMic92This is probably still faster than a full fork05:37:37
@mic92:nixos.devMic92You can find all global variables in gdb easily (info variables). Maybe there is a way to filter by library05:39:02
@mic92:nixos.devMic92 * 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:matrix.orgtomberekLooking at: https://github.com/NixOS/nix/pull/1565 (maybe discussion here can help unblock). Are there reservations or issues unresolved?17:44:07
@abathur:matrix.orgabathur
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:matrix.orgabathur

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:matrix.orgabathur

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

There are no newer messages yet.


Back to Room ListRoom Version: 6