DFSG NEW review for pydantic-handlebars version 0.2.1-2

Summary

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

Licensing

The source is uniformly MIT/Expat: LICENSE carries Copyright (c) 2026 Pydantic Services Inc., matching the DEB-5 Files: * stanza, and the ten tests ported from the handlebars.js spec suite have a later stanza naming Yehuda Katz (2011-2019) with the same Expat text, whose source licence was retrieved from handlebars.js. The prescan's author check found every holder named; a grep for copyright, licence and non-free terms across the tree found nothing else. The full Expat text is present, and no file needs a /usr/share/common-licenses reference. debian/copyright is machine-readable and its stanzas match the tree.

Packaging

The packaging is conventional and mostly clean: debhelper 14 with pybuild, Testsuite: autopkgtest-pkg-pybuild with a correct debian/pybuild.testfiles, two well-formed DEP-3 patches, a doc package with doc-base, and no unused or missing substvars. One real bug remains: debian/rules implements the nodoc switch with DEB_BUILD_OPTIONS only, while the package declares and its CI exercises the nodoc build profile, so a profile-aware build still tries to run mkdocs after the profile has removed it from the build dependencies.

Issues

1. [minor] [packaging] debian/rules checks nodoc in DEB_BUILD_OPTIONS only, so the declared nodoc build profile still runs mkdocs without it installed

• Files: debian/rules:9, debian/rules:13, debian/control
• Basis: checked, in the package or with a reference tool
• Evidence: Both blocks are guarded with ifeq ($(filter nodoc,$(DEB_BUILD_OPTIONS)),), around mkdocs build -d $(CURDIR)/build/html and around dh_mkdocs -T mkdocs -T libjs-underscore -T mkdocs-material. debian/control declares Build-Profiles: <!nodoc> on pydantic-handlebars-doc and puts mkdocs <!nodoc>, mkdocs-material <!nodoc>, mkdocstrings <!nodoc> and mkdocstrings-python-handlers <!nodoc> in Build-Depends-Indep. Policy 4.9.2: enabled build profiles are listed in DEB_BUILD_PROFILES, not in DEB_BUILD_OPTIONS.
• Problem: With -P nodoc (the second profile in debian/salsa-ci.yml's test-build-profiles matrix) DEB_BUILD_OPTIONS does not contain nodoc, so execute_after_dh_auto_build still runs mkdocs build, while the profile has dropped mkdocs, mkdocs-material and the mkdocstrings packages from Build-Depends-Indep; the build stops at mkdocs: not found. Even if it got past that, dh_mkdocs in execute_after_dh_installdocs would abort with MkDocs directory not found, because the < !nodoc> doc package is not built. debhelper itself honours both forms (dh_installdocs uses is_build_profile_active('nodoc') || get_buildoption('nodoc')), which is why the rest of the nodoc handling does not fail.
• Fix: Test the profile as well, e.g. ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES))) around both blocks, or key the docs build wholly on dh_listpackages containing pydantic-handlebars-doc.

Verified

• Prescan: its only output was the author check (every holder found is named in debian/copyright), which matches what I found; it listed no files, so there was no built/minified/non-free file to account for.
• Enumerated every upstream path (57 files, .pc/ and debian/cargo-checksum.json absent): no images, fonts, sounds, archives, PDFs, bytecode or minified code. uv.lock is uv's generated lock file, generated from the shipped pyproject.toml.
• Upstream LICENSE is the MIT/Expat text with Copyright (c) 2026 Pydantic Services Inc.; no source or test file carries its own copyright or licence header. The Files: * stanza matches it.
• The later stanza for the ten tests under tests/ names Yehuda Katz 2011-2019: CLAUDE.md states the tests were ported from handlebars.js's spec suite, and handlebars.js's LICENSE is the same Expat text with Copyright (C) 2011-2019 by Yehuda Katz, so the attribution and License: Expat are right.
• Grep for Copyright, (C), ©, SPDX-License-Identifier, Licensed under, GNU General/Lesser, Apache License, Mozilla Public, public domain, All rights reserved, non-commercial, no modification and Creative Commons found nothing besides LICENSE and debian/copyright; docs/helpers.md's {{#unless license}} is example template text, not a licence term.
• debian/copyright is DEP-5: canonical Format: URL, Source:, Files: *, Files: debian/*, the tests stanza with Comment: and License: Expat, and a stand-alone Expat paragraph with the full text.
• Read all of debian/ in full: control, rules, changelog, series and both patches, pybuild.testfiles, doc-base, .docs, source/format, gbp.conf, salsa-ci.yml, upstream/metadata.
• Test imports (pytest, hypothesis, pytest-examples, pydantic, pytest-xdist) match Build-Depends-Indep; the comment line in debian/pybuild.testfiles is skipped by pybuild (line.startswith('#') in /usr/share/dh-python/dhpython/build/base.py).
• Both patches are DEP-3 (From/Date/Subject/Forwarded) and match the applied tree: one adds paths: [src], font: false, use_directory_urls: false to mkdocs.yml, the other skips the ruff-based docstring lint test.
• dh_mkdocs exists on this system (shipped by mkdocs, which Provides: dh-sequence-mkdocs) and only uses -T to scan extra packages for symlink targets; the doc-base absolute Files:/Index: paths are the same form used by other packages in /usr/share/doc-base.
• uscan found the packaged version as the newest upstream release (upstream 0.2.1, packaged 0.2.1).

Not confirmed

• Whether the mkdocs-material theme lists sitemap.xml in its static_templates: dh_mkdocs requires an sitemap.xml next to index.html and would otherwise abort with MkDocs directory not found. mkdocs-material is not installed here, so I could only check mkdocs's own build code (the sitemap template is rendered whenever the theme lists it). The maintainer's find ... sitemap.xml.gz -delete suggests the file is produced.
• Whether salsa-ci's test-build-profiles job installs Build-Depends profile-aware; if it does not, mkdocs would still be installed for the nodoc job and would mask the failure described in the issue, while sbuild --profiles=nodoc would fail.

Proposed changes

None.