hi Mike, I took a look at the python-raygeo package, up for sponsorship in the Python team:
For starters, the repository itself is in need of a cleanup: * the pristine-tar branch is stale, and also contains unrelated (upstream?) git commits and files that have nothing to do with pristine-tar. * the upstream branch is stale. * the debian/master branch seems to hold the most recent packaging updates but there's also a debian/sid branch. To avoid confusion, please get rid of whichever is not used anymore. For the remainder of this review, I'm assuming debian/master is the packaging branch. Then for the packaging: * copyright: not your fault, but it looks like upstream breaks the terms of the license they chose for their own project. "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software", but the license text is missing from the tarball. I'm not entirely sure what the FTP Masters will make of that, given that strictly speaking the license text now *is* included (in d/copyright, but still). * d/gbp.conf: do you need the [import-orig] section at all? The only setting is a duplicate of what's already under DEFAULT. * rules: no need to override dh_clean, just list the file in d/clean. * d/salsa-ci.yml: why is the BLHC check disabled? * lintian: W: python3-raygeo: no-manual-page [usr/bin/raygeo-docs] W: python3-raygeo: no-manual-page [usr/bin/raygeo] I: python-raygeo source: out-of-date-standards-version 4.7.2 (released 2025-02-27) (current is 4.7.4) * autopkgtest: the package nicely runs the upstream testsuite on build, but uses only the trivial autodep8 import check as its autopkgtest. Consider putting the upstream testsuite to good use in an autopkgtest context as well, for example via 'Testsuite: autopkgtest-pkg-pybuild' or a custom script, if necessary. * patches: I'm not familiar at all with the best practices for rust/cargo packaging, but couldn't help but wonder if it would be possible to actually loosen versions in cargo.lock rather than replace each with some other equally specific version. The current patchset also removes checksums for some dependencies, while updating others. That approach seems to set the package up for a lot of future maintenance work, since AFAICT even minor versions bump of rust build-deps could trigger failures. Any way to deal with this in a more flexible way and/or automate refreshing the cargo.lock file based on whatever Debian provides, maybe along the lines of [1]? In that same package, also note the patches dealing with the versioning in the lock file are split up per build-dep and mostly set ranges of acceptable versions. Anyone with more rust experience, feel free to chime in. [1]https://salsa.debian.org/python-team/packages/maturin/-/blob/d1326d41a1a0ed0f0e27e19f7b1fb5f8d025d57f/debian/rules
pgpp6KLE7Vpvk.pgp
Description: OpenPGP digital signature
