Re: Adding dependencies for autopkgtest run at Debian CI
* Antonio Terceiro <firstname.lastname@example.org> [2018-08-26 10:49]:
On Sun, Aug 26, 2018 at 11:16:14AM +0200, Rafael Laboissière wrote:
We started a discussion on the issue below in the Debian Octave Group
mailing list , but I think it would be better to move it here. I am
Cc'ing this message to the DOG list.
Package octave-level-set, version 0.3.0-1, failed to run the unit tests on
Debian CI . This happened because several unit tests run “pkg load
parallel”. I think I fixed the problem in version 0.3.0-2 of the package by
adding a dependency on octave-parallel.
I am not really happy with this “fix”, because parallel is not really a
dependency of level-set (at least, the upstream author does not declare it).
Now, there is another package in a similar situation: octave-vibes run “pkg
load interval” in some unit tests . I am not sure it will be appropriate
to make octave-vibes depend on octave-interval, since the package works
perfectly without it (besides the mentioned unit test failures).
It would be perfect if there was a way to add an extra dependency for the
run on Debian CI. I am not sure whether this can be accomplished through
looking at e.g. octave-level-set, I noticed that octave-parallel was
already in Build-Depends: on octave-parallel before you added it to
What you can do in autodep8 is to parse debian/control and add the
build dependencies to the generated debian/tests/control. We already do
that for Perl and Ruby, with different approaches:
- Perl has separate tests that run with and without build dependencies
installed, so it just uses @builddeps@
- Ruby has a single test run. autodep8 parses Build-Depends and adds
them to the generated test control file. But it filters out
dependencies we know are only used to compile stuff (debhelper,
gem2deb), which should not be needed to run tests against the
Thanks for the suggestion, Antonio. I implemented the second solution in
commit 1ea911c. If nobody objects, I will make a new release of autodep8
(version 0.14, I guess).
Also,I think we could bump the Standards-Version to 4.2.1. By the way,
version 4.1.5 of the Debian Policy introduced the field
Rules-Requires-Root for debian/control. If it is okay with you, I will
add "Rules-Requires-Root: no" to debian/control.