From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 6EB71D607; Fri, 03 Jul 2026 14:02:57 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 445D6D59B; Fri, 03 Jul 2026 14:02:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fout-b6-smtp.messagingengine.com (fout-b6-smtp.messagingengine.com [202.12.124.149]) by atuin.qyliss.net (Postfix) with ESMTPS id BD250D59A for ; Fri, 03 Jul 2026 14:02:51 +0000 (UTC) Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id 84D5F1D0007F; Fri, 3 Jul 2026 10:02:49 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Fri, 03 Jul 2026 10:02:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1783087369; x=1783173769; bh=PiqjMuXl71 TBKu7u5uPy8ES2Jk1+aYuxUaGZKXnPIo8=; b=IC8Zs5fFG6Vo+wzJBlYDCCQ7Ca OqUKgPtXmJqHgdGRNCMet53NOch2xxWXvM0oA5Wv+1dsojnSPddogs6wUNZn3hH6 PK8bEDqurWFVEjGNpUXBRpUGM71M6yKOq/CIRkyFcz/Z9Y9BOeF/6Nv/78GJsi7X IYUq/ZRPl1zsNU6PJwOXdZZki+zqC1WCXlgTswX6JyB3I3QmL1m1h96ybi825H5H /rg1kErFy8IcGXviNjYR2Tw6ZEF+WctVoZXQfhuMrfm3caM6A+yuu+lRO7jtg4eD hCVf6soNXCOXKO2BFPVZM5MJp4rQviPNSajqBtt7Nr1o8es6+q2IR5babaIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1783087369; x=1783173769; bh=PiqjMuXl71TBKu7u5uPy8ES2Jk1+aYuxUaG ZKXnPIo8=; b=knpn4JUzUuYMJjWQzd88M/PMsm/zQMthgTtp8LjLUHpJTwe2hFT MiKBMG3EhgdJ6INgptGuR4LySPeHDBJfH6RKprgXTdeK0OfCj23WK8jv481dWwEf XcJ6FMQf3VU/e7YYMVSWOHuUiS4+hrxuIVgjdoWUmBOszZ3uZurR3sEmGKJw5r1c /mubL95FEGDyY/rKEk4LxrHNAKi5dFeDKej8QXUftz3+Xd/JIMHGT4s+Bamb/Jjp r7ooypgahGDIXkSOC0HsJckCx+4q+Xvdqo5qlsEjL0BIWsN6fBWDhGc4f2PDbbNZ 85u5na2FboFQRDUwDylvJ/EZTVuZTxjrXfQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEORNQv236ZH8ep/k3sXjH3d1lxyuVzCX4gPg6dOxWbBBu51ED9m5dj/NqN5O18dn Mx1aUqeZNq25SeVH0QSBp7fjwZ2k/x1IaEVKOcbzqdxrqWdW1Hv1yHAbALVdZl2ESDp27I jwnLMDRnnDKxXDZnWXcO1wnTCNGoKUtlJ8T6fr3nWhUhz4+8BT4vtw4MFnYUnuHCEL7gUq rBm44PC7cM5YvjjnjuvCz0OV6PzXNwEmVAbm6heSgQcx5HGIY1zVeDyCOqRWW5h/hxUinD a+p5glkcGyM7hAHgGTUyyGK/eddTCABdXJ9CFsXEV7T6acOYRFJa15/zaP4bOAyAf9XiZC oxP/reNDAjz1iuYojNjwp8MQQ0K+pziS5eqd0OK58FGQL1wCSmWGb/B5ZPvztFjUc/mPOP +c4xJZh7iqvRos8lAciXpz1LhugC1CZBKVD/QJrblxQ0h7eqoFTG8Ex0SQjHcqKctBMQ4p GfzKxfCQHNbJFV7ch9PlxibReeEIIuWSfZiUu4elT5WgvVQ1+Xf42ml26Z/COOsHfH08cN Y6odLHO36T4uLoFCDwEmXLmJS69tT98A7lN4moZziYhTWa6zISxp2B1pFNA273GJnctVRp OPLK3iCV1ATq6+G94bCYTQTLoU9Wu+dowcWUHgYMIW8WG10tpeEmZyeXUl/w X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 3 Jul 2026 10:02:48 -0400 (EDT) Received: by mbp.qyliss.net (Postfix, from userid 1000) id 04B0D846328B; Fri, 03 Jul 2026 16:02:46 +0200 (CEST) From: Alyssa Ross To: colby@colbyt.com Subject: Re: [PATCH 8/8] vm-lib: allow app VMs to name closure roots In-Reply-To: References: <20260626185509.3715326-1-colby@colbyt.com> <20260626185509.3715326-9-colby@colbyt.com> <87echlwlyt.fsf@alyssa.is> Date: Fri, 03 Jul 2026 16:02:44 +0200 Message-ID: <87zf08kw6z.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: OBQ726Z3C3R3RZXIHPACDQ27ZLQCNYRC X-Message-ID-Hash: OBQ726Z3C3R3RZXIHPACDQ27ZLQCNYRC X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.10 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable colby@colbyt.com writes: > =E2=80=9CMiss files=E2=80=9D 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 arbitra= ry subpaths. In that case the graph root should be the package output path = (`/nix/store/...-firefox-...`) while `fs/run` should still point at the exe= cutable. 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 =E2=80=9Cwhat should be exec= uted=E2=80=9D from =E2=80=9Cwhich store path(s) should seed the image closu= re.=E2=80=9D For the current app VMs, > `run =3D lib.getExe firefox` / `lib.getExe foot`, while `runClosure =3D= [ 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 fa= ilures I saw, especially the Python bootstrap `usr/` output shape, GnuTLS p= robing `/usr/bin/socat`, the mypy test observing the unsandboxed build root= , and the libfyaml `.pc` `none required` tokens, are better treated as Nixp= kgs issues or temporary overlay workarounds for this pin. > > I=E2=80=99ll 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 =E2=80=94 maximum benefit for all users of the upstream pro= ject, 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 wrote: > >> colbyt writes: >>=20 >> > 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 VM= s. >> > >> > Signed-off-by: colbyt >>=20 >> 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). >>=20 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRV/neXydHjZma5XLJbRZGEIw/wogUCakfBBAAKCRBbRZGEIw/w othKAQCgCvUAKNbSKPQ+Lt4fiR/boou6UOQZNYHVqfMAaY037AD/T2k7VsMGBOUD 2K3s7UqTmIH6a4pUMJGcBKIlW6WzEAA= =gikm -----END PGP SIGNATURE----- --=-=-=--