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

[Fabian Grünbichler]

On May 17, 2022 5:25 pm, Peter Green wrote:
> 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?

that does indeed sound sensible - dh-cargo removes the Cargo.lock file 
as part of the configure step already, so doing that again at some later 
stage (or preventing the test invocation from re-generating one) seems 
like a good idea to ensure consistent behaviour.