On 2/9/21 11:15 PM, Jonas Smedegaard wrote:
Quoting Arnaud R (2021-02-09 16:55:40)
Hello Jonas!
On 2/9/21 5:46 PM, Jonas Smedegaard wrote:
I am puzzled as to what is the real cause, though: It seems to me that
the CI infrastructure neglects to install python3-vobject despite it
being declared as a dependency of python3-radicale
Oh, so actually I would add either python3-radicale, either radicale, to
the Depends field in d/tests/control, in order to install it in the
testbed, along with its dependencies (which include python3-vobject).
As far as I know (I might be wrong), it's not automatic. I think it's
because autopkgtest does not know which binary packages you intend to
test, so you have to make it explicit in the Depends field.
Alternatively there is the special dependency '@' , which installs all
the build dependencies of the source package.
Sorry, I don't follow your reasoning.
python3-radicale depends on python3-vobject.
radicale depends on python3-radicale which depends on python3-vobject.
Seems to me from the logfile that it tests python3-radicale (not
radicale) and that it installs python3-radicale as expected but then
does not install python3-vobject which I would expect from dependency
declared for python3-radicale - and that is what puzzles me: Seems to me
that the CI routine bootstraps a broken installation.
Or rephrased: It is my understanding that autopkgtest cannot know which
_additional_ packages might be needed for _testing_purposes, or if some
packages only _recommended_ is needed for testing purposes - but
_dependencies_ need not be declared for the test, as those must be
resolved by autopktest framework.
If indeed this is what happens, then adding python3-vobject as an
explicit dependency of the test is not a solution but instead shadows a
bug somewhere else.
If I am wrong in how to read and interpret the logfile then I need to
understand it before acting on it.
I looked at the logs again carefully, and here's my understanding.
There are two tests. First comes the test 'command1', and it corresponds
to the first (and only) test defined in debian/tests/control:
Test-Command:
pytest-3
Restrictions: allow-stderr
Depends:
python3-pytest,
python3-waitress,
We can see it in the logs:
autopkgtest [15:15:07]: testing package radicale version 3.0.6-1
autopkgtest [15:15:07]: build not needed
autopkgtest [15:15:07]: test command1: preparing testbed
The following additional packages will be installed:
At this point we see the list of packages that are installed in the
testbed to run this test. python3-radicale is NOT one of them. Instead,
what we see are the 2 packages python3-waitress and python3-pytest
(listed in debian/tests/control), along with their dependencies (total
20 packages).
Further down the log, we'll see that the test runs and fails:
autopkgtest [15:15:14]: test command1: pytest-3
Then comes the second test:
autopkgtest [15:15:15]: test autodep8-python3: preparing testbed
autopkgtest [15:15:30]: @@@@@@@@@@@@@@@@@@@@ test bed setup
autopkgtest [15:15:39]: testbed dpkg architecture: amd64
The following additional packages will be installed:
For this test, we can see that python3-radicale is being installed, and
the test actually succeeds.
The second test is probably run due to "Testsuite:
autopkgtest-pkg-python" in debian/control. It is not a test defined in
debian/tests/control.
Bottom-line: for tests that are defined by the maintainer in
debian/tests/control, one must list the dependencies needed to run the
test, including the package itself. In this case I would add
`python3-radicale` to the Depends field in debian/tests/control.
I hope that it clarifies. Note that I'm not an autopkgtest expert, this
is my understanding so far, I might be wrong.
All the best,
Arnaud
