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.