Comment 0 for bug 2003981

In autodep8 version 0.28, the following changelog entry exists:

   * Add support for pybuild-autopkgtest, via
     `Testsuite: autopkgtest-pkg-pybuild`. See pybuild-autopkgtest(1) for
     usage details.

Packages in Debian have started to transition over, an example being python-hypothesis. In Debian Unstable, the full testsuite is ran as expected:

I: pybuild base:240: cd /tmp/autopkgtest-lxc.cgbhfp5l/downtmp/autopkgtest_tmp/build; python3.10 -m pytest -k 'not dateutil' tests/cover tests/nocover tests/datetime tests/numpy

And indeed, this is what upstream expects for automated testing. However, in Ubuntu this is the entire "test":

autopkgtest [01:13:55]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import hypothesis; print(hypothesis)" ; done

Importing the Python module and printing out an object representation can hardly be considered a test suite. While there is no debian/tests directory, the Debian Maintainer likely expects tests to be ran, given that "Testsuite: autopkgtest-pkg-pybuild" is directly specified in debian/control.

Here is a rough package count:

$ grep-dctrl --show-field Package -F Testsuite "autopkgtest-pkg-pybuild" /var/lib/apt/lists/*Sources | sed "s/Package: //" | sort -u | wc -l
88

While I do not have direct SSH access to the autopkgtest cloud, from reading the code it seems clear to me that autodep8 is built from source, from this Git repository: https://git.launchpad.net/~ubuntu-release/+git/autodep8/
References:
 - https://git.launchpad.net/autopkgtest-cloud/tree/charms/focal/autopkgtest-cloud-worker/reactive/autopkgtest_cloud_worker.py#n44
 - https://git.launchpad.net/autopkgtest-cloud/tree/charms/focal/autopkgtest-cloud-worker/actions/update-sources#n19
 - https://git.launchpad.net/autopkgtest-cloud/tree/charms/focal/autopkgtest-cloud-worker/lib/utils.py#n40

The aforementioned autodep8 repository needs an update, and someone with SSH access should run the following (per the admin reference guide):
$ juju run-action <unit> reload-units
(where <unit> is the cloud/lxd worker shown in juju status)