DFSG NEW review for runtype version 0.5.3-1

Summary

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

Licensing

Everything in the tree is MIT-licensed, held by Erez Shinan alone, and debian/copyright says so. It is a DEP-5 file with the correct Format line and a single Files: * stanza (Copyright: 2020, Erez Shinan <erezshin@gmail.com>, License: MIT), which matches LICENSE, docs/conf.py's copyright = '2020, Erez Shinan', README.md ("Runtype uses the MIT license") and pyproject.toml (license = "MIT"). The full MIT text is included as a stand-alone License paragraph, as required for a permissive licence that is not in /usr/share/common-licenses; there is no other holder, no second licence and nothing non-free anywhere in the 48-file tree, so no Files-Excluded is needed.

Packaging

Straightforward Debian Python Team packaging for a new package, and it is put together correctly: pybuild picks the setup.py (distutils) plugin over the pyproject one, so python3-setuptools is the right and sufficient build dependency and poetry-core is not needed; the source name (runtype) differing from the binary name (python3-runtype) is handled by the single-binary addon, which compat 14 requires to keep dh_auto_install's destdir at debian/python3-runtype. Only three minor points are worth fixing before upload: the Standards-Version, a test-only Build-Depends that is neither annotated nor actually exercised, and the absent autopkgtest.

Issues

1. [minor] [packaging] Standards-Version 4.6.1 is older than the current Policy 4.7.4.1

• Files: debian/control:11
• Basis: checked, in the package or with a reference tool
• Evidence: Standards-Version: 4.6.1
• Problem: The reviewing system's Policy is 4.7.4.1 (policy tool, table of contents), so the field's first two components (4.6) are behind the current series (4.7): an issue of minor severity by the review's own rule. The package has not been checked against anything changed since 4.6.1 (Policy Appendix A10).
• Fix: Bump to Standards-Version: 4.7.4 (or 4.7.4.1) and work through the A10 upgrading checklist for 4.7.x.

2. [minor] [packaging] Build-Depends mypy is used only by tests/test_mypy.py, whose tests the build's runner never collects

