Howdy Klaus, Thank you for working on this package.
Here are some comments I have for improving the packaging work: * When removing code, just remove it. You are tracking the work in a VCS, there is generally no reason to commit changes that comments out lines of code. So, in ‘debian/patches/’, the ‘0001-Remove-check-for-python-version.patch’ and ‘0003-Patch-sphinx-config-to-avoid-network-access-and-add-.patch’ changes (actually, the Git commits you used to generate those files) should not comment any code lines but instead remove those lines. * Wow, hard-coding a man page in a Python string literal is a fragile way to store the document. Have you discussed with upstream the feasibility of moving those to their own first-class source documents, and reading from there at run time? Python ‘pkg_resources’ has functionality to locate and read a file installed as part of the package. * In ‘debian/copyright’, please don't obfuscate the email addresses of copyright holders. It's a needless barrier to getting useable contact information for legal purposes. * Is there a good reason to omit the “Upstream-Maintainer” field in the header of the ‘debian-copyright’ file? There seems to be an obvious single maintainer contact for this code base. * The ‘cf/etc/udunits/’ tree looks like a bundled third-party work. Per Debian Policy §4.13, should this work not be packaged separately and listed as a dependency? * Can you include a ‘debian/README.source’ explaining how you collated the various parts and changes you've made from the upstream source? In particular, the procedure for making ‘debian/*.1’ and ‘debian/test_file.nc’ should be described, along with rationales that can be later re-visited if upstream policies change. -- \ `\ _o__) Ben Finney <bign...@debian.org>