A .ctags
A .dir-locals.el
A .github/lockdown.yml
A .gitignore
A .gitlab-ci.yml
A .mailmap
D AUTHORS
A AUTHORS.in
A CONTRIBUTING.rst
D ChangeLog
A HACKING
D MANIFEST
A Makefile
D PKG-INFO
M README
A ci/containers/README.rst
A ci/containers/ci-centos-8.Dockerfile
A ci/containers/ci-centos-stream-8.Dockerfile
A ci/containers/ci-debian-10.Dockerfile
A ci/containers/ci-debian-sid.Dockerfile
A ci/containers/ci-fedora-33.Dockerfile
A ci/containers/ci-fedora-34.Dockerfile
A ci/containers/ci-fedora-rawhide.Dockerfile
A ci/containers/ci-opensuse-leap-152.Dockerfile
A ci/containers/ci-opensuse-tumbleweed.Dockerfile
A ci/containers/ci-ubuntu-1804.Dockerfile
A ci/containers/ci-ubuntu-2004.Dockerfile
A ci/containers/refresh
A examples/README
A examples/dhcpleases.py
M generator.py
M libvirt-override-api.xml
M libvirt-override.c
D libvirt-python.spec
A libvirt-python.spec.in
A requirements-test.txt
M setup.py
M tests/test_conn.py
M tests/test_domain.py
A tests/test_domain_checkpoint.py
A tests/test_domain_snapshot.py
A tests/test_interface.py
A tests/test_network.py
A tests/test_nodedev.py
A tests/test_storage.py
M tox.ini
This mismatches the upstream tarball fetched (and gpg validated) by uscan as follows:
This seems to roughly inversely match your commit. It appears as though you've switched from the release tarball to a git snapshot. Wouldn't it be better to stick to what Debian are doing here? This has the additional advantage that uscan can be used to verify the orig tarball comes from and is signed by the same upstream used previously.
Looking at the diff, I don't see anything that looks like it would affect packaging, except for a change around the tests. I wondered if this would require a build dependency change, and if tests might silently stop running. From your PPA build log, I found that no tests are being run, so I thought this might indeed be a regression against the current version in Ubuntu. However, looking at the build log for Hirsute 7.0.0-2 (the current version), tests aren't running there either. So this isn't a regression, and therefore I wouldn't consider this issue to be a blocker for this MP.
It's possible that tests aren't useful and/or intended to run as part of the package build, but this isn't mentioned in the original MIR bug (https://bugs.launchpad.net/ubuntu/+source/libvirt-python/+bug/1262758) so could probably do with some investigation separate to this MP. I didn't look back as far as libvirt itself previous to the upstream release split though. Maybe it's worth filing a bug for this?
What orig tarball are you planning to use for this upload?
Your "New upstream version 7.6.0" shows me:
$ git log -1 -p --name-status c3539dc
commit c3539dc
Author: Christian Ehrhardt <email address hidden>
Date: Mon Aug 16 12:37:50 2021 +0200
New upstream version 7.6.0
A .ctags lockdown. yml README. rst ci-centos- 8.Dockerfile ci-centos- stream- 8.Dockerfile ci-debian- 10.Dockerfile ci-debian- sid.Dockerfile ci-fedora- 33.Dockerfile ci-fedora- 34.Dockerfile ci-fedora- rawhide. Dockerfile ci-opensuse- leap-152. Dockerfile ci-opensuse- tumbleweed. Dockerfile ci-ubuntu- 1804.Dockerfile ci-ubuntu- 2004.Dockerfile refresh dhcpleases. py override- api.xml python. spec.in test.txt domain. py domain_ checkpoint. py domain_ snapshot. py interface. py network. py nodedev. py storage. py
A .dir-locals.el
A .github/
A .gitignore
A .gitlab-ci.yml
A .mailmap
D AUTHORS
A AUTHORS.in
A CONTRIBUTING.rst
D ChangeLog
A HACKING
D MANIFEST
A Makefile
D PKG-INFO
M README
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A ci/containers/
A examples/README
A examples/
M generator.py
M libvirt-
M libvirt-override.c
D libvirt-python.spec
A libvirt-
A requirements-
M setup.py
M tests/test_conn.py
M tests/test_
A tests/test_
A tests/test_
A tests/test_
A tests/test_
A tests/test_
A tests/test_
M tox.ini
This mismatches the upstream tarball fetched (and gpg validated) by uscan as follows:
Extraneous files:
.ctags lockdown. yml G.rst containers/ README. rst containers/ ci-centos- 8.Dockerfile containers/ ci-centos- stream- 8.Dockerfile containers/ ci-debian- 10.Dockerfile containers/ ci-debian- sid.Dockerfile containers/ ci-fedora- 33.Dockerfile containers/ ci-fedora- 34.Dockerfile containers/ ci-fedora- rawhide. Dockerfile containers/ ci-opensuse- leap-152. Dockerfile containers/ ci-opensuse- tumbleweed. Dockerfile containers/ ci-ubuntu- 1804.Dockerfile containers/ ci-ubuntu- 2004.Dockerfile containers/ refresh dhcpleases. py python. spec.in s-test. txt test_domain_ checkpoint. py test_domain_ snapshot. py test_interface. py test_network. py test_nodedev. py test_storage. py
.dir-locals.el
.github/
.gitignore
.gitlab-ci.yml
.mailmap
AUTHORS.in
CONTRIBUTIN
HACKING
Makefile
ci/
ci/
ci/
ci/
ci/
ci/
ci/
ci/
ci/
ci/
ci/
ci/
ci/
examples/README
examples/
libvirt-
requirement
tests/
tests/
tests/
tests/
tests/
tests/
Missing files:
AUTHORS python. spec
ChangeLog
MANIFEST
PKG-INFO
libvirt-
This seems to roughly inversely match your commit. It appears as though you've switched from the release tarball to a git snapshot. Wouldn't it be better to stick to what Debian are doing here? This has the additional advantage that uscan can be used to verify the orig tarball comes from and is signed by the same upstream used previously.
Looking at the diff, I don't see anything that looks like it would affect packaging, except for a change around the tests. I wondered if this would require a build dependency change, and if tests might silently stop running. From your PPA build log, I found that no tests are being run, so I thought this might indeed be a regression against the current version in Ubuntu. However, looking at the build log for Hirsute 7.0.0-2 (the current version), tests aren't running there either. So this isn't a regression, and therefore I wouldn't consider this issue to be a blocker for this MP.
It's possible that tests aren't useful and/or intended to run as part of the package build, but this isn't mentioned in the original MIR bug (https:/ /bugs.launchpad .net/ubuntu/ +source/ libvirt- python/ +bug/1262758) so could probably do with some investigation separate to this MP. I didn't look back as far as libvirt itself previous to the upstream release split though. Maybe it's worth filing a bug for this?
Needs fixing: for the orig tarball question only.