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 [email protected] 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
