[needs-packaging] lg (lgpio, rgpio, rgpiod, rgs)

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

First round of comments from reviewing the package for sponsoring:

Please set up a DEP-14 compliant git repository for packaging or remove the Vcs-* templates from d/control .
The source name lg is beautifully short but I think something longer would be better, like lg-gpio or lgpio-tools.
Please close this LP bug in d/changelog.

Further comments:

Please remove the examples from debian/rules .

Please use an @ubuntu.com email address or set maintainer to Ubuntu Developers <email address hidden> to avoid:

dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 255

Otherwise the package looks good and will happily sponsor it after the comments are resolved.

All review points, except one discussed below, now addressed in the new PPA upload (0.1.6.1-0ubuntu1~ppa4) at:

  https://launchpad.net/~waveform/+archive/ubuntu/lg

> The source name lg is beautifully short but I think something longer would be better, like lg-gpio or lgpio-tools.

lg-gpio would probably be okay: it's the "lg" project and it's all about gpio stuff, but I don't think lgpio-tools works (given there's no lgpio-tools package, but it probably should produce an rpgio-tools package).

On the subject of renaming, there's possibly one other bit that might need a rename too. Just to give some quick context, there's three sides to the packages produced by this project:

* liblgpio1, liblgpio-dev, python3-lgpio - A library (and Python 3 bindings) for controlling GPIO pins locally (hence lgpio=local gpio)

* librgpio1, librgpio-dev, python3-rgpio - A library (and Python 3 bindings) for controlling GPIO pins remotely via...

* rgpiod, rgs - A daemon which uses liblgpio to control the local GPIO pins in response to TCP socket requests from librgpio, plus a shell client for this daemon (rgs)

Would it perhaps be wise to rename the "rgs" package (which is also rather short) to "rgpio-tools"?

Renamed packages uploaded to https://launchpad.net/~waveform/+archive/ubuntu/lg/+packages though it seems the amd64 builders are a bit backed up at the moment.

Thanks, uploaded!

Ok, performed a NEW review. There's only one thing I asked Dave to address before accepting:

 * I was discussing this with Dave already, but since there's a new user added during rgpiod installation, I feel that it might be good to remove it during package purge as well (as Dave mentioned, this is the case for packages like sssd). Dave had valid doubts if leaving files (that might be created by rgpiod) with non-existent ownership is nice, but I think the other choice is better. Since yeah, we can't really guarantee we'll handle all the weird stuff the package does during runtime, but maybe we should make sure that at least everything the package system installs is also removed - even if there would be leftover files with a non-existing ownership.

Some other stuff, even more minor, to be considered for some future version of the package (non-blocking):

 * Adding the legacy get-orig-tarball target to debian/rules. It has been obsoleted by debian/watch, but here, since the upstream prepares releases in a very specific way, we can't really use that. Dave prepared a get-orig-tarball script for that, which is good, but I think it would be nice to at least add this legacy target as a fallback for people unable to use uscan.
 * Some of the /etc/ content removal in the .postrm script seems redundant, since dpkg should handle proper conffile removal by itself on purge. Might be good to take a look and see if maybe adding /etc/rgpiod/ to .dirs will help by dpkg handling the removals on its own? Something to look into!

Otherwise I think this is good to go. I can pull the updated package from the PPA directly.

Ok, I see the issues have been addressed - I'll re-upload, re-review and accept.