Re: [PATCH 8/8] vm-lib: allow app VMs to name closure roots

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 3079 bytes --]

colby@colbyt.com writes:

> “Miss files” was imprecise.
>
>   The issue I hit was not a store path depending on something outside its closure. It was that `run` can be an executable subpath from `lib.getExe`, e.g.
>
>     /nix/store/...-firefox-.../bin/firefox
>
> and `writeClosure`/`exportReferencesGraph` wants store paths, not arbitrary subpaths. In that case the graph root should be the package output path (`/nix/store/...-firefox-...`) while `fs/run` should still point at the executable.

My understanding is that writeClosure and exportReferencesGraph are
supposed to be fine with being given subpaths of store paths, and will
just treat it as if they were given the root of the store path.  A
couple of years ago this stopped working, but it was treated as a bug
and my PR restoring the previous behaviour was accepted:

https://github.com/NixOS/nix/pull/10549

You're not using a very old version of Nix that doesn't have that fix,
are you?

> So the intent of `runClosure` is to decouple “what should be executed” from “which store path(s) should seed the image closure.” For the current app VMs,
>   `run = lib.getExe firefox` / `lib.getExe foot`, while `runClosure = [ firefox ]` keeps the closure root as a store output.
>
> The current patches were pragmatic unblockers for the Asahi/nix-portable build environment where I was running with `--option sandbox false`. The failures I saw, especially the Python bootstrap `usr/` output shape, GnuTLS probing `/usr/bin/socat`, the mypy test observing the unsandboxed build root, and the libfyaml `.pc` `none required` tokens, are better treated as Nixpkgs issues or temporary overlay workarounds for this pin.
>
>   I’ll try to split them mentally that way:
>   - keep only the Spectrum-specific build/runtime changes in the Spectrum series;
>   - either upstream the package fixes to Nixpkgs or carry them as clearly marked temporary pin workarounds;
>
> I'll also try to get the builder onto sandboxed builds so I stop finding the uncommon unsandboxed-only failures first.
>
> Thanks for your patience.

That sounds right to me.  We try to make sure changes are upstreamed as
far as possible — maximum benefit for all users of the upstream project,
and shares maintenance beyond just Spectrum's limited capacity.

Thanks again for all your enthusiasm and effort!

>
> On Thursday, July 2nd, 2026 at 7:27 AM, Alyssa Ross <hi@alyssa.is> wrote:
>
>> colbyt <colby@colbyt.com> writes:
>> 
>> > make-vm copies the closure of the run path into the image.
>> >
>> > For app VMs that use lib.getExe, that can miss files from the package
>> > output that owns the executable. Allow callers to pass explicit closure
>> > roots, and use the package derivations for the foot and Firefox app VMs.
>> >
>> > Signed-off-by: colbyt <colby@colbyt.com>
>> 
>> Can you give an example of something it misses?  If a store path depends
>> on paths not in its closure, that's likely a packaging bug (outside of
>> specific exceptions like /run/opengl-driver).
>> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]