Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely
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).
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).
d/control
=========
duplicate-short-description liblgpio-dev liblgpio1 python3-lgpio
Fixed.
python3-rgpio: package-contains-no-arch-dependent-files
Ah 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.
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?
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?
symbols
=======
symbols-file-missing-build-depends-package-field liblgpio.so.1 librgpio.so.1
Fixed.
Thanks for the review,
Dave Jones.
Reply to: