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.