• Files: debian/control:6, debian/rules:4, tests/test_mypy.py:9-22
• Basis: checked, in the package or with a reference tool
• Evidence: Build-Depends: debhelper-compat (= 14), dh-python, python3-setuptools, python3, mypy; pybuild (in /usr/share/perl5/Debian/Debhelper/Buildsystem/pybuild.pm) only adds --test-pytest if (grep {$_ eq 'python3-pytest'} @deps ...), and dhpython/build/base.py:test_cmd otherwise falls back to cd {build_dir}; {interpreter} -m unittest discover -v.
• Problem: python3-pytest is not in Build-Depends, so pybuild's test step never selects pytest and the build runs the unittest runner. That collects TestCase classes only; tests/test_mypy.py defines module-level def test_dataclass():/def test_dispatch():, which unittest does not collect, so mypy is imported at discovery but its assertions never run — the dependency buys nothing. It is also not annotated <!nocheck> even though it is needed only for the test suite, so a nocheck build (dh skips dh_auto_test at compat 13+) still installs it; Policy 4.9.2 describes the <!nocheck> annotation for exactly this.
• Fix: Either drop mypy from Build-Depends, or make the checks actually run (add python3-pytest, and whatever else the suite needs — pyproject.toml's [tool.pytest.ini_options] addopts require the pytest-benchmark plugin); in either case annotate the test-only dependency, e.g. mypy <!nocheck>.

3. [minor] [packaging] No debian/tests/control: the package has no autopkgtest although its test suite runs against the installed module

• Files: debian/
• Basis: inferred from what was read, not seen directly
• Evidence: The source ships tests/ (unittest-based TestCase suites, plus tests/test_mypy.py and tests/benchmarks/), which is what the build itself runs (cd {build_dir}; python3 -m unittest discover -v), but there is no debian/tests directory and no Testsuite: header.
• Problem: Nothing exercises the installed package in the archive's test runners, so an ABI/behavioural regression in python3-runtype would only be caught by hand. This is established Debian Python Team practice rather than a Policy requirement; hence minor.
• Fix: Add a debian/tests/control, e.g. Test-Command: python3 -m unittest discover -v tests with Depends: @, python3-mypy, or use the team's pybuild-autopkgtest helper; dpkg-source then adds the Testsuite header itself.

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

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

Verified

• Whole tree (48 files, excluding .pc/ and debian/cargo-checksum.json, of which there is none) grepped for Copyright, (C), ©, SPDX-License-Identifier, Licensed under, Permission is hereby granted, GNU General Public, GNU Lesser, Apache License, Mozilla Public, public domain, All rights reserved, licen[cs], BSD, GPL, MPL, CC0, WTFPL: the only licence statements are LICENSE (MIT, Copyright (c) 2020 Erez Shinan), docs/conf.py:62 (copyright = '2020, Erez Shinan'), README.md:159 ("Runtype uses the MIT license (LICENSE)") and pyproject.toml:6 (license = "MIT"). No other holder appears, matching the pre-scan's Author check result.
• Binary images not opened, as required: bench1.jpg, bench2.jpg, logo.png at the top level and docs/bench_dispatch.jpg, docs/bench_dispatch_union.jpg, docs/bench_validation.jpg. docs/generate_benchmarks.sh and docs/plot_benchmarks.py show that the docs plots are generated from the project's own benchmark JSON by matplotlib, and README.md:1 displays logo.png, so all are upstream's own files under the Files: * MIT stanza.
• No vendored or embedded third-party code: no .jar/.so/.class/.min.js/Makefile.in trees, and docs/requirements.txt lists only Sphinx tooling (recommonmark, sphinx-gallery, sphinx_markdown_tables, sphinx_rtd_theme).
• The three typing_extensions uses are all guarded (runtype/pytypes.py:23-26 try: import typing_extensions / except ImportError:, runtype/dataclass.py:17-21 under if TYPE_CHECKING, tests/test_basic.py:18-21 try/except), so no python3-typing-extensions dependency is required; runtype's runtime imports are stdlib-only.
• Build system resolution read from the system: pybuild's distutils plugin scores 50 for setup.py against the pyproject plugin's 40 (base detect 50, -20 for a beta plugin, +10 for a build-backend), so python3 setup.py build with build_lib set to build_dir is used (/usr/share/dh-python/dhpython/build/plugin_distutils.py, plugin_pyproject.py, base.py) and python3-setuptools is the correct, sufficient dependency; neither poetry-core nor python3-build/pybuild-plugin-pyproject is needed.
• The build's test step does run: dh_auto_test calls pybuild --test, and the fallback runner python3 -m unittest discover collects tests/ (it has init.py), while tests/benchmarks is skipped because /usr/lib/python3.13/unittest/loader.py:428-429 returns without recursing into a directory lacking init.py — so the pytest/benchmark tests are never imported and their missing dependencies are not a build failure.
• Provides: ${python3:Provides} and the substvars in Depends are harmless at this compat level: dh_gencontrol at compat 14 supplies any ${name:Field} named after a relationship field itself (debhelper tool, dh_gencontrol / compat-14 changes).
• --with=single-binary in debian/rules is a real dh addon and the correct handling for this source (Source: runtype, binary python3-runtype, no debian/install): it passes --destdir=debian/<package>/ to dh_auto_install, and at compat 14 the addon is otherwise only activated implicitly with a warning (dh(1) --with, the single-binary addon description, debhelper compat-14 changes).
• debian/source/format is 3.0 (quilt); there is no debian/patches and .pc/applied-patches is empty, so no patches are applied or needed; mypy is a real binary package and dependency (apt-cache: mypy 2.4.0-3).
• The debian/* files themselves carry no notices; they are covered by the Files: * stanza, and the copyright file's one stanza is the only one needed for this tree.
• debian/watch deliberately not reviewed.
• uscan found the packaged version as the newest upstream release (upstream 0.5.3, packaged 0.5.3).

Not confirmed

• No build or test run was possible in this read-only review, so build and test success are unconfirmed; nothing seen suggests a build failure (in particular the setup.py build path, the present python3-setuptools/mypy dependencies and the unittest test step all resolve).
• Whether the binary package ships runtype/py.typed is not confirmed: setup.py:12 sets package_data = { '': ['*.md'] }, which does not match py.typed, but setuptools of the version in the archive may add py.typed automatically.