Hi Lester,

I am not a DD and cannot sponsor this, so treat the below as a peer review
rather than anything authoritative. I built and tested the package because I
have been doing similar Python team adoptions and wanted the practice; I hope
it is useful rather than noise.

Summary: the packaging looks good and there is one mechanical blocker that
will stop an upload.

BLOCKER

debian/changelog has UNRELEASED as the distribution:

  python-petl (1.7.23-1) UNRELEASED; urgency=medium

lintian in an unstable chroot makes it an error rather than a warning:

  E: python-petl changes: unreleased-changes
  W: python3-petl: changelog-distribution-does-not-match-changes-file
     unreleased != unstable

ftp-master will reject the upload, so no sponsor can act on it as it stands.
It needs to be "unstable":

  dch --release --distribution unstable

which also refreshes the trailer timestamp.

Worth noting this is not just a stale mentors upload: it is also in git at
de8d9fca5, which is the commit your green pipeline ran on. Salsa CI does not
check the distribution field, so a passing pipeline does not catch it.

WHAT I VERIFIED, ALL GREEN

  * sbuild in a clean sid chroot: builds fine, 2m55s.
  * autopkgtest: PASS on python3.13 and python3.14.
  * uscan: watch file resolves, reports up to date at 1.7.23.
  * 1.7.23 is genuinely the newest upstream on both PyPI and GitHub
    (released 2026-08-05).
  * The binary gets Depends: python3:any as expected. I checked because
    debian/control has no Depends field at all for python3-petl, which looks
    alarming until you confirm dh_python3 injects it - it does, and the
    1.7.20-1 binary currently in the archive is the same.

I also specifically checked whether dropping
0001-Try-to-circumvent-pytest-error.patch broke anything, since the changelog
reason given ("Unnecessary since override_dh_auto_test is used") did not quite
hold up - that override was already present in 1.7.20-1 when the patch was
added, so the patch cannot have been about build-time tests. It turns out the
removal is fine anyway: autopkgtest imports petl cleanly on both interpreters
without it. Upstream appears to have fixed the underlying issue. So: right
call, and I could not break it.

ONE SUGGESTION, ENTIRELY OPTIONAL

override_dh_auto_test: is inherited from 1.7.20-1 rather than something you
introduced, so this is not a criticism of your upload - but the "known broken
tests" turn out to be a much smaller problem than the blanket skip implies. I
removed the override and rebuilt:

  ============ 5 failed, 573 passed, 14 skipped in 6.32s =============

Identical on 3.13 and 3.14. All five failures are in
petl/test/io/test_xlsx.py, and all five are the same thing:

  FileNotFoundError: [Errno 2] No such file or directory:
  '.../.pybuild/cpython3_3.13_petl/build/petl/test/resources/test.xlsx'

petl/test/resources/test.xlsx *is* present in the upstream tarball; it just
does not make it into pybuild's build tree, since the package data is not
declared for the wheel build. So it is a fixture-plumbing problem, not
actually broken code.

Deselecting those five would get you 573 tests running at build time instead
of zero, which is a real improvement for a data-handling library. Something
like:

  T := petl/test/io/test_xlsx.py
  export PYBUILD_TEST_ARGS = \
    --deselect $(T)::test_fromxlsx \
    --deselect $(T)::test_fromxlsx_read_only \
    --deselect $(T)::test_fromxlsx_nosheet \
    --deselect $(T)::test_fromxlsx_range \
    --deselect $(T)::test_fromxlsx_offset

(untested as written - I verified the failure set, not that exact incantation.)

Note test_xlsx.py holds 18 tests and only these 5 fail, so
--ignore=petl/test/io/test_xlsx.py would throw away 13 that pass, and a
-k "not test_fromxlsx" filter risks catching more than intended. Deselecting
by name is worth the extra typing. Getting the resource files into the build
tree would be nicer still, if you want to chase it upstream.

TWO MINOR LINTIAN TAGS

  W: python3-petl: no-manual-page [usr/bin/petl]

The package ships an executable with no manual page. I wrote one recently for
another package by reading its argparse setup rather than its README, which
kept the documented options honest - happy to share the approach if useful.

  P: python-petl source: package-does-not-install-examples [examples/]

Upstream ships examples/ which is not installed. Pedantic-level, take it or
leave it.

Nothing else came up. debian/copyright properly credits Boyuan Yang alongside
yourself, the Uploaders/Maintainer split matches Python team policy,
debhelper-compat 14 and Standards-Version 4.7.4 are current, and the v5 watch
file with the GitHub template is the right modern form.

Fix the distribution field and this looks ready to me.

Regards,

Dustin Kost
[email protected]

Reply via email to