nix: vms for testing ghostty

[jcollie]

Adds a Nix VM configuration to run Gnome/Wayland. The primary purpose will be testing Ghostty in a "clean" environment. I'm going to continue to experiment with running this in CI to see if we can do some basic testing of GTK since it's difficult to unit test that code.

To use, run nix run .#wayland-gnome in the Ghostty source directory. I have no idea if this works on macOS. There's probably a lot of extra stuff that can be trimmed to slim it down.

Whatever directory you run this from will be mounted at /tmp/shared in the VM. The ghostty user runs as uid/gid 1000/1000 so that may affect your ability to read/write that directory if your host system user runs as a different uid/gid.

If this is something that we'd like to keep, we should add VM definitions for KDE Plasma and maybe one tiling window manager.

Screencast.From.2025-01-04.22-19-31.mp4

[curtbushko]

Works on my NixOS desktop (of course)

On mac I get:

… while evaluating the option `virtualisation.vmVariant.services.gnome.gnome-keyring.enable':

… while evaluating definitions from `/nix/store/ckrr972nfzf68qcjis629brvmx1qxs6d-source/nixos/modules/programs/geary.nix':

… while evaluating the option `virtualisation.vmVariant.programs.geary.enable':

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)
error: Package ‘geary-46.0’ in /nix/store/ckrr972nfzf68qcjis629brvmx1qxs6d-source/pkgs/by-name/ge/geary/package.nix:152 is not available on the requested hostPlatform:
         hostPlatform.config = "aarch64-apple-darwin"
         package.meta.platforms = [
           "aarch64-linux"
           "armv5tel-linux"
           "armv6l-linux"
           "armv7a-linux"
           "armv7l-linux"
           "i686-linux"
           "loongarch64-linux"
           "m68k-linux"
           "microblaze-linux"
           "microblazeel-linux"
           "mips-linux"
           "mips64-linux"
           "mips64el-linux"
           "mipsel-linux"
           "powerpc64-linux"
           "powerpc64le-linux"
           "riscv32-linux"
           "riscv64-linux"
           "s390-linux"
           "s390x-linux"
           "x86_64-linux"
         ]
         package.meta.badPlatforms = [ ]
       , refusing to evaluate.

       a) To temporarily allow packages that are unsupported for this system, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

          Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
                then pass `--impure` in order to allow use of environment variables.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnsupportedSystem = true; }
       in configuration.nix to override this.

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnsupportedSystem = true; }
       to ~/.config/nixpkgs/config.nix.

[curtbushko]

I was looking at build-and-run-vms to see if turning on the linux builder helps.

I still get:

error:
       … while calling the 'getAttr' builtin
         at <nix/derivation-internal.nix>:44:19:
           43|       value = commonAttrs // {
           44|         outPath = builtins.getAttr outputName strict;
             |                   ^
           45|         drvPath = strict.drvPath;

       … while calling the 'derivationStrict' builtin
         at <nix/derivation-internal.nix>:34:12:
           33|
           34|   strict = derivationStrict drvAttrs;
             |            ^
           35|

       … while evaluating the option `virtualisation.vmVariant.system.build.toplevel':

       … while evaluating definitions from `/nix/store/ckrr972nfzf68qcjis629brvmx1qxs6d-source/nixos/modules/system/activation/top-level.nix':

       … while evaluating the option `virtualisation.vmVariant.assertions':

       … while evaluating definitions from `/nix/store/ckrr972nfzf68qcjis629brvmx1qxs6d-source/nixos/modules/system/boot/kernel.nix':

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: assertion '(stdenv).hostPlatform.isLinux' failed
       at /nix/store/ckrr972nfzf68qcjis629brvmx1qxs6d-source/pkgs/os-specific/linux/kernel/generic.nix:87:1:
           86|
           87| assert stdenv.hostPlatform.isLinux;
             | ^
           88|

[jcollie]

I was looking at build-and-run-vms to see if turning on the linux builder helps.

I still get:

After reading a couple blog posts, I just pushed a patch that maybe fixes this (at least until we find the next roadblock) as this command to manually build is working on my Linux system with aarch64 cross-compilation turned on. Not sure if it finishes yet because cross-compilation is very slow.

nix build -L .#nixosConfigurations.wayland-gnome-aarch64-darwin.config.system.build.vm

[gigamonster256]

output of latest commit on M1 macbook pro

> nix run .#wayland-gnome
error: a 'aarch64-linux' with features {} is required to build '/nix/store/pbpm1nf1lfwk2kp1qchn90i16fz9hgb0-NetworkManager.conf.drv', but I am a 'aarch64-darwin' with features {apple-virt, benchmark, big-parallel, ca-derivations, nixos-test}

Edit: with nix.linux-builder.enable = true; in my nix-darwin config, the linux derivations are building using the 'remote' builder but quite slowly, however I believe making sure linux CI runs before macOS, the derivations should be able to be cached. We'll see if the VM works correctly once everything finishes building.

[jcollie]

Edit: with nix.linux-builder.enable = true; in my nix-darwin config, the linux derivations are building using the 'remote' builder but quite slowly, however I believe making sure linux CI runs before macOS, the derivations should be able to be cached. We'll see if the VM works correctly once everything finishes building.

Aha, I was just about to ask about that. The CI runs would probably not be run on macOS as they are slower (and more expensive) than Linux CI runs. Not even sure yet if these will even be run automatically for Linux.

[gigamonster256]

It took about 20 minutes to get from qemu launching to the desktop environment with qemu maxing out a single core the entire time (getting to the login prompt and actually using the DE works fine, just getting to it takes forever)

[jcollie]

It took about 20 minutes to get from qemu launching to the desktop environment with qemu maxing out a single core the entire time (getting to the login prompt and actually using the DE works fine, just getting to it takes forever)

Nice! I did find this blog post that has some tips on giving the builder some more resources, that might help.

https://nixcademy.com/posts/macos-linux-builder/

[curtbushko]

The above works for me also and I get a VM image to run.

It took quite a while to build on my M1 but that's ok I guess.

[jcollie]

The above works for me also and I get a VM image to run.

It took quite a while to build on my M1 but that's ok I guess.

Yeah, it's not exactly a speed demon on Linux either.

[curtbushko]

Maybe the plan can to be:

1. here, take this VM and reproduce your problem
2. provide a script that creates the config/setup and reproduces it
3. ??
4. profit!

[jcollie]

Maybe the plan can to be:

1. here, take this VM and reproduce your problem
2. provide a script that creates the config/setup and reproduces it
3. ??
4. profit!

Yeah, basically I wanted VMs like this so I can easily run Ghostty in environments that are dissimilar from mine to test how
GTK interacts there. All the machines that I have regular access to use basically the same Nix config.

[jcollie]

Added Cinnamon and Plasma 6 in both Wayland and X11 variants.

[anund]

If I'm testing a vm with a few more customized options can I just define the vm snippet and pass it to nix run rather than editing the vm definitions directly?

[jcollie]

If I'm testing a vm with a few more customized options can I just define the vm snippet and pass it to nix run rather than editing the vm definitions directly?

I just added a couple of patches that should let you do this (untested):

{
   inputs = {
    nixpkgs = {...};
     ghostty = { ...};
  };
  outputs = { nixpkgs, ghostty }: {
    nixosConfigurations."x86-64-linux".my-vm = ghostty.create-gnome-vm {
      nixpkgs = nixpkgs;
      system = "x86_64-linux";
      overlay = ghostty.overlays.releasefast;
      path = ./my-vm.nix;
      uid = <myuid>;
      gid = <mygid>;
  };
};

[jcollie]

Also, let me know if there are things that should be in the base image. I can see a case for zsh and fish since those are very popular shells that people use, but probably not something like starfish or oh-my-posh.

[jcollie]

Home-manager probably isn't a candidate either, even though it's very popular I don't think that it's necessary for testing Ghostty.

[anund]

Tension between maintenance and use 😄. I'm coming at using nix vm's with a different time frame in mind. Instead of a blessed (read maintained) set of vms that are correct for months/years, I'm interested in tool to collaborate over briefly and than mostly throw away.
In that context the vm setup config is and source inputs add extra noise around hunting for the currently conflicting set of system configuration values. Those values would need to be wide open so my question about reuse for the cli above.

Separate point: flake example requires work beyond typo correction. It'll take me a while to figure out how to properly run it. I'm less familiar with flakes. pebcak: setting nixpkgs to 22.11 generates interesting 'thing not found' errors.

[mitchellh]

I think plenty of logic could be extracted into separate nix/vm/*.nix helper files (i.e. runVM) and I think we could organize it slightly differently but overall this is very good work and I'm happy to merge it.

I'm not sure if you're aware of a way to at least update the CI to validate all the configs are valid. Running them would be too expensive, but validating they build would be excellent if we could.