| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
* Add new vhost source dependency
* Drop Cargo.lock patch
* Re-enable test on x86_64 (seems to work fine now)
* Drop syslog patch
* Rebase VIRTIO_NET_F_MAC patch -- I renamed TapFdOptions to
TapFdOption for consistency with newly-added similar structs.
Message-Id: <20210603091138.24942-4-hi@alyssa.is>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crosvm now needs the Minijail sources. However, it'll notice that a
Minijail package is provided via pkg-config, and then not actually use
those sources or build its own Minijail. It would be nice if the
Minijail we provide could be the same version as in Chromium OS, which
means bringing Minijail under chromiumOSPackages.
A couple of backports are no longer required; one to common-mk and one
to Linux. A new patch to fix a parallel build failure has been
introduced.
Message-Id: <20200602005619.31128-1-hi@alyssa.is>
Thanks-to: Michael Raskin <7c6f434c@mail.ru>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
Tested-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These changes make chromiumOSPackages.updateScript better understand
the Repo manifest format[1].
It now properly distinguishes between paths in the Chromium OS source
tree and paths on the git servers, which are usually not the same.
For example, chromiumos-overlay is located in the source tree at
src/third_party/chromiumos-overlay, but on chromium.googlesource.com
it's located at chromiumos/overlays/chromiumos-overlays. Components
are now keyed by their location in the Chromium OS source tree (and
packages have all been updated for this change.)
Additionally, it now understands Repo remotes. This means that it is
now possible to use a Chromium OS component like Minijail, which is
hosted on android.googlesource.com rather than
chromiumos.googlesource.com. This was not previously possible.
[1]: https://gerrit.googlesource.com/git-repo/+/HEAD/docs/manifest-format.md
Message-Id: <20200530190028.6388-1-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
| |
Just noticed this. I wasn't able to test the script when removing
libchrome in f867986f602459d4c73e6e2247738ea3804ea05e because
cros-updates-serving was down.
|
| | |
|
| |
|
|
|
| |
These aren't needed for anything apart from the Sommelier demos (which
we never build anyway) and are annoying and hard to keep building.
|
| |
|
|
|
|
| |
"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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
sommelier has a lot of dependencies on other Chromium OS packages. To
manage this mess, I introduced chromiumOSPackages to hold them all,
since most of them won't be useful aside from building other
Chromium OS packages, and chromiumOSPackages.common-mk, which is a
wrapper around stdenv to handle interacting with Chromium OS's
idiosyncratic GN-based build system.
I adapted crosvm's updateScript to become the updateScript for all of
chromiumOSPackages, and pulled crosvm under chromiumOSPackages. This
means that all Chromium OS packages use approximately the same
versions that are distributed as an upstream release.
There are still a couple of Chromium OS packages in Nixpkgs that
aren't part of this set. Pulling those in is future work.
|