Okay, 796 might be a bit much with what we’ve already merged so far. I’ll split off the larger rebuilds into a staging PR after the nixpkgs-review finishes.

✅ for golem. @GaetanLepage thanks for verifying 🙏

✅ for vfkit builds and runs as expected on aarch64-darwin:

$ ./result/bin/vfkit -h
A hypervisor written in Go using Apple's virtualization framework to run linux virtual machines.
                Complete documentation is available at https://github.com/crc-org/vfkit

Usage:
  vfkit [flags]

Flags:
  -b, --bootloader strings      bootloader configuration (default [])
  -c, --cpus uint               number of virtual CPUs (default 1)
  -d, --device stringArray      devices
      --gui                     display the contents of the virtual machine onto a graphical user interface
  -h, --help                    help for vfkit
  -i, --initrd string           path to the virtual machine initrd
  -k, --kernel string           path to the virtual machine linux kernel
  -C, --kernel-cmdline string   linux kernel command line
      --log-level string        set log level
  -m, --memory uint             virtual machine RAM size in mibibytes (default 512)
      --restful-uri string      URI address for RestFul services (default "none://")
  -t, --timesync string         sync guest time when host wakes up from sleep
  -v, --version                 version for vfkit

Also confirmed working with podman (which uses vfkit):

$ ./result/bin/podman machine start
Starting machine "podman-machine-default"

This machine is currently configured in rootless mode. If your containers
require root permissions (e.g. ports < 1024), or if you run into compatibility
issues with non-podman clients, you can switch using the following command:

        podman machine set --rootful

API forwarding listening on: /var/folders/r0/k849jt6s5ss4222ll7t21vc40000gn/T/podman/podman-machine-default-api.sock
You can still connect Docker API clients by setting DOCKER_HOST using the
following command in your terminal session:

        export DOCKER_HOST='unix:///var/folders/r0/k849jt6s5ss4222ll7t21vc40000gn/T/podman/podman-machine-default-api.sock'

Machine "podman-machine-default" started successfully
$ ./result/bin/podman machine list
NAME                     VM TYPE     CREATED       LAST UP            CPUS        MEMORY      DISK SIZE
podman-machine-default*  applehv     5 months ago  Currently running  8           2GiB        100GiB

@emilazy We good with rebuild count here to merge?

Nah I need to split out some of this to a staging PR and also let nixpkgs-review finish off a few remaining builds that will surely fail. Soon™

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 370693

x86_64-darwin

aarch64-darwin

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 370693

x86_64-darwin

aarch64-darwin

I’m not sure why you ran nixpkgs-review on this PR twice when I already commented here that I’ve been trying to nixpkgs-review these PRs myself so I can check for regressions and look at the logs to fix any that arise but it’s been impossible to get any builds through on the community builder because the CPUs have been overloaded by builds you’re running for days.

Please don’t use the community builders as a replacement ofborg to nixpkgs-review PRs en masse, they really don’t have the resources for it. The parallel jobs at least really must go down for anyone else to be able to use them for anything. We just had to reboot the builder because it was almost non‐responsive and I couldn’t test #371149 to unblock a staging-next-24.11 cycle that’s due to merge today.

Anyway I’ll get back to these PRs once that’s done.

I’m not sure why you ran nixpkgs-review on this PR twice when I already commented here that I’ve been trying to nixpkgs-review these PRs myself so I can check for regressions and look at the logs to fix any that arise but it’s been impossible to get any builds through on the community builder because the CPUs have been overloaded by builds you’re running for days.

Please don’t use the community builders as a replacement ofborg to nixpkgs-review PRs en masse, they really don’t have the resources for it. The parallel jobs at least really must go down for anyone else to be able to use them for anything. We just had to reboot the builder because it was almost non‐responsive and I couldn’t test #371149 to unblock a staging-next-24.11 cycle that’s due to merge today.

Anyway I’ll get back to these PRs once that’s done.

You are right. Sorry... Even lowering --max-jobs it was not good.
I won't do that again.

Managed to finally get a review through. Looks like no regressions with the sandbox off. I had to skip the .NET packages as they really didn’t want to build for whatever reason, but as they’re just downstream from Swift it should be fine. (Really this probably only needed packages that were directly touched building; I should implement the --depth option I’ve been wanting in nixpkgs-review since forever…)

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 370693

x86_64-darwin