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.)
crosvm now uses submodules for all of its dependencies to ease
out-of-tree builds, so we no longer need to try to reconstruct a
partial Chromium OS source tree ourselves. Yay!
But, it no longer comes with a Cargo.lock, so we have to bundle that.
Rust 1.50.0 incorporated a Cargo change (rust-lang/cargo#8937) in
which cargo vendor erroneously changed permissions of vendored
crates. This was fixed in Rust
1.51.0 (rust-lang/cargo#9131). Unfortunately, this means that all
cargoSha256/cargoHashes produced during the Rust 1.50.0 cycle are
potentially broken.
This change updates cargoSha256/cargoHash tree-wide.
Fixes#121994.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
"paladin" doesn't seem to be up to date, whereas "full" seems to match
what cros-updates-serving.appspot.com reports is currently being
shipped to Chromebooks.
Previously, we would asssert that the lockfiles are consistent during the
unpackPhase, but if the pkg has a patch for the lockfile itself then we must
wait until the patchPhase is complete to check.
This also removes an implicity dependency on the src attribute coming from
`fetchzip` / `fetchFromGitHub`, which happens to name the source directory
"source". Now we glob for it, so different fetchers will work consistently.
Changes the default fetcher in the Rust Platform to be the newer
`fetchCargoTarball`, and changes every application using the current default to
instead opt out.
This commit does not change any hashes or cause any rebuilds. Once integrated,
we will start deleting the opt-outs and recomputing hashes.
See #79975 for details.
Replaced src munging with a custom unpackPhase because the previous
approach couldn't handle a newly introduced path with a space, and
this is cleaner anyway (but was impossible at the time due to
unpackPhase not being forwarded to fetchcargo).
It has been explained to me that cros-omahaproxy reports which
versions are available to users, while cros-updates-serving reports
the latest builds available for each channel. The latter is probably
better for our use case anyway, and apparently, while both aren't
officially supported, is less likely to randomly break.
So let's use that instead, even if it is much more annoying to parse.
