SIG Core Meeting 2024-05-18

Hello SIG Core,

We’ve been making some solid progress lately - lots of discussion here on the forums, and we even have a working stdenv (huge thanks to @VlinkZ!!). Given the progress we’re making, I think it’s a good point for us to call a meeting, so we can all touch base and get in sync on where we want to start heading next.

Here’s a draft outline for a possible agenda (updating as suggestions come in):

  • Member introductions
  • Take stock of current progress
    • What do we currently have in Core?
  • Core direction
    • What do we want Core to look like?
    • What should it contain?
    • How should it be used by other SIGs?
  • Moving lang infrastructure out of Core
    • How will Core use things like buildRustPackage?
  • Working with Security Committee
    • How should we address security advisories in Core?
  • Any other miscellaneous items
  • Next meeting - when? how often?

Definitely not final - please drop a comment if there’s anything else you want to discuss (or just bring it up in the meeting!).

As for potential meeting times, please drop your availability over here: SIG Core Meeting - Crab Fit (i do apologize in advance for my availability - my timezone probably does not align very well with most people here :sob:). I’ll pick out a final date on May 15, 2024, so please log your availability before then if you plan to join in.

The meeting time has been decided: 2024-05-18T13:00:00Z

Join the meeting on Jitsi: <removed, no longer using this meeting link>

Meeting notes:

Looking forward to seeing you all there!


Yeah, I know I said it somewhere else but its worth repeating, awesome job @VlinkZ you’re definitely leading the way for Aux IMO.

I’d love to get on a voice and/or video call.

It terms of short term planning though, I’m going to be traveling this next week. In particular May 16,17,18 I am likely to have no internet 95-100% of the day.

Long term My normal schedule is usually pretty flexible, so I’ll likely be able to fit in whatever times you guys pick. My timezone is CST but I’m usually up ~6:30am so we can probably find a time that overlaps with you @srxl.


I wanna add looking at Security Updates process for core to the agenda.

The dependabot just ran, and the result lists a bunch of critical and high vulnerabilities that should be remediated before starting to use core.


From what I can see a lot of those issues are coming from tests, rather then shipped packages. Its still important to fix those, but not as imperative if it breaks the packages’ tests.

1 Like

Good catch, I somehow missed that in the wall of text… might have needed some more :coffee:

Maybe we could prioritize:

  • Fix non-test first, after that test issues
  • For each category fix in critical → low order

The other topic for discussion would be to see if we can use the PR workflow to check new code before committing for know vulnerabilities.
That would cover the aspect dependabot doesnt cover.


Looks like we managed to get one block where everyone’s available, so we’ll be going with that one - We’ll hold our meeting at 2024-05-18T13:00:00Z! I’ll setup a Jitsi call closer to the day that we can all jump in on.


I have a couple points I noticed while working on Core. I will put them here and join the meeting (unless something massive happens in the next 4 hours)

  1. When a dev is iterating on Core, what is the feedback device? What do you run to know if you broke something? There’s no clear indication.
  2. Relatedly, do we want some CI to build those jobs?
  3. Maybe we want code formatting? I like Alejandra but it’s a bit opinionated so maybe nixpkgs-fmt is better nixfmt-rfc-style more relevant in SIG Doc
  4. Linters while we’re at it? I have never used a Nixlang linter
  5. Still related: is it intended to have AAAAAASomeThingsFailToEvaluate long term? Assuming Core stays relatively small it seems counterproductive
  6. Do we want to take the opportunity to improve fetchFromGitHub so it includes revs in the output name? Very opinionated

My mad little experiments in binary caching might be getting to the point where they could back something like this, but realistically none of my machines is going to survive doing proper builds. Might be just about usable all the while we’re just evaluating but not ultimately changing the derivations. Someone on matrix did tentatively volunteer a rather beefier machine!

1 Like

The steering committee have discussed formatting, etc. a little bit, and there’s been a thread on the forum. The outcome was that we should stick with nixfmt-rfc-style. The documentation special interest group (who created that thread and subsequently asked steering) are planning to write contributor guides based on this, so I’ll happily link you to them when we’ve got them.

I think we should not have this. It is such a hacky workaround its embarrassing

Any meeting notes?


There’s still 45 minutes until the meeting :stuck_out_tongue: I’ll add them to this post once the meeting is wrapped up.

Oh dang! I must’ve done my timezones completely wrong I was thinking it was yesterday at 9am for me.

Anyways great! I’ve got like a spotty 500Kbs internet right now, so i probably wont try to talk but I’ll try to listen in on the call. Recording would be appreciated if participants are willing.

Quick thing I think is important for the agenda; PR review process.

For example, it looks like I’ve got permission to just merge one of the PR’s into main. I think a soft/subjective policy is fine for PR’s but we should probably talk about what is appropriate to just merge unilaterally and what needs a reviewreview/discussion


There’s already been some discussion on this one (Reviewing and merging PR/MRs) - might be worth touching base on it again though.


I’m unfortunately not going to be at the meeting (traveling so none of the times worked :frowning: ).
But a few points for my perspective


  • Core now builds nix and lix on Linux (and Darwin once my prs are merged).
  • There are some extra packages needed for optional dependencies not needed for nix/lix. We should consider trimming them down while maintaining successful builds for nix/lix
  • build-support and common-updaters have a lot of extra not needed by core right now, they should be trimmed down.
  • Language packages like perl, haskell, and python have only necessary packages uncommented, the rest are commented right now to preserve structure but should be removed.


  • what should be done with lib? Should it stay in core or be split?
  • how should we deal with language packages required by core? (Python, Haskell, perl, etc)
    • language packages should be in SIG repos, but what if core depends on them? I’m thinking have a minimal set of packages in core, and then the rest of the packages in a SIG repo. But that does end up splitting maintainers between core and SIG repo.
  • how do we want to implement testing?
  • how will we track maintainers? (Link with community through flake? Or have individual maintainer lists per sig?)

My opinions

  • I think it would be nice to split lib from core, but only if we have a good way of having the tests not cause a circular dependency. I haven’t seen a format I’ve particularly liked yet, but open to either way.
  • Core should contain necessary packages for building nix/lix. I’m unsure whether we should extend that to everything needed to build a minimal ISO. In order to decide we also need to make a plan on where to store NixOS modules. Since modules depend on core, if we have them in a separate repo, should that repo contain packages needed to build minimal ISO, or should core?
  • For meeting schedule, once every two weeks, or even every week for now would work fine with me. Hopefully I can make the next one :pray:

Meeting concluded - thanks to everyone who came along! A copy of the meeting notes are available here: