Dear mentors,

I am looking for a sponsor for my package "python-petl":

  * Package name     : python-petl
    Version          : 1.7.23-1
    Upstream contact : petl developers <python-etl@googlegroups.com>
  * URL              : https://github.com/petl-developers/petl
  * License          : Expat
  * Vcs              :
https://salsa.debian.org/python-team/packages/python-petl
    Section          : python

The source builds the following binary packages:

   python3-petl - Python Extract Transform and Load Tables of Data

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/python-petl/

Alternatively, you can download the package with 'dget' using this command:

   dget -x
https://mentors.debian.net/debian/pool/main/p/python-petl/python-petl_1.7.23-1.dsc

Changes since the last upload:

  python-petl (1.7.23-1) UNRELEASED; urgency=medium
  .
    * New maintainer. (Closes: #1142617: ITA: python-petl -- Extracting,
      transforming and loading)
    * debian/copyright: add year range, change license string to Expat
    * Add self to debian/copyright, as uploader in debian/control
    * Add Salsa CI
    * Add debian/upstream/metadata, upstream contact, fix description
    * New upstream release.

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
dustin.kost@gmail.com

Can you please publish the prompt(s)?

Hi Dustin,

Thanks for the review.

 > debian/changelog has UNRELEASED as the distribution:

This was intentional, as documented here:
https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst?ref_type=heads&plain=1#L85.

I'm actually unsure at what point I should update the distribution to
'unstable'. I was hoping that when a sponsor reviews and is happy with
the changes, that they would ask me to go ahead and change it to
'unstable' right before they upload it.

For the rest of the reviews - I have noticed the lintian warnings and
haven't investigated the Python test failures (thanks for your findings,
btw), but decided to leave them as-is since, as you mentioned, they
exist in 1.7.20-1. Since this is my first-ever package, I wanted to
focus on getting the experience and confidence of building a package,
familiarizing myself with the workflow, then getting a sponsorship. I
hoped the bare-minimum changes (as you can tell, mostly
housekeeping-related :)) with an ITA would be acceptable.

Thanks again.

(sorry for the double emails I did a reply not a reply all earlier)

Hey Andrey,

Yes I am a real human :)

It's not so much as a prompt as it is a whole system now:
-Started out as a "How can I help the Debian project?" question
-This led to the WNPP list
-Asked Claude to find "low hanging fruit" packages
-Created a Debian 13 VM specifically for building/packaging (devscripts,
lintian, etc)
-Gave Claude SSH access to the VM to pull packages, build them with sbuild
into a sid/unstable chroot like buildds does, run
lintian/debhelper-compat/autopackagetest, send well formated emails to the
bugs/python team lists (try to keep things in the style and tone of what's
acceptable)
-Anything requiring debsign was manually ran by me after confirming what
was built/going to be uploaded to salsa

Claude was intrumental in navigating the Debian ecosystem: setting up the
testing environment, keyring, salsa access, where/who to contact and what
to send onto the lists.

If you'd like, I can publish the toolchain/process for review.

Thanks,
Dustin

Hi Lester,

You are right about this. Thanks for the correction.

The policy says:

  Packages must use the ``UNRELEASED`` distribution in
  ``debian/changelog`` if the current version in the VCS source has
  not been uploaded yet. Only when a package's new version is about to
  be uploaded should the distribution be changed to ``unstable`` or
  another suitable distribution.

So UNRELEASED is not a mistake, it is what the team requires.

When to flip it: your expectation matches what the policy describes, so
don't change anything preemptively. The only thing I would do is raise
it explicitly when a sponsor picks this up, because the .changes
currently carries Distribution: UNRELEASED and that has to become
unstable before the upload can be accepted. Whether they want you to
flip it and re-upload to mentors, or would rather do it themselves at
upload time, seems to be sponsor preference rather than something the
policy settles.

On the lintian tags and the test failures: leaving them alone is a
defensible call and I would not treat it as a gap. A first upload that
adopts a package and changes as little as possible is easier to review
than one that also rewrites the packaging. The test results are 5
failing out of 578, all one fixture that does not reach the build tree,
but it's pre-existing and not a regression.

Sorry for the noise on your first package. I've just started getting
into Debian packaging as well. The rest of it looked good to me.

Regards,

Dustin Kost
dustin.kost@gmail.com

Control: tags -1 moreinfo

hi Lester,

the Python team doesn't typically use mentors, see team policy. But
now that the RFS is there anyway, my review:

* changelog: no need to repeat the bug title or summary when closing
  a bug, just the bug number will do.

* copyright: missing entry for:
  petl/io/xlutils_view.py:2:# Copyright (c) 2013 Simplistix Ltd

* control: the short description on the binary package used to
  reference the field in the Source stanza (via Description:
  ${source:Synopsis}), but no longer does. Instead, there are now
  separate description fields (with slightly different content) for
  the source and binary pkg. That duplication doesn't serve a
  purpose, especially for a simple single-binary package.

* rules: [already fixed in git] no tests were run on build at all,
  although the upstream testsuite can be successfully run with only
  minor packaging tweaks.

* control: I suspect more build-deps could be marked '<!nocheck>'?

* the upstream testsuite get installed into the binary package, is
  that intentional? Is it used somehow by a reverse dependency?


Please remove the moreinfo tag (and CC me) once you have an updated
package ready.

Hi Jeroen,

Thanks for the review.

Updated d/changelog.

Updated d/copyright.

Updated d/control, which restores the lines to when before I took over.

Thank you.

I marked more packages with nocheck.

I have excluded them in the binary package.

Done, I have also updated the package to 1.7.24.

Thanks!

Package uploaded.