!VRULIdgoKmKPzJZzjj:nixos.org

Nix Hackers

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

Load older messages


SenderMessageTime
20 Jul 2021
@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
@tomberek:matrix.orgtomberek pamplemousse: maybe https://github.com/NixOS/nix/blob/master/src/libexpr/eval.hh#L177 23:24:38
@tomberek:matrix.orgtomberekor actually: https://github.com/NixOS/nix/blob/293220bed5a75efc963e33c183787e87e55e28d9/src/libexpr/nixexpr.hh#L16523:30:13
@tomberek:matrix.orgtomberek * pamplemousse: maybe ~~https://github.com/NixOS/nix/blob/master/src/libexpr/eval.hh#L177~~ 23:32:17
24 Jul 2021
@sumner:sumnerevans.comsumner left the room.01:01:11
@jaen:matrix.orgjaen joined the room.11:44:11
@jaen:matrix.orgjaenHello, is this the right place for "nix is behaving very weirdly when trying to build a package flake output and I don't know why"?11:44:42
@abathur:matrix.orgabathur
In reply to @jaen:matrix.org
Hello, is this the right place for "nix is behaving very weirdly when trying to build a package flake output and I don't know why"?
#nix:nixos.org
14:41:41
@balsoft:balsoft.rubalsoft Or #flakes:nixos.org 15:20:32
@abathur:matrix.orgabathur
In reply to @abathur:matrix.org
I'll at least aspire to find some time to read over the changeset and take some notes, as well
~publicly acknowledging that I've been through this at least once and have notes that I'm happy to discuss in private/ephemeral forms. I'm leery of posting them in the open since I'd rather not risk playing any role in exacerbating/prolonging the tension/frustration around this changeset.
18:48:10
@abathur:matrix.orgabathur But I don't think that changes the next-step: getting the conditions people are hoping it would fix under test 18:55:44

Show newer messages


Back to Room ListRoom Version: 6