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-dunamaiTypically, 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 ⢿⡄⠘⠷⠚⠋ pollo@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.Great, let's get it done :)I think Dunamai is mostly ready, but I hoped to get it reviewed by someone experienced before proceeding further.Already done, I seem to be able to create new projects in Python Team Salsa here:The first step would be to join the Python Team [1]. Once that is done, either email me or ping me on IRC (pollo) :)[1]: https://deb.li/PyPolicyhttps://salsa.debian.org/groups/python-team/packagesI've updated my dunamai packaging in Salsa to latest 1.18.0, it builds locally and Salsa CI is green as well:https://salsa.debian.org/jruzicka/dunamai/-/pipelinesI guess it's time to move/re-create/import the repo to python-team/packages alongside other python packages, right?What is the preferred repo name? I went with dunamai, but some packages use python-dunamai.I also wonder about package name - it's currently python3-dunamai. But perhaps CLI users would expect just dunamai... Perhaps a "Provides: dunamai"? Could you sum up the policy on this, please?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?This might be my first NEW package introduced to Debian as a DD so guidance is indeed welcome :)Cheers, Jakub Ružička
Attachment:
OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature