DFSG NEW review for pydantic-handlebars version 0.2.1-1

Summary

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

Licensing

Everything in the tree is free and DFSG-compliant: the only licence text is LICENSE (MIT in its Expat form, Copyright (c) 2026 Pydantic Services Inc.) plus debian/copyright, there is no vendored code, no binary/font/image/minified file, no file without a licence and no non-free wording. debian/copyright is DEP-5 with the exact Format: URL, an Expat Files: * stanza, a Files: debian/* stanza and the complete Expat text. It is not complete for the whole source, though: ten tests/*.py declare themselves ports of handlebars.js's MIT spec suite and no handlebars.js copyright or notice is recorded anywhere for them (see the issue).

Packaging

Modern and largely correct: debhelper-compat 14 with dh-sequence-python3 and pybuild-plugin-pyproject, Architecture: all packages, correct Depends handling (dh_python3 maps pydantic -> python3-pydantic; the -doc package correctly has no Depends field because at compat 14 dh_gencontrol adds the mkdocs:Depends substvar itself), every Build-Depends/Build-Depends-Indep name exists in the archive, Standards-Version 4.7.4 is current (Policy 4.7.4.1), sane changelog, DEP-3 patches, doc-base and autopkgtest via Testsuite: autopkgtest-pkg-pybuild with debian/pybuild.testfiles. Two things should be fixed before upload: the nodoc guard in debian/rules reacts to DEB_BUILD_OPTIONS while the doc dependencies and the -doc package are guarded by the nodoc build profile its own control file uses, and the generated build/ tree is never cleaned.

Issues

1. [important] [licensing] tests ported from handlebars.js's MIT spec suite are not attributed in debian/copyright

• Files: tests/test_basic.py:3, tests/test_blocks.py:3, tests/test_builtins.py:3, tests/test_data.py:3, tests/test_helpers.py:3, tests/test_regressions.py:3, tests/test_security.py:3, tests/test_subexpressions.py:3, tests/test_tokenizer.py:3, tests/test_whitespace.py:3, debian/copyright
• Basis: checked, in the package or with a reference tool
• Evidence: Each of those ten modules opens with e.g. Ported from handlebars.js spec/basic.js. (spec/blocks.js, builtins.js, data.js, helpers.js, regressions.js, security.js, subexpressions.js, tokenizer.js, whitespace-control.js respectively), and the test names and their order correspond to those spec files. handlebars.js is MIT: /usr/share/nodejs/handlebars/package.json has "author": "Yehuda Katz" and "license": "MIT". debian/copyright's Files: * stanza says only Copyright: 2026, Pydantic Services Inc. with License: Expat, and its Expat paragraph reproduces Pydantic's notice.
• Problem: The copyright file claims one holder for every file, but those ten test modules are a 1:1 port of handlebars.js's MIT-licensed spec suite and so are derived from it. MIT requires that the upstream copyright notice and permission notice be kept in copies and derivative works, and nothing in the source package (LICENSE, the tests, or debian/copyright) carries handlebars.js's notice. debian/copyright is therefore inaccurate/incomplete for tests/*.py. Debian practice for ported code is to give it its own Files: stanza with the upstream holders and a Comment naming the origin (compare the installed /usr/share/doc/node-es-module-lexer/copyright, which does exactly that for a function ported from acorn).
• Fix: Add a Files: stanza in debian/copyright covering the ten ported modules (they can be listed explicitly, or the remaining test modules left in Files: *), giving handlebars.js's own copyright line as its LICENSE states it (Copyright (C) 2011-2019 by Yehuda Katz, reproduced exactly) and License: Expat, with a Comment naming the upstream spec file(s) each was ported from. No new stand-alone License paragraph is needed, since the Expat text already covers it.

2. [important] [packaging] debian/rules guards the documentation build on DEB_BUILD_OPTIONS, but the doc dependencies and -doc package use the nodoc build profile

• Files: debian/rules:9, debian/rules:13, debian/control
• Basis: checked, in the package or with a reference tool
• Evidence: debian/rules has ifeq ($(filter nodoc,$(DEB_BUILD_OPTIONS)),) above both mkdocs build -d $(CURDIR)/build/html -f $(CURDIR)/mkdocs.yml and the dh_mkdocs call, while debian/control guards the doc tooling with the profile (Build-Depends-Indep: mkdocs <!nodoc>, ...) and the doc package with Build-Profiles: <!nodoc>. Restriction formulas are evaluated against the enabled build profiles (Policy 7.1.1.2, 5.6.35), and dpkg-buildpackage(1) sets only DEB_BUILD_PROFILES for -P nodoc/DEB_BUILD_PROFILES; Dpkg::BuildProfiles::set_build_profiles() writes only DEB_BUILD_PROFILES, and debhelper never writes DEB_BUILD_OPTIONS (no assignment anywhere under /usr/share/perl5/Debian/Debhelper).
• Problem: With the nodoc build profile active - dpkg-buildpackage -P nodoc, or the profile job the package's own debian/salsa-ci.yml enables (test-build-profiles with BUILD_PROFILES: nodoc) - mkdocs is not installed because of <!nodoc> and pydantic-handlebars-doc is not built, yet the guard does not fire (nodoc is not in DEB_BUILD_OPTIONS), so mkdocs build runs and the build fails. The guard only covers the DEB_BUILD_OPTIONS=nodoc case (also a standard tag, Policy 4.9.1), which is precisely the case in which mkdocs is installed.
• Fix: Guard on the profile as well, e.g. ifneq (,$(filter nodoc,$(DEB_BUILD_PROFILES) $(DEB_BUILD_OPTIONS))) for both blocks, or drop Build-Profiles: <!nodoc>/the <!nodoc> markers if only the DEB_BUILD_OPTIONS tag is meant to be supported.

3. [minor] [packaging] the mkdocs output directory build/ is never cleaned

• Files: debian/rules:10
• Basis: checked, in the package or with a reference tool
• Evidence: mkdocs build -d $(CURDIR)/build/html -f $(CURDIR)/mkdocs.yml writes into the source tree; debian/rules has no override_dh_auto_clean and there is no debian/clean file. dh_clean only removes debian/tmp, debian/files, the substvars/log files and what debian/clean lists.
• Problem: A build leaves build/html behind, and debian/rules clean does not remove it, so the tree is left dirty; a dpkg-buildpackage run that also produces the source package (the default) then works from a tree containing generated files.
• Fix: Add build/ (or build/html) to a new debian/clean file.

4. [minor] [packaging] the sitemap.xml.gz deletion in debian/rules does not reach the installed documentation

• Files: debian/rules:16
• Basis: checked, in the package or with a reference tool
• Evidence: find -type f -name "sitemap.xml.gz" -delete runs in execute_after_dh_installdocs from the source root (find with no path starts at .), i.e. after dh_installdocs has already copied build/html (debian/pydantic-handlebars-doc.docs) to debian/pydantic-handlebars-doc/usr/share/doc/pydantic-handlebars-doc/html.
• Problem: It deletes only the copy in the source tree, so pydantic-handlebars-doc still ships build/html/sitemap.xml.gz; if the intention was to keep that file out of the package the deletion does not do it (and it leaves build/html half-deleted in the source tree).
• Fix: Delete it from the installed copy instead, e.g. find debian/pydantic-handlebars-doc/usr/share/doc/pydantic-handlebars-doc -name 'sitemap.xml.gz' -delete, or drop the line if it is not needed.

Verified

• Read every file of debian/ in full: changelog, control, rules, copyright, source/format, gbp.conf, salsa-ci.yml, pybuild.testfiles, pydantic-handlebars-doc.docs, pydantic-handlebars-doc.doc-base, upstream/metadata, patches/series and both patches (debian/watch looked at only by name; not reviewed).
• The pre-review scan listed no files: its author check found every holder in the tree named in debian/copyright, which matches what I found - the only holder is Pydantic Services Inc. (LICENSE, pyproject.toml authors), plus the packager for debian/*.
• Inventoried the tree (top level, src/pydantic_handlebars/, tests/, docs/, .github/) and compared it with the master list of pydantic-handlebars_0.2.1.orig.tar.gz: the tree is upstream's files plus debian/, nothing was dropped, so no Files-Excluded is needed.
• The only licence text in the tree is LICENSE and debian/copyright; no file carries another licence, and no built/binary file, archive, font, image, .so/.jar/.class/.pyc, minified JS/CSS or vendored copy exists anywhere (glob for those extensions found nothing). uv.lock and .python-version are upstream text files, not build products.
• debian/copyright is machine-readable DEP-5 (so no replacement is proposed); the Expat short name matches the licence text, Files: * matches LICENSE and pyproject's license = 'MIT', and Files: debian/* covers the packaging and both patches.
• All dependency names exist in the archive (apt-cache): debhelper-compat 14, dh-sequence-python3, pybuild-plugin-pyproject, python3-all, python3-hatchling, and mkdocs / mkdocs-material / mkdocstrings / mkdocstrings-python-handlers / python3-hypothesis / python3-pydantic / python3-pytest / python3-pytest-examples / python3-pytest-xdist.
• dh_mkdocs is shipped by the mkdocs package (which Provides: dh-sequence-mkdocs), so Build-Depends-Indep: mkdocs <!nodoc> brings the helper debian/rules calls; -T mkdocs-material is needed to symlink the theme's static files, and dh_mkdocs' mkdocs:Depends substvar is added to the -doc package by dh_gencontrol at compat 14, so the missing Depends field there is correct.
• pydantic -> python3-pydantic is in dh-python's dist/cpython3_fallback map, so ${python3:Depends} from the wheel's Requires-Dist is right; python3-pytest in Build-Depends makes pybuild pass --test-pytest (checked in Buildsystem/pybuild.pm), so the tests do run at build time.
• Standards-Version 4.7.4 is current against Policy 4.7.4.1 (policy tool); changelog is 0.2.1-1, unstable, matches the orig tarball version, and closes #1150536.
• Testsuite: autopkgtest-pkg-pybuild is a real runner (autodep8's support/pybuild generator runs pybuild-autopkgtest with @builddeps@); debian/pybuild.testfiles (tests, docs, README.md) is exactly what test_docs.py needs, and no doc example imports anything beyond pydantic_handlebars, pydantic and the stdlib.
• Both patches are DEP-3 with From/Date/Subject/Forwarded and match the tree: fix_mkdocs_config.patch adds paths: [src], font: false and use_directory_urls: false to mkdocs.yml (the last makes doc-base's flat html/index.html correct), and skip_ruff_based_unit_tests.patch skips only the ruff-version-specific test_docs_lint.
• The doc package's doc-base file uses Section: Programming/Python, a valid doc-base section (compare the installed /usr/share/doc-base/python3-passlib.python3-passlib-documentation), and its Index/Files paths are the ones dh_installdocs produces from build/html (dh_installdocs keeps the directory's basename).
• debian/pybuild.testfiles overrides pybuild's default copy list, so pyproject.toml (and with it [tool.pytest.ini_options]: xfail_strict, filterwarnings=error) is not present in the build directory during the test step; the tests still run, only upstream's pytest settings are not applied - noted, not raised as an issue.
• uscan found the packaged version as the newest upstream release (upstream 0.2.1, packaged 0.2.1).

Not confirmed

• How the package's own Salsa CI profile job activates the profile (the pipeline is fetched from a URL I cannot read): if it passes nodoc as a build profile the build fails as described in the debian/rules issue; if it were passed as DEB_BUILD_OPTIONS the guard would fire. The issue's claim holds for any dpkg-buildpackage -P nodoc build.
• Whether upstream's repository (or the ftp-master reviewers) treats the ported test modules as derivative works of handlebars.js; the metadata I could check (the porting docstrings, handlebars.js's own package.json licence) is as given in the issue.

Proposed changes

None.