On August 7, 2022 9:01 pm, Peter Michael Green wrote: > Package: debcargo > Version: 2.5.0-3 > > Alexander Kjäll was working on packaging wl-clipboard-rs when he ran > into an autopkgtest failure. >> debian cargo wrapper: options, profiles, parallel: ['parallel=4'] [] ['-j4'] >> debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, >> x86_64-linux-gnu >> debian cargo wrapper: linking /usr/share/cargo/registry/* into >> /tmp/tmp.Zo0aVr3cJs/registry/ >> debian cargo wrapper: options, profiles, parallel: ['parallel=4'] [] ['-j4'] >> debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, >> x86_64-linux-gnu >> debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', >> '/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', >> '-j4', '--target', 'x86_64-unknown-linux-gnu', '--all-targets', >> '--no-default-features', '--features', 'native_lib'],) {} >> error: no matching package named `parking_lot` found >> location searched: registry `crates-io` >> required by package `wayland-server v0.29.4` >> ... which satisfies dependency `wayland-server = "^0.29.4"` of package >> `wl-clipboard-rs v0.6.0 (/usr/share/cargo/registry/wl-clipboard-rs-0.6.0)` > > Investigating showed that Cargo.toml contains the following > >> [dev-dependencies.wayland-server] >> version = "0.29.4" >> >> [features] >> dlopen = ["native_lib", "wayland-client/dlopen", "wayland-server/dlopen"] >> native_lib = ["wayland-client/use_system_lib", >> "wayland-server/use_system_lib"] > If I am reading this correctly this means that when running tests with > the "native_lib" feature enabled, the "use_system_lib" feature of the > wayland-server package will be enabled. > > However debcargo does not generate a test dependency on > librust-wayland-server+use-system-lib-dev > > I believe this is the result of the error Alexander encountered (and I > reproduced) > > The packaging for wl-clipboard-rs ia available in the > WIP-wl-clipboard-rs branch of debcargo-conf. > Package: debcargo > Version: 2.5.0-3 > > Alexander Kjäll was working on packaging wl-clipboard-rs when he ran into an > autopkgtest failure. > > debian cargo wrapper: options, profiles, parallel: ['parallel=4'] [] > ['-j4'] > debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, > x86_64-linux-gnu > debian cargo wrapper: linking /usr/share/cargo/registry/* into > /tmp/tmp.Zo0aVr3cJs/registry/ > debian cargo wrapper: options, profiles, parallel: ['parallel=4'] [] > ['-j4'] > debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, > x86_64-linux-gnu > debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', > '/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', > '-j4', '--target', 'x86_64-unknown-linux-gnu', '--all-targets', > '--no-default-features', '--features', 'native_lib'],) {} > error: no matching package named `parking_lot` found > location searched: registry `crates-io` > required by package `wayland-server v0.29.4` > ... which satisfies dependency `wayland-server = "^0.29.4"` of > package `wl-clipboard-rs v0.6.0 > (/usr/share/cargo/registry/wl-clipboard-rs-0.6.0)` > > Investigating showed that Cargo.toml contains the following > > [dev-dependencies.wayland-server] > version = "0.29.4" > > [features] > dlopen = ["native_lib", "wayland-client/dlopen", "wayland-server/dlopen"] > native_lib = ["wayland-client/use_system_lib", "wayland-server/ > use_system_lib"] > > If I am reading this correctly this means that when running tests with the > "native_lib" feature enabled, the "use_system_lib" feature of the > wayland-server package will be enabled. > > However debcargo does not generate a test dependency on > librust-wayland-server+use-system-lib-dev > > I believe this is the result of the error Alexander encountered (and I > reproduced) > > The packaging for wl-clipboard-rs ia available in the WIP-wl-clipboard-rs > branch of debcargo-conf.
just to add some extra info: such a feature -> dev-dep relationship is currently intentionally dropped when resolving features and dependencies[0]. it probably makes sense to only do that for "regular" resolution, and keep them for "autopkgtest" resolution, like you proposed - either by extending[1] the relevant code[1,2] to keep track of them separately, or by introducing a parameter to control skipping them. given that there are currently only two call sites and both might benefit from having the extra info available, extending might be better. as a workaround, setting "test_depends" in debcargo.toml manually should work (although it is rather cumbersome for all the obvious reasons). 0: https://salsa.debian.org/rust-team/debcargo/-/issues/37 (and the commit closing it) 1: https://salsa.debian.org/rust-team/debcargo/-/blob/master/src/crates.rs#L46 2: https://salsa.debian.org/rust-team/debcargo/-/blob/master/src/crates.rs#L380