Control: tags -1 moreinfo Control: owner -1 ! Hi Michael,
(@Jan: would be nice if you could chimein in regards to this RFS) On Tue, May 03, 2022 at 12:28:39PM +0200, Michal Sojka wrote: > Hi Tino, > > thanks for the feedback. > > > the package triggers several lintian warnings. I guess most of them were > > already present in old version. But at least the > > package-contains-no-arch-dependent-files warning for the new usbrelayd > > package can be trivially fixed by setting its arch to "all" instead of > > "any". > > I've removed the package-contains-no-arch-dependent-files warning and > reuploaded (https://mentors.debian.net/package/usbrelay/). I'm a bit > confused that when I run lintian locally, I get less warnings that what > is shown in mentors.debian.net. Are there some switches that I need to > run lintian with to see all relevant warnings? > > I'm also not sure about NMU warnings. Shall I mention NMU in the > changelog or it will be done by the one who will really upload the > package? no, the sponsor usually does not modfify the package. Regarding the NMU, see below, as our mails crossed... > Best regards, > -Michal Hi Michael, On Mon, May 02, 2022 at 09:44:59PM +0200, Michal Sojka wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for package "usbrelay": > > * Package name : usbrelay > Version : 1.0-1 > Upstream Author : Darryl Bond <darryl.b...@gmail.com> > * URL : https://github.com/darrylb123/usbrelay > * License : GPL-2+, CC-BY-SA-4.0 > * Vcs : https://salsa.debian.org/wentasah/usbrelay > Section : electronics > > > The package is officially maintained by DD Jan Dittberner, but he seems > to be no longer active, at least with this package. I contribute to the > development of the upstream package and from time to time, users report > problems that are caused by too old version of the package in the Debian > archive. Having more recent version in Debian would be beneficial. unfortunatly those bugs were not reported in the Debian bug tracker... Some thoughts about procedures: Jan is generally active (uploaded a package last month), but is in the LowNMU list [1] and the package is in the salsa Debian group [2]. Using the "LowNMU" procedure means that your package needs to be a NMU [3], but an NMU requires that the upload fixes bugs reported in the Debian BTS and a NMU limits the changes you are allowed to do in a package. You can of course file the bugs you fix in your changes in the Debian BTS (including a "please package the new upstream version where you can list all the problems with the old version.), but some changes will still be out of scope for an NMU. The salsa Debian group is technically a Team upload [4] and team-uploads do not have restrictions on what to upload, so I guess this is an viable approach. The third option is to adopt the package -- either by an explicit OK to do from Jan or via the ITS procedure [5]. With that, you will become (co-)maintainer of the package, but that implies some kind of promise to also look after the package in the future. This is of course the best outcome for Debian and your project, but also means a commitment in maintaing the package. [1] https://wiki.debian.org/LowThresholdNmu [2] https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#collaborative-maint␆bib [3] https://wiki.debian.org/NonMaintainerUpload https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus [4] https://wiki.debian.org/TeamUpload [5] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging https://wiki.debian.org/PackageSalvaging (The "conservative" criterias are imho fulfilled: -::q open bugs, missing upstream releases, sourceful upload required, no visible activity on the package >6months) > The updated package is based on the version already in Debian and > introduces two additional binary packages to cover new functionality > provided by upstream. I tried to prepare the updated package as well as > I can, but this is my first attempt to prepare official Debian packaging > so I'm open to suggestions for improvement. The packaging is inspired by > official documentation as well as by Fedora packaging, which was created > recently by other contributors. > > The source builds the following binary packages: > > usbrelay - USB HID relay driver > python3-usbrelay - Python bindings for USB HID relay driver > usbrelayd - MQTT client for USB HID relay driver > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/usbrelay/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/u/usbrelay/usbrelay_1.0-1.dsc > > Changes since the last upload: > > usbrelay (1.0-1) unstable; urgency=medium > . > * New upstream version 1.0 > * Drop "v" prefix from the watch file > * Drop 0001-make-CFLAGS-LDFLAGS-and-CPPFLAGS-customizable.patch > * Update gcc9.patch (Closes: Bug#916557) > * Pass Debian package version to the build system > * Use upstream man page rather than Debian one > * Override lintian soname error > * Add python3-usbrelay package > * Add usbrelayd package providing interface to MQTT > * Update udev rules > * Bump debhelper compatibility to 13 (no changes) > * Bump Standards-Version to 4.6.0 (no changes) > * Update copyright information > * Announce the hardware support using AppStream > * Add usbrelayd(8) manpage > * Fix spelling error > > Additional comments can be found in some commit messages at > https://salsa.debian.org/wentasah/usbrelay/-/commits/master. Ok, let me check the package: (I'm using the mentors version for the review) - As said earlier, depending if you want a Team upload or follow the ITS, this needs some entry in d/changelog, depending how you want to proceed... - debian/io.github.darrylb123.usbrelay.metainfo.xml should possible brought upstream, shouldn't it (no need to change for the upload, but I guess this is not debian specific) - d/rules - triggers https://lintian.debian.org/tags/debian-rules-parses-dpkg-parsechangelog, you should do as lintian recommends. - (bikeshed -- no need to change) I'd prefer to use d/clean instead of overriding the clean target; overrides are harder to maintain :) - the man page is still in the debian directory -- it can be deleted as it is now part of upstream. - same for the udev rules. - d/usbrelay.install has a hard-coded architecture-dependent path. That will break build on archs != amd64. - d/postinst (and postrm): The username is not correct. According to Debian Policy, 4.9.1, it must start with an "_" I guess also that you don't want/need a homedirectory for that uses, so its $HOME should be /nonexistent in this case. (Policy 9.2.3) HOWEVER, let me suggest something else: Use the DynamicUser feature from systemd: DynamicUser=yes SupplementaryGroups=plugdev in the service file should make postint/postrm no longer be needed. - Lintian has a few remarks: (my related remarks in brackets) W: usbrelay source: no-nmu-in-changelog W: usbrelay source: source-nmu-has-incorrect-version-number 1.0-1 (will be gone once the changelog mentions the team upload or after the salvage procedure is done) I: usbrelay source: debian-rules-parses-dpkg-parsechangelog (line 20) (see abovr) I: usbrelay source: older-debian-watch-file-standard 3 (could be updated to version 4, just s/3/4/ in the header) I: usbrelayd: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/usbrelayd.service (can be ignored) I: usbrelay source: patch-not-forwarded-upstream debian/patches/0002-Mention-README-in-the-man-page.patch I: usbrelay source: patch-not-forwarded-upstream debian/patches/gcc9.patch (see below) I: usbrelayd: systemd-service-file-missing-documentation-key [lib/systemd/system/usbrelayd.service] (possibly ask upstream to ammend the service file accordingly) X: usbrelay source: debian-watch-does-not-check-gpg-signature [debian/watch] (it would be nice if upstream could pgp-sign their tarballs, so noone can tamper with them. They sign their commits already, so a key would be available. Not required for this upload.) P: usbrelay source: maintainer-manual-page debian/usbrelayd.8 (see above -- deletign the file will fix this.) X: usbrelay source: prefer-uscan-symlink filenamemangle s/.*(\d[\d\.]*)\.tar\.gz/usbrelay-$1.tar.gz/ [debian/watch:3] (ignore that) P: usbrelay source: silent-on-rules-requiring-root [debian/control] (Add "Rules-Requires-Root: no" to d/control -> https://lintian.debian.org/tags/silent-on-rules-requiring-root) X: usbrelayd: systemd-service-file-missing-hardening-features [lib/systemd/system/usbrelayd.service] (DynamicUser=yes should fix that too) X: usbrelay source: upstream-metadata-file-is-missing (would be nice to have, but not required: https://wiki.debian.org/UpstreamMetadata example: https://salsa.debian.org/games-team/darkradiant/-/blob/master/debian/upstream/metadata You have mentioned that you are involved with upstream: In this case, can you check if the debian/patches can be brought upstream? I don't think they are to be Debian specific, especially the gcc-9 patch. (no need to do that for this upload, but if you forward them now, please add the dep3-Tag "Forwarded" to the d/patch) Overall, package quality is nice, only a few things to fix before this can be uploaded. > Regards, > -- > Michal Sojka > >
