Hi Jeroen, Thanks a lot for taking the time to review the package.
I have cleaned up the repository branches and removed the redundant debian/sid branch. I also removed the redundant [import-orig] section from debian/gbp.conf, updated the Standards-Version, and enabled autopkgtest-pkg-pybuild with the required pytest dependencies. The manpage installation issue has also been corrected. The Cargo handling was redesigned to avoid maintaining a large Debian-specific replacement for the upstream Cargo.lock. The upstream lockfile is kept unchanged in the source tree. During the Debian build, cargo prepare-debian populates a local registry from the crates packaged by Debian; the upstream lockfile is temporarily saved, and a new lockfile is generated offline from that Debian registry. The original lockfile is restored during cleanup, so the source package does not accumulate generated lockfile changes. The remaining Debian Cargo patch only adjusts dependency requirements in Cargo.toml to versions currently available in Debian, such as glam, rstar, rand, strum, svgtypes, and pyo3-stub-gen. This allows Cargo to resolve against Debian’s packaged crates without replacing the complete upstream lockfile or manually maintaining checksums for every dependency. A separate patch handles the Rust API compatibility adjustments needed for the Debian crate versions. Regarding the licensing issue: I agree that upstream should ship the complete MIT licence text in the source tarball. Debian currently provides the licence text in debian/copyright, but I will report this upstream and ask them to add or restore the missing licence file in future releases. The remaining CI issue was a BLHC false positive caused by Rust-only build output, while the actual rustc commands contain the expected Debian hardening flags. This has been handled with narrowly scoped BLHC ignores for the affected Rust crate lines. Cheers Mike Michele Cane, PhD On Monday, 31 August 2026 at 17:49, Jeroen Ploemen <[email protected]> wrote: > 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 >
publickey - [email protected] - 0xC017295D.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
