!VRULIdgoKmKPzJZzjj:nixos.org

Nix Hackers

902 Members
For people hacking on the Nix package manager itself189 Servers

Load older messages


SenderMessageTime
18 Jul 2021
@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
@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 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:15:10
@tomberek:matrix.orgtomberek I’ll take a look at existing tests and see what gaps there are. At the least try to assess old and new installers. With luck this can be added to an upcoming milestone. 20:50:21
23 Jul 2021
@abathur:matrix.orgabathur
In reply to @tomberek:matrix.org
I’ll take a look at existing tests and see what gaps there are. At the least try to assess old and new installers. With luck this can be added to an upcoming milestone.
I'll at least aspire to find some time to read over the changeset and take some notes, as well
14:12:26
@tomberek:matrix.orgtomberekI updated the nix-tests-terraform (https://github.com/tomberek/nix-tests-terraform) and have a failure on Alpine, but seems to be due to a groupadd/addgroup mixup in the setup.17:03:08
@tomberek:matrix.orgtomberek I’ll look at Graham’s test matrix next. 17:36:48
@danielle:fairydust.spacedanielle changed their profile picture.22:50:23
@mjolnir:nixos.orgmjolnir banned @kreyren:tchncs.dekreyren (Inappropriate and destructive behavior.).22:54:50
@pamplemouss_:matrix.orgpamplemousse I am confused by some code in the evaluator:
https://github.com/NixOS/nix/blob/master/src/libexpr/eval.cc#L1152
What's e here? Where does it come from (where does it receives a value)?
23:18:40
@pamplemouss_:matrix.orgpamplemousseCould anyone enlighten me please?23:18:58
Room Avatar Renderer.23:23:04

Show newer messages


Back to Room ListRoom Version: 6