Hi,
I have been working towards getting crosvm into Debian, and I would like to
ask where this ITP stands before going further, since it is yours and not
mine.
My interest is concrete: I am adding a crosvm backend to syzkaller, so that
Linux kernel fuzzing can run under crosvm as well as QEMU. That works today
against a locally built crosvm, and it would be considerably more useful if
crosvm were simply installable from Debian.
The blocker has never really been crosvm itself, it has been the
dependencies. minijail was not in Debian at all, so I packaged it, taking
over the 2017 RFP (#860067):
https://salsa.debian.org/ysk/minijail
- three C packages, minijail (the minijail0 tool), libminijail1 and
libminijail-dev
- lintian clean at -EviIL +pedantic on source and binaries, and it builds
from its declared Build-Depends in a clean unstable chroot
- one patch worth mentioning: upstream links libminijail.so with no SONAME
(common.mk even carries a comment wondering whether to add one), which
Policy 8.1 requires for a shared library in a versioned package. The
package sets libminijail.so.1 and tracks the ABI with a symbols file.
That patch and two man page fixes are going upstream to
minijail@chromium.org rather than living in Debian indefinitely.
It also ships librust-minijail-dev and librust-minijail-sys-dev. Those two
crates are not on crates.io at all - "cargo info minijail" cannot find them,
and crosvm reaches them through a [patch.crates-io] entry pointing at the
git submodule, because ChromeOS supplies them out of band. Their only
source is rust/ in the minijail tree, so they are built from the minijail
source package rather than through debcargo. That is unusual enough that
I would rather have the Rust team's opinion on it than decide it alone,
so I am raising it on debian-rust separately.
With minijail in place, the remaining gap for crosvm is small and ordinary.
Building with
dh-cargo, --no-default-features --features qcow,balloon,net,usb,audio
pulls in 107 crates from crates.io, of which 105 are already in Debian. The
two that are not are p9 and p9_wire_format_derive. Both are published on
crates.io (0.3.2 and 0.3.0), both go through debcargo the normal way, and
neither cascades: p9 depends only on libc, serde, syn, quote, proc-macro2
and unicode-ident, all of which are already packaged. I have started
p9_wire_format_derive in debcargo-conf and will send both as merge requests.
Dropping gpu and slirp from the default feature set is what makes that list
so short. gpu needs rutabaga_gfx and magma-gpu, neither in Debian; slirp is a
Windows-only backend upstream and on Linux only drags in pcap-file and an
obsolete syn 0.11, while buying nothing, since crosvm has no user-mode
networking on Linux either way.
My packaging branch is at https://salsa.debian.org/ysk/crosvm
version 0.1.0~git20260806.a4bba0841-1, cut as a git snapshot because
upstream has called itself 0.1.0 since the beginning and makes no releases.
The source package assembles and is lintian clean, but it does not build yet,
for the two crates above, so its changelog still says UNRELEASED. I did not
want to claim more than that.
My plan, unless you would rather it went differently:
1. get minijail sponsored and uploaded first, since crosvm cannot enter
Debian without it
2. send p9 and p9_wire_format_derive to debcargo-conf
3. then crosvm itself
So, would you like to keep this ITP and have the dependency work handed to
you, co-maintain it, or hand it over? Any of those suits me. I am not a
Debian Developer, so either way the uploads will need a sponsor, and if you
or anyone reading on debian-devel is willing to review, I would be glad of
it.
Best Regards,
Yunseong Kim