cross-domain virtio-gpu seems to be broken on 129. I'll work on a fix
for that and then upgrade further, but in the meantime it's nice to
have 128, which fixes interoperability with virtiofsd.
The musl test fails on x86_64 at the moment because mesa doesn't build
for x86_64-unknown-linux-musl from x86_64-unknown-linux-gnu, but I've
checked that crosvm builds for musl on x86_64 with a native build.
This would have caught the build regression introduced by
74cbe399ba ("crosvm: 124.0 -> 125.0") and fixed by
d213fa697f ("pkgsMusl.crosvm: fix build").
The version of crosvm we have packaged only passes its tests with 4K
pages.
The whole patch doesn't apply, but that's okay, because we don't run
most of the affected tests.
I'm aware of a nasty bug in this crosvm version[1], which didn't
affect me on earlier versions (although from the code it looks like
the bug was already present). But it only affects vhost-user-gpu,
which is probably a fairly obscure feature, so I guess it shouldn't
hold us back?
[1]: https://groups.google.com/a/chromium.org/g/crosvm-dev/c/v_7Gie37NCI
crosvm now includes a Cargo.lock again, so we don't need to vendor it
into Nixpkgs.
Its build system now compiles the seccomp policies into the binary, so
we don't need to build and install those ourselves any more.
Despite having moved the main repo to crosvm/crosvm, release branches
are still only being created on chromiumos/platform/crosvm. So we
should have crosvm/crosvm as the homepage, but fetch from
chromiumos/platform/crosvm.
Link: https://github.com/NixOS/nixpkgs/pull/193746
This was important when building crosvm required assembling our own
build tree from lots of different repositories, but now that they've
moved to submodules, it's overly complicated and needlessly
inconsistent with the rest of Nixpkgs.
These are no longer by default as they have been extracted into their
own crate, so this code wasn't doing anything. If we did want to run
the integration tests again, we'd have to download kernel and rootfs
binaries from Google, and that's more trouble than it's worth.
manifest-versions never seems to contain the release build any more,
so we can't use it to find the version of crosvm being served to CrOS
devices.
Instead, I've changed the update script to take the latest version of
the appropriate crosvm Chrome OS release branch. This is the branch
that gets served. Every release, it is branched off from the
"chromeos" branch (which is the one that passes Chrome OS QA), and
then collects any critical fixes over the lifetime of the release.
With this change, I've introduced a new, simplified versioning
scheme, e.g. 100.0. The tip build is always 1:1 with the Chrome
version, so having both of those is redundant. The other number is
the number of commits that have been added to the release branch after
branching from the chromeos branch, so that the number will go up if
we update to include a new commit from the same release.
The old dashboard no longer exists. Currently, the platform version
being served doesn't exist in manifest versions, but that was also a
problem we had before sometimes.
Otherwise, we might only match a prefix of the version. (Although
it's not likely to be a problem in practice — I doubt we'll end up in
a situation where there's a buildspec number 10x the one we're looking
for.)
