DFSG NEW review for jaraco.packaging version 10.4.0-1

Summary

• Licensing is DFSG-compliant and debian/copyright is accurate: Yes
• Packaging is of good quality: No
• Issues: 0 blocker, 1 important, 4 minor
• debian/watch: old format (version 4)
• debian/copyright: machine-readable
• Scan before the review: nothing found

Licensing

The tree is MIT/Expat throughout: LICENSE is the complete Expat text, and no file carries a conflicting notice or third-party code. debian/copyright is DEP-5, matches Files: * to Expat with the upstream holder, overrides debian/* with GPL-3+, contains the full Expat text and points to /usr/share/common-licenses/GPL-3 for the packaging, and the packaging files' own headers agree. The only wrinkle is upstream's LICENSE, which has an unsubstituted <copyright holders> placeholder; the holder it omits is named in debian/copyright and in pyproject.toml, so the Debian description is accurate, and this is an upstream defect, not a DFSG problem.

Packaging

The packaging is tidy (compat 14, pybuild/pyproject, no patches, correct maintainer scripts and changelog) but has one defect a sponsor would require fixed: pyproject.toml's build system requires setuptools_scm for the dynamic version, and neither Build-Depends nor Build-Depends-Indep installs python3-setuptools-scm; pybuild builds with --no-isolation --skip-dependency-check, so the build has no way to obtain the version. The autopkgtest the maintainer clearly intended is also inert because debian/control lacks the Testsuite: field that makes autopkgtest call autodep8, and the shipped helper file is a deprecated form. debian/README.source is copied from a different package.

Issues

1. [important] [packaging] Build-Depends lacks python3-setuptools-scm required by the pyproject build system

• Files: debian/control:3-16, pyproject.toml:1-6, pyproject.toml:33
• Basis: inferred from what was read, not seen directly
• Evidence: pyproject.toml: requires = ["setuptools>=77", "setuptools_scm[toml]>=3.4.1", ...], dynamic = ["version"] and a [tool.setuptools_scm] table; debian/control lists python3-setuptools (>= 77) and python3-coherent.licensed but no python3-setuptools-scm. dh-python builds with python3 -m build --skip-dependency-check --no-isolation --wheel (/usr/share/dh-python/dhpython/build/plugin_pyproject.py:147).
• Problem: With isolation disabled, the backend requirements in build-system.requires are not installed; setuptools must itself provide the version from the setuptools_scm integration, but the module/entry point is absent from a clean build environment, so the dynamic version cannot be resolved and the build fails. Nothing else in the declared build dependencies pulls in python3-setuptools-scm (python3-setuptools and python3-coherent.licensed do not depend on it).
• Fix: Add python3-setuptools-scm to Build-Depends-Indep (the only binary is Architecture: all), and, if a build from the unpacked source has no SCM metadata, set SETUPTOOLS_SCM_PRETEND_VERSION from the changelog or otherwise ensure the version is found.

2. [minor] [packaging] No autopkgtests run: source stanza lacks Testsuite: autopkgtest-pkg-python

• Files: debian/control:1-6, debian/tests/pkg-python/import-name:5
• Basis: checked, in the package or with a reference tool
• Evidence: debian/control has no Testsuite: field and there is no debian/tests/control; the only test material is debian/tests/pkg-python/import-name containing jaraco.packaging. autodep8(1): "autodep8 can be automatically called by autopkgtest. To achieve that, you must set the Testsuite: field in the source package paragraph to autopkgtest-pkg-TYPE".
• Problem: autodep8's pkg-python generator is only invoked when the source stanza declares the package type, so the shipped configuration is never used and the package has no automatic smoke test at all (Policy 5.6.30 notes Testsuite is added to the .dsc only when debian/tests/control exists). Additionally, autodep8 warns that debian/tests/pkg-python/import-name is deprecated in favour of debian/tests/autopkgtest-pkg-python.conf, which the man page documents (import_name).
• Fix: Add Testsuite: autopkgtest-pkg-python to the source stanza, then replace debian/tests/pkg-python/import-name with debian/tests/autopkgtest-pkg-python.conf containing import_name = jaraco.packaging.

3. [minor] [packaging] Upstream's build[virtualenv] runtime extra is not represented in Depends/Recommends

• Files: pyproject.toml:27-29, debian/control:17-25
• Basis: inferred from what was read, not seen directly
• Evidence: Metadata declares Requires-Dist: build[virtualenv]; dh_python3 ignores extras unless asked with --depends-section (/usr/share/dh-python/dhpython/pydist.py:743-751), so the binary only gets python3-build. apt-cache show python3-build shows only Suggests: python3-pip, python3-venv.
• Problem: jaraco.packaging.sphinx calls metadata.load, whose default is an isolated metadata build (jaraco/packaging/sphinx.py:132-136, jaraco/packaging/metadata.py:7-10; BUILD_ENVIRONMENT=current is the documented opt-out). Without virtualenv and with Debian's python3 lacking ensurepip unless python3-venv is installed, the default path cannot create its build environment, so the extension's normal use fails on a plain installation.
• Fix: Add Recommends: python3-virtualenv (matching upstream's [virtualenv] extra) or, at least, python3-venv and python3-pip, so the documented default mode works.

4. [minor] [packaging] debian/README.source names the wrong package

• Files: debian/README.source:2
• Basis: checked, in the package or with a reference tool
• Evidence: Debian source package for ‘jaraco.logging’ under a rule of equal signs.
• Problem: The file is copied from another package and misidentifies the source package under review as jaraco.logging.
• Fix: Change the title to Debian source package for ‘jaraco.packaging’.

5. [minor] [packaging] debian/watch is in the old version 4 format

• Files: debian/watch
• Basis: found by the review tooling's own checks
• Evidence: version = 4
• Problem: Version 5 is the current format of debian/watch.
• Fix: Convert it to version 5; a mechanical conversion is under Proposed changes.

Verified

• The scan before the review listed no files: its author check found every holder in the tree and all are covered by debian/copyright; there was nothing to account for.
• Inventory: every upstream file (31, excluding debian/ and the ignored .pc/) was examined; all are text and none is binary, minified, vendored third-party code or a built artifact other than PKG-INFO and jaraco.packaging.egg-info/, which are metadata regenerated from pyproject.toml/PKG-INFO and removed by debian/clean.
• LICENSE (both in the tree and in jaraco.packaging_10.4.0.orig.tar.gz) is the complete Expat text; its Copyright (c) 2026 <copyright holders> is an unsubstituted upstream placeholder, but pyproject.toml and PKG-INFO name Jason R. Coombs and debian/copyright's Files: * gives © 2013–2026 Jason R. Coombs <jaraco@jaraco.com>, so the Debian description is not inaccurate.
• License evidence across the tree: no SPDX tags or copyright headers in the Python sources, docs/, .github/ or config files; debian/rules, debian/upstream/metadata and debian/README.source each state GPL-3+, matching the debian/* stanza; no non-free wording (non-commercial, no-modification, field-of-use) anywhere.
• debian/copyright is DEP-5 with the exact 1.0 Format URL, a Files: * stanza and a later debian/* stanza (correct override order), the full Expat licence text and a GPL-3+ pointer to /usr/share/common-licenses/GPL-3; extra fields are permitted by copyright-format §4, so License-Grant is not a format error.
• debian/changelog (10.4.0-1, unstable, ITP bug #1151194), debian/source/format (3.0 quilt), debian/rules, debian/gbp.conf, debian/salsa-ci.yaml, debian/source/lintian-overrides and debian/upstream/metadata were read; there are no patches.
• Standards-Version 4.7.4 matches the reviewing system's Policy 4.7.4.1 in the first two components, and debhelper compat 14 is the recommended level; the single-binary add-on used by rules exists at compat 14.
• debian/rules's override_dh_auto_test is defensible: conftest.py downloads sampleproject from the network, and upstream's doctests build the project, so the suite cannot run in a build chroot; pytest is listed <nocheck> but the target is skipped anyway at compat 14.
• Enhances: names ${python3:Enhances} and ${misc:Enhances}, which nothing defines; dpkg's Substvars drops undefined variables (with a warning) and deps_parse skips the resulting empty list elements, so the field reduces to python3-sphinx and does not break the build.
• docs/history.rst includes ../NEWS (links).rst, which is generated by rst.linker and absent from the tree; the Debian package does not build the docs (no -doc package, no doc override), so this affects only upstream's readthedocs build.
• No build or test was run; the packaging was judged from debian/, the source tree, the .dsc/orig tarball, and the reviewing system's dh-python, dpkg and autodep8 sources.
• uscan found the packaged version as the newest upstream release (upstream 10.4.0, packaged 10.4.0).
• Every pointer of debian/copyright to /usr/share/common-licenses names a file that is there (GPL-3).

Not confirmed

• Whether, once python3-setuptools-scm is build-depended, setuptools_scm can take version 10.4.0 from the shipped PKG-INFO without a .git checkout, or whether SETUPTOOLS_SCM_PRETEND_VERSION is also needed; a build would show.
• Whether the default isolated metadata path in fact fails without python3-venv/python3-pip/python3-virtualenv on an installed system; that is the reasoning behind the build[virtualenv] issue and a runtime test would confirm it.