Hi Dave, On 15.11.21 13:19, Dave Jones wrote:
Hi Bastian, On Sun, Nov 14, 2021 at 01:58:54AM +0100, Bastian Germann wrote:On Mon, 1 Nov 2021 14:43:14 +0000 Dave Jones wrote:Filed bug #998243 against wnpp, and took the opportunity to bump the packaging to 0.2.0.0 while doing so; packaging is updated on salsa, and the source package is also uploaded to mentors.d/watch ======= debian-watch-file-is-missing This is very important when you have several packages to maintain. It keeps track of new releases.Unfortunately in this case, upstream's form of distribution doesn't work with Debian's uscan tooling. Specifically, they distribute their various libraries and tools (including lg) as a zip file named after the project without a version component. The version component is stored as an empty file within the root of the zip file.In other words, it's not possible (or more accurately I couldn't work out how) to get uscan to determine a new version is available and download it.However, I agree entirely that this is an important piece of tooling for any maintainer, hence my inclusion of a simple "get-orig-source" script in the debian/ directory (also referenced as the "get-orig-source" target of d/rules) which does the equivalent job to uscan in this case (downloads the appropriate zip archive from upstream, checks if it matches the present one, and calls mk-origtargz on the result as necessary).
I just checked http://abyz.me.uk/lg/lg.zip against the GitHub releases/tags provided archive. They are not bit-by bit identical but contain the same source. As .zip cannot be used as an orig tarball directly, it is actually preferrable in this case not to get the author-uploaded zip but to use the GitHub tar.gz archive.
You can use one of uscan's versionmangle options to add the .0.0 but in my opinion you can also just go with the GitHub tag version. So, please replace your get-orig-source script by d/watch.
Actually, you are already claiming in d/copyright that Source is https://github.com/joan2937/lg.
d/copyright =========== Please consider relicensing debian/* or at least debian/patches/* to the Unlicense as well.The effective license of your patched package is GPL-3+ now, given that your patches are actually copyrightable. Also, upstream would not take your patches.Good point -- certainly happy to relicense the debian/* bits as Unlicense (I was surprised to learn that on Debian SQLite, a famously public domain piece of software, is likewise GPL licensed as a result of this).Please rename what is now called public-domain to Unlicense.Fixed (though I'm slightly dis-heartened that unlicensed stuff can't be trivially labelled public-domain).
On reading the license text you will find out that there are jurisdictions that do not have a concept of explicitly putting a work into the public domain. It is not equivalent in those jurisdictions.
d/control ========= duplicate-short-description liblgpio-dev liblgpio1 python3-lgpioFixed.python3-rgpio: package-contains-no-arch-dependent-filesAh yes, the rgpio Python bit should indeed be "all". Fixing that caused a "not-binnmuable-all-depends-any" tag to pop up in lintian, which is something new to me (and led to some "what is binnmu?" googling). I *appear* to have fixed that by cargo-culting the tag's recommendation to change the dependency to >= source:Version but I wonder if there's some subtlety I'm missing. Would be grateful if you (or anyone) could verify this is indeed correct now.
This is okay in this case. One can upload rebuilds of binary packages which are not arch=all. The version changes in this case. An all package depending on that would then not install anymore.
d/changelog =========== Why are the .0.0 in your upstream version? I see 0.2 on GitHub.The GitHub repo doesn't have the definitive list of versions (e.g. 0.1.6.1 and 0.1.7.0, which were released, are missing); the author's versioning scheme (within the source archive) always includes four components, so I assumed the upstream component of the debian version number should do likewise?
As I said, I am fine with both options (two or four components). For versions that end on something != .0.0, you can still extend to four components.
Though, in light of the "not-binnmuable-all-depends-any" tag I encountered above, I wonder if they should be left off to permit a stronger Depends line for python3-rgpio?
One is independent of the other.
symbols ======= symbols-file-missing-build-depends-package-field liblgpio.so.1 librgpio.so.1Fixed.
Thanks, Bastian