Review of package dunamai
Hello!
It seems you're a DD! Sorry, it took me a bit to realise this... No need
for me to sponsor anything then!!
As promised, here's the review for the dunamai package.
> I guess it's time to move/re-create/import the repo to
> python-team/packages alongside other python packages, right?
Yes, the first step if you want the package to be part of the Debian
Python Team is to upload it to Salsa in
https://salsa.debian.org/groups/python-team/packages, following the
proper branch structure described in the team's policy.
As for the current branches, I see you've built the package on a git
import instead of a tarball (meaning you have upstream commits in the
upstream and debian/foo branches). This is not typically what is done in
the Team.
As such, the Team's policy says:
"DPT requires a pristine-tar branch, and only upstream tarballs can be
used to advance the upstream branch. Complete upstream Git history
should be avoided in the upstream branch."
> What is the preferred repo name? I went with dunamai, but some
> packages use python-dunamai
Typically, if it's a library, it's a good idea to have the source
package start by "python-". If you are packaging something that is
primarily an application (say, supysonic), you can omit it.
In your case, dunamai is both a CLI tool and a library. In this case,
I'd strongly recommend going with "python-dunamai" for the source
package and "python3-dunamai" for the binary package.
> I currently maintain the package in debian/experimental branch. Would
> you recommend going through experimental with dunamai /
> poetry-dynamic-versioning or aim straight for sid in debian/master?
Hmm, whatever? It's really a matter of personal preferences. I tend to
be lazy and not want to build on experimental because the sbuild script
is more tedious... :)
That said, here's the actual review:
1. d/changelog: as per the Team's policy, packages that haven't been
uploaded to the archive should be marked as UNRELEASED instead of
experimental or unstable. This helps us keep track of what's actually
been uploaded when working collaboratively on packages.
2. d/control: you don't need to restrict the python version (">= 3.5")
even if that's something upstream does somewhere.
In fact, you don't even need to specify "python3" at all. See #5.
3. d/control: you can skip the "Python 3" mentions in the description.
python2 is 100% deprecated since Bookworm.
4. d/control: I would strongly encourage you to add "Testsuite:
autopkgtest-pkg-pybuild" to your d/control source statement. This will
run the upstream testsuite as an autopkgtest for you and makes you
package much more robust. (man pybuild-autopkgtest)
5. d/control: In the eternal words of dpkg-gencontrol:
dpkg-gencontrol: warning: package python3-dunamai: substitution variable
${python3:Depends} unused, but is defined
You should add it to your binary dependencies.
6. d/copyright: The "MIT" license tends to be called "Expat" in Debian.
It's a nitpick, but IMO it's enough for some ftp-masters to reject your
upload to NEW. "decopy" identifies the LICENSE file as Expat correctly :)
7. d/metadata: This file tends to be in "debian/upstream/metadata"?
8. d/tests/dunamai: You don't really need to the python import function.
This is trivial, doesn't really do much and if you still want to do
this, I'd recommend using "Testsuite: autopkgtest-pkg-python" in
d/control, as it does this exact thing in a more automated and
streamlined fashion.
9. d/rules: as pointed out by lintian, you're parsing dpkg-changelog
directly.
You can make your life easier by using "source
/usr/share/dpkg/pkg-info.mk" at the top and using variables like
DEB_{SOURCE,VERSION}.
"cat /usr/share/dpkg/pkg-info.mk" will give you the list of variables
you can use and what they are.
In fact, I'm not sure I get why you need this VERSION variable? The
package seems to build fine without it.
10. Your package doesn't actually run tests during build: "Ran 0 tests
in 0.000s". You're missing "python3-pytest" as a build-dependency.
With this dependency, all tests (and not only the unit tests) will be
ran and they'll fail. I don't think you want to run the integration
tests, or at least, this should probably be done in an autopkgtest instead.
You can fix this by adding a "d/pybuild.testsuites" file containing
"tests/unit" to specify what testfiles to add/keep.
(man pybuild for more info)
Cheers, and thanks for contributing to Debian! When you're ready for a
review of poetry-dynamic-versioning, don't hesitate to ping me.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
On 2023-08-01 08 h 18, Jakub Ružička wrote:
Hey,
On 8/1/23 05:02, Louis-Philippe Véronneau wrote:
Hello,
I need poetry-dynamic-versioning for a new version of a package I
maintain and I'll be more than happy to review and sponsor your work
on this.
Bug#1043255: RM: pep517 -- ROM; Obsolete, replaced by python-pyproject-hooks
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Python-pyproject-hooks has replaced pep517, so it should be removed once there are no more reverse Build-Depends. Most packages have been updated and bugs have been filed for the three remaining. Scott K
review for lazy-loader/0.3-1
Hi, I took a look at lazy-loader, up for sponsorship in the Python Team: * copyright: years outdated; * control: long description would benefit from some more details explaining what lazy loader is and does, e.g. a summary of [1]; * control: standards-version is slightly out-of-date; * watch: upstream uses signed tags for releases, please add the upstream key in the packaging and make uscan verify the signature. Since the watch file already uses git mode, you might only have to add the pgpmode=gittag option once the upstream key is in place for verification to work. Please re-add the package to the channel topic on IRC once the above issues have been fixed. [1]https://scientific-python.org/specs/spec-0001/ standards-version pgpMPxVbKJIGb.pgp Description: OpenPGP digital signature
Re: Maintenance of gtts (python3-gtts)
Given the (lack of) maintenance on the package, I am pretty confident we don't have anyone in Debian that really knows it (I am willing to be pleasantly surprised). The gtts upload I did migrated to Testing last night, so I'll leave the rest of it to you. Thanks, Scott K On Monday, August 7, 2023 9:27:05 AM EDT Emmanuel Arias wrote: > Hello Scott, > > I don't use it, but seems an interested project. I can work on it, but > it would be great if you have a maintainer that already know the project. > > Cheers, > Emmanuel > > On Sun, Aug 06, 2023 at 05:23:53PM -0400, Scott Kitterman wrote: > > The gtts package is, at least nominally, maintained by the Debian Python > > Team, but has no human uploader. As a practical matter, I think someone > > should either adopt it (add themselves to uploaders) or we should > > formally orphan the package so we aren't pretending. > > > > It has two rdepends: > > > > Reverse-Depends > > === > > * dialect [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el] > > * mnemosyne > > > > I personally track mnemosyne, even though it's not team maintained, > > because i have an interest in the package. I noticed it was going to be > > removed from Testing because of a FTBFS bug in gtts, so I fixed gtts by > > updating it to the current upstream release. Looking at the upload > > history, it's been this way for awhile. > > > > One consequence of it not being actually maintained is that we released > > bookworm with a non-functional gtts package (see #1030290). If anyone had > > been paying attention to the package, they would have noticed that should > > have been an RC bug (it is now) and it would have either been fixed or > > removed. > > > > The package is now in not awful shape in Unstable (and barring surprises > > Testing later today), but it could still use some work. The major > > immediate task for a potential maintainer would be working with the > > Stable Release Managers to get bookworm fixed. > > > > If you're interested in the package and wiling to watch over it, please > > let me know via email. If I don't hear back, I'll assume no one is > > interested and orphan it in a week or two. > > > > Thanks, > > > > Scott K signature.asc Description: This is a digitally signed message part.
Re: Maintenance of gtts (python3-gtts)
Hello Scott, I don't use it, but seems an interested project. I can work on it, but it would be great if you have a maintainer that already know the project. Cheers, Emmanuel On Sun, Aug 06, 2023 at 05:23:53PM -0400, Scott Kitterman wrote: > The gtts package is, at least nominally, maintained by the Debian Python > Team, > but has no human uploader. As a practical matter, I think someone should > either adopt it (add themselves to uploaders) or we should formally orphan > the > package so we aren't pretending. > > It has two rdepends: > > Reverse-Depends > === > * dialect [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el] > * mnemosyne > > I personally track mnemosyne, even though it's not team maintained, because i > have an interest in the package. I noticed it was going to be removed from > Testing because of a FTBFS bug in gtts, so I fixed gtts by updating it to the > current upstream release. Looking at the upload history, it's been this way > for awhile. > > One consequence of it not being actually maintained is that we released > bookworm with a non-functional gtts package (see #1030290). If anyone had > been paying attention to the package, they would have noticed that should > have > been an RC bug (it is now) and it would have either been fixed or removed. > > The package is now in not awful shape in Unstable (and barring surprises > Testing later today), but it could still use some work. The major immediate > task for a potential maintainer would be working with the Stable Release > Managers to get bookworm fixed. > > If you're interested in the package and wiling to watch over it, please let > me > know via email. If I don't hear back, I'll assume no one is interested and > orphan it in a week or two. > > Thanks, > > Scott K signature.asc Description: PGP signature
