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

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.

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.

Sounds good to me.  I was just looking into this yesterday and was going
to suggest the same thing.

Cheers,

Looking into it more, this seems to be more of a problem with the
packages themselves, not dh-cargo.  Although, changing dh-cargo would
likely cause this to be caught sooner.  A lintian error would probably
be better.

The two problematic packages that have been brought up are
rust-rpassword and rust-os-pipe.  Both of these are running cargo
commands during their tests ("cargo run" and "cargo build",
respectively).

If dh-cargo doesn't install the Cargo.lock file, then autopkgtest for
those packages will still fail, but this time due to not being able to
write out the new Cargo.lock file when running the tests.

We either need to skip/patch out those particular tests in the packages
or adjust them so they use a temp directory.

Cheers,