| 2023-01-26 20:57:51 |
Simon Quigley |
description |
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) |
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> update-sources
(where <unit> is the cloud/lxd worker shown in juju status) |
|
