[Pkg-rust-maintainers] Bug#1011153: dh-cargo, sometimes includes generated cargo.lock in lib package.

[Peter Green]

Package: dh-cargo

rust-libc is currently blocked from migrating to testing by an autopkgtest regression
in rust-rpassword.

> debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', '/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', '-j56', '--target', 'x86_64-unknown-linux-gnu', '--all-targets', '--no-default-features'],) {}
> error: failed to select a version for the requirement `libc = "=0.2.103"`
> candidate versions found which didn't match: 0.2.125
> location searched: directory source `/tmp/tmp.FK7ISfSozf/registry` (which is replacing registry `crates-io`)
> required by package `rpassword v5.0.1 (/usr/share/cargo/registry/rpassword-5.0.1)`

It appears the cause is that librust-rpassword-dev contains a Cargo.lock file which
was generated from the versions of packages in debian at the time of it's upload.

Doing some poking around it appears that the Cargo.lock file is generated by the
"dh_auto_test -- test --all" command in debian/rules. What I haven't figured out
is under what circumstances this happens, there appears to be at least* one other
rust library package containing a Cargo.lock file in it's root librust-os-pipe-dev
and it's autopkgtest is failing in the same way.

I think the most sensible way to deal with this is to exclude Cargo.lock in dh-cargo,
does anyone else have any thoughts before I go ahead and do that?


* The search on packages.debian.org for Cargo.lock gave a "too many results" error.