Attendees: @tomberek @roberth @fricklerhandwerk @Ericson2314 @proofconstruction
Notes: @fricklerhandwerk
Triage
-
flakes: input is updated on upgrade if repo owner capitalization is changed · Issue #10726 · NixOS/nix · GitHub
- can be considered a bug, but not a critical one
-
{extra-,}experimental-features in flake nixConfig ignored · Issue #10727 · NixOS/nix · GitHub
- this has deeper underlying architectural issues
- but attendees don’t agree whether configuration via flakes is a worthwhile feature to begin with
-
builtins.fetchGit fails with .gitmodules entries that aren't submodules · Issue #10739 · NixOS/nix · GitHub
- @Ericson and @roberth aware of the issue, will discuss in the thread
-
Recursion in `builders` definitions deadlocks builds with `waiting for lock on '/nix/store/...'` · Issue #10740 · NixOS/nix · GitHub
- in principle a well-known issue, ideally to be solved with cycle detection in remote builds
- not clear if fixing it would be worth the effort in the grand scheme of things (but anyone is invited to)
-
nixos.org is out of date wrt latest Nix release · Issue #10743 · NixOS/nix · GitHub
- time to set up redirects
- Require `drvPath` attribute to end with `.drv` by Ericson2314 · Pull Request #10757 · NixOS/nix · GitHub
-
run nix in a non root container in openshift - restricted SCC · Issue #10747 · NixOS/nix · GitHub
- @ericson2314 will look into it
Discussion
- @fricklerhandwerk: would like to re-iterate the last report’s proposal to pick one large issue (testing, layering, meson, …?) and finish it
-
@roberth: meta note on these meetings, we probably should double down on specialising
- @fricklerhandwerk: agreed, please let’s take the proposal from a couple of weeks ago seriously and onboard more maintainers to share load in each of our areas of expertise
-
@roberth: should more clearly delineate interests, @fricklerhandwerk e.g. seems not very interested in pursuing fetcher
- @fricklerhandwerk: not necessarily not interested, just not convinced it’s the right long-term path to take. I’d like to get convinced otherwise, but hard to get substantiated answers
- @roberth: I wish we could go back in time around 2018 where dependency management was a hot topic, and where it wasn’t clear at all how to do all of that
- @fricklerhandwerk: yes, then we could parallelise better and use these meetings to discuss changes that concern common issues such as architecture or general strategy
- @tomberek: willing to have that discussion. if we can’t clearly separate via APIs, any attempt at non-trivial solutions becomes much harder. make the layers explicit and clear (rather than a wish or hope) and e.g. finish RFC134 in code and documentation and set up hard boundaries
- @fricklerhandwerk: don’t have to wait for the hard boundary, would be enough to have people to work towards that together
-
@ericson2314: big issues would be testing, removing global variables, the configuration system
- for the config, it may even be easier to do a huge breaking change and then building backwards compatibility
- meson would be a good place to start though
-
@fricklerhandwerk: proposal: focus on porting the build setup to meson until it’s done
- @tomberek and @ericson2314 can drop in for pairing, scheduled a meeting Friday next week (anyone is invited to join though)
- only a couple of hours per week available, but can stick to it as long as it takes, as long as there’s a feedback cycle