# Meeting Minutes - First NixOS Plumbers Summit - Berlin - 2025-09-29 [TOC] ## Attendees - @arianvp - @edef - @frederictobiasc - @ma27 - @mschwaig - @nikstur - @raitobezarius - @willibutz ## Topics to take to ASG - exec with PATH lookup (execvpe) ## Topics discussed at the summit ### Declarative Installer * default `systemd.repart.partitions` to `image.repart.partitions` * fully declarative installer: nixos-install using `systemd-repart` * we think this is a good idea * not going to be a disko replacement, just an alternative ### Maintainability in Nixpkgs (Circular Dependencies) * Currently we enable LVM to get a single udev rule to make verity/cryptsetup to work: * split up LVM package into LVM and device mapper * we think this is a good idea * Many of our circular deps are circular "runtime deps". * How do we avoid that? usually /run/current-system * Doesn't work in initrd * Doesn't work for very early things * https://github.com/pyproject-nix/uv2nix/blob/de6273a5d3189fcc4ec2ae7270d9ed922a155439/doc/src/patterns/meta.md uv2nix delays runtime dependencies to the end and builds a "venv" * investigate usability of a venv for every binary, @arianvp wants to look into this * Overrides for packages to break dependency cycles are hard to discover * Suggested improvement: create a single overlay file per "set of strongly connected components" that shows how the packages are combined together and bootstrapped. e.g. for systemd * Broken kbd dependency cycle for systemd * kbd.vlock depends on pam, depends on system * systemdMinimal depends on kbd * We build kbd without vlock, then systemdMinimal, then the full kbd, then the full systemd * No one uses kbd.vlock * We should create a separate kbdVlock package that builds kbd.vlock * PR: https://github.com/NixOS/nixpkgs/pull/447207 * We need better tooling to detect unnecessary cycles and prohibit them from re-entering Nixpkgs * We should set outputChecks.maxOutputSize for our corePackages * We NEED it but we don't yet know what it would look like * One last remark: Enable alerting and monitoring on certain well-defined closures * Build/run tests in a separate derivation for all packages * We NEED to do it * (let's do it later and not block on the first thing): On top of tests in different derivations, test and other kinds of verification derivations can assert ahead of time that if they produce something, it will have the same hash as one of their inputs. That way you can start to speculatively start building things that are downstream of them, or disable building them altogether depending on your workflow. * clean up the introduction of minimal util-linux where it is not strictly necessary * If possible, minimal/unusual variants of stock software should not be used by default (-> only when necessary for e.g. bootstrapping) * systemdLibs is a notable exception * python3Minimal was an example. Started to depend on it to break circular dependencies. But it broke the application itself. * Don't pursue execessive ligthness over funcionality * Action item: Contact nixpkgs core team to set guidelines for this * Evolving Nixpkgs is hard because it's difficult to kill old things * We need to learn the art of deprecating things * Old things were so easy to customize upstream for unusual use cases * Replicating these obscure features in the new variants is not desirable * Now we're stuck with both versions forever * https://xkcd.com/1172/ ### Bashless (part of the interpreter-less efforts) :::info The interpreter-less efforts are making it possible to build on top of a minimal NixOS system that does not require any interpreters. This will never keep anyone from adding interpreters, it just makes them optional. ::: * Bashless activation: * Tracking issue: https://github.com/NixOS/nixpkgs/issues/428908 * Bascially done, only profile left * Remove activation scripts * We all agree that we need to get rid of activation scripts * deprecate/remove the public API for activation scripts first, keep the internal activation scripts around * Warnings on using activationScripts * Userborn is ready * /etc overlay needs a migration path * Add to manual how to migrate away from activationScripts * Already available in Userborn: https://github.com/nikstur/userborn?tab=readme-ov-file#replacing-systemactivationscripts * Extract activation scripts functionality out of tree to give users a possibility to migrate * Same we can do for `ec2-data.nix` ### Image Building * Making repart work with @phaer's `images` interface so that you can do `nixos-rebuild --build-image` works. * Rename the option to `system.build.image`. * Problem: Many people are using finalImage already * https://github.com/NixOS/nixpkgs/pull/437117 * Let's investigate whether and how we can do this, should be quite possible * Stop images from being cached whenever we try to test something in Hydra * Pushing to the cache is currently necessary for Hydra to function * Pushing is not expensive, keeping it around is -> We could expire images time-based so that it's quickly removed from the cache * We need tools to stop things from being cached * Touching Hydra is very difficult and not necessarily super feasible * Should we do preferLocalBuild for all the images? Maybe, but needs evaluation * Include the repart modules in module-list.nix * Yes we all agree * This will break all the other image profiles * We probably need to make this interoperable with @phaer's work or find an alternative approach * Should we put the repart tests into the hydra jobset? ### VMs / NixOS tests * `virtualisation.diskImage` * currently we do this weird dance to run test VMs with repart images: https://github.com/NixOS/nixpkgs/blob/6cf07e0f638ce09fe8ef918cb644fe18ac5b566c/nixos/tests/appliance-repart-image.nix#L104-L119 * @arianvp's proposal: https://github.com/NixOS/nixpkgs/pull/441851 * currently wouldn't support changing disk at runtime * is an improvement over status quo * alternative proposal: solve this in the test instrumentation -> we can do this later * `virtualisation.credentials` * @arianvp wants PR reviewed :) * https://github.com/NixOS/nixpkgs/pull/435886 * Declarative provisining of the TPM in qemu-vm: `swtpm_setup` in NixOS Test Driver (EK/EC) * OK sounds good idea. do it * qemu.OVMF in NixOS test driver * We have a weird custom build in qemu-vm that is unnecessary * Some features do not work in the default OVMF build * We want SecureBoot and TPM to work in all test circumstances * OMVFFull doesn't work one some systems * Kill OVMF build in qemu-vm always use OVMFFull: We all agree * Do not use OVMF from qemu, use the one we built from the sources * Separate concerns in qemu-vm (multiple modules) * We want separate modules that configure: * Host * VMM * Guest * Test Instrumentation * Networking? * The test driver currently has a weird way to decide between headless and interactive. And this messes with console output for headless tests. This for example hides systemd emergency messages. * This fixed our issue: https://github.com/NixOS/nixpkgs/commit/ea9b0daeee2e14fce2578bc00115ac9f513e3473 ### snix * Update: * Snix has a builder now * kernel builds * firefox builds * Standardized interface on "What is a buildsandbox" * fuchsia blobstore (https://fuchsia.dev/fuchsia-src/concepts/filesystems/blobfs) * expose hashes as abstract pointers without being able to inspect the bytes * People are running caches on top. but scaling issues * snix-castore creates queue problems upstream * nginx fault. not well-configured * How do we get snix "smart client" in nix * Snix needs to standardise the directory format * nar-bridge runs on the server-side; you talk over NAR * move nar-bridge to the client. * nix-cache-info can be extended with an "Upgrade: " field * @arianvp and @edef : See if we can add new fields to cache.nixos.org/nix-cache-info * @raitobezarius and @edef: https://git.lix.systems/lix-project/lix/issues/662#issuecomment-14801 * How do we get to a place where we can efficiently netboot a system from cache.nixos.org? * We want castore to be a linux filesystem * Garbage Collection * being actively worked on * DGNum people are interested in this as well * OIDC for per-user authentication of cache * being actively worked on * If you are trusted user this is solved * Can be solved the same way cachix solved it * Lix could eventually end up supporting this on the daemon level ### Organisation * NixOS corepkgs team and codeowners * Suggested Team members: * @arianvp * @nikstur * @ElvishJerrico * @LordGrimmauld * Who else? * Not to be confused with the nixpkgs core team * Issue: * Currently no ownership of core components * Difficult to push back on changes for individuals that own the core set of packages * Many core packages are not maintained * Scope: * Not `environment.corePackages` (lol) * Not kernel * Not stdenv (libc, compilers etc. still handled by stdenv team) * Systemd and its dependencies * Changes nothing about best effort maintenance (done mostly in free time) * We should add CPEs to our packages * https://pad.lassul.us/PWbgxhB7T6y3HRzUDzIjFQ ### Provenance * pURL PR: https://github.com/NixOS/nixpkgs/pull/421125 * Do we care about it? * We can do it, but no one really cares about it (preferring CPEs instead) * persisting this kind of information as part of the output seems like a bad idea * CPEs could be initialized in a kind of automated way? * laut signature format: https://github.com/mschwaig/laut/blob/a6bdcccfcce6e267d49a6e3355ded4e580d61274/src/laut/signing.py#L111 * how to solve frankenstores * remove self-references (lol) * The reify runtime dependencies late stuff solves this! * No more monoidal properties. * content-aware rewrites * Mach-O: content hash embedded in header. when nix does content rewrites it breaks that content hash * repair and check is broken on MacOS * need to understand the Mach-O format zb package manager nix * https://www.zombiezen.com/blog/2024/09/zb-early-stage-build-system/ * Sigstore / temporary keys * Substitution forms a monoidal category * rewrites are a functor. * Things might happen in Lix at some point maybe * This should think of switching to a new cipher suite in the future (a minimum of crypto agility) ### Documentation * We should re-plumb Nixpkgs documentation * Store release notes in a separate file for each note * two changelogs is worse than one. * Rewrite using standard tool like mkdocs, or mdBook? * We should keep nixos-render-doc around because pandoc is not optimal (ghc)