Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver
Control: owner -1 ja...@debian.org On Thu, May 05, 2022 at 07:54:12AM +0200, Michal Sojka wrote: > On Thu, May 05 2022, Tobias Frost wrote: > > I've just gave you access rights to the repo on salsa, you should be able to > > commit directly. > > For the review and upload, an git reference or mentors upload will works > > both > > for me. > > [...] > > > ✔. You can remove the "moreinfo" tag on this bug to signal that it is ready. > > Thanks Tobias. Yesterday, Jan offered me off-list to review and possibly > upload the package, so I'll work with him and announce the result here. That's great news! (I'm setting the owner of this RFS bug to Jan then, so that $sponors will see it is worked on.) > -Michal
Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver
On Thu, May 05 2022, Tobias Frost wrote: > I've just gave you access rights to the repo on salsa, you should be able to > commit directly. > For the review and upload, an git reference or mentors upload will works both > for me. [...] > ✔. You can remove the "moreinfo" tag on this bug to signal that it is ready. Thanks Tobias. Yesterday, Jan offered me off-list to review and possibly upload the package, so I'll work with him and announce the result here. -Michal
Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver
On Wed, May 04, 2022 at 01:27:23AM +0200, Michal Sojka wrote: > Hi Jan and Tobias, > > @Jan good to hear from you. > @Tobias, thanks for useful suggestions, see my reactions below. > > On Tue, May 03 2022, Jan Dittberner wrote: > > As you might have guessed I'm busier than I would like and do usually need a > > bit of time to respond. > > > > It would have been a good idea to contact me directly or via a wishlist bug > > requesting a package update. I would have answered a wishlist bug > > requesting an usbrelay upstream version update. The RFS came a bit > > surprisingly. A short mail before starting the work would have been nice. I > > had contact with Darryl Bond in the past and responded to his > > requests. > > I apologize for not contacting you. I'm also in contact with Darryl Bond > and I understood that he tried to contact you recently, but without > success. It might have been my misunderstanding. > > > I would be happy to have a co-maintainer for usbrelay. @Michal you may add > > yourself to Uploaders if you are interested in taking care of the package in > > the future. > > Yes, I'll add myself. I'm using this software quite extensively and will > be happy to help with packaging. \o/ > @Jan How shall I proceed now? I've implemented the changes suggested by > Tobias, but I need to test the result again with the hardware, for which > I'll need a day or two. What then? Shall I upload a new version to > mentors.d.o or send salsa merge request or both? I've just gave you access rights to the repo on salsa, you should be able to commit directly. For the review and upload, an git reference or mentors upload will works both for me. > > Please run lintian with the flags -i -v -E --pedantic to get the maximum > > output. I recommend using pbuilder or sbuild to build in a clean > > environment. I usually use sbuild in combination with git-buildpackage to do > > my package builds. Both sbuild and pbuilder can lintian automatically after > > a finished package build. > > Thanks. > > On Tue, May 03 2022, Tobias Frost wrote: > > 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) > > I'll send that (as well as other parts) upstream. I first wanted to know > what changes are required for Debian and then send the final version > upstream. > > > - d/rules > >- (bikeshed -- no need to change) I'd prefer to use d/clean instead of > > overriding the clean target; overrides are harder to maintain :) > > I didn't notice this possibility - it's definitely nicer! > > > - the man page is still in the debian directory -- it can be deleted as > > it is now part of upstream. > > Upstream has usbrelay.1, I've added usbrelayd.8. As mentioned above, > I'll send it upstream later. ok, I've missed that little detail that those are different manpages.. Sorry for the noise. > > - same for the udev rules. > > Upstream rules are slightly different - looser permissions, different group. Ok, that created my confusion... For conciseness, I'd recommend to patch the file instead of having a copy. > > - d/usbrelay.install has a hard-coded architecture-dependent path. That > > will break build on > > archs != amd64. > > Good catch. > > > - 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. > > That's definitely a good thing. > > > - 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) > > done > > > 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 > >
Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver
Hi Jan and Tobias, @Jan good to hear from you. @Tobias, thanks for useful suggestions, see my reactions below. On Tue, May 03 2022, Jan Dittberner wrote: > As you might have guessed I'm busier than I would like and do usually need a > bit of time to respond. > > It would have been a good idea to contact me directly or via a wishlist bug > requesting a package update. I would have answered a wishlist bug > requesting an usbrelay upstream version update. The RFS came a bit > surprisingly. A short mail before starting the work would have been nice. I > had contact with Darryl Bond in the past and responded to his > requests. I apologize for not contacting you. I'm also in contact with Darryl Bond and I understood that he tried to contact you recently, but without success. It might have been my misunderstanding. > I would be happy to have a co-maintainer for usbrelay. @Michal you may add > yourself to Uploaders if you are interested in taking care of the package in > the future. Yes, I'll add myself. I'm using this software quite extensively and will be happy to help with packaging. @Jan How shall I proceed now? I've implemented the changes suggested by Tobias, but I need to test the result again with the hardware, for which I'll need a day or two. What then? Shall I upload a new version to mentors.d.o or send salsa merge request or both? > Please run lintian with the flags -i -v -E --pedantic to get the maximum > output. I recommend using pbuilder or sbuild to build in a clean > environment. I usually use sbuild in combination with git-buildpackage to do > my package builds. Both sbuild and pbuilder can lintian automatically after > a finished package build. Thanks. On Tue, May 03 2022, Tobias Frost wrote: > 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) I'll send that (as well as other parts) upstream. I first wanted to know what changes are required for Debian and then send the final version upstream. > - d/rules >- (bikeshed -- no need to change) I'd prefer to use d/clean instead of > overriding the clean target; overrides are harder to maintain :) I didn't notice this possibility - it's definitely nicer! > - the man page is still in the debian directory -- it can be deleted as > it is now part of upstream. Upstream has usbrelay.1, I've added usbrelayd.8. As mentioned above, I'll send it upstream later. > - same for the udev rules. Upstream rules are slightly different - looser permissions, different group. > - d/usbrelay.install has a hard-coded architecture-dependent path. That will > break build on > archs != amd64. Good catch. > - 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. That's definitely a good thing. > - 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) done > 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) Added, will send upstream later. > 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.) I think that tarballs are created automatically by GitHub upon tagging the release. I guess that for that, we would need to generate tarballs locally, sign them and upload
Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver
Am Tue, May 03, 2022 at 04:35:46PM +0200 schrieb Tobias Frost: > Hi Michael, > > (@Jan: would be nice if you could chimein in regards to this RFS) Hi Tobias, Hi Michal, As you might have guessed I'm busier than I would like and do usually need a bit of time to respond. > On Tue, May 03, 2022 at 12:28:39PM +0200, Michal Sojka wrote: > > > 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... > 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 > > * 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. It would have been a good idea to contact me directly or via a wishlist bug requesting a package update. I would have answered a wishlist bug requesting an usbrelay upstream version update. The RFS came a bit surprisingly. A short mail before starting the work would have been nice. I had contact with Darryl Bond in the past and responded to his requests. I would be happy to have a co-maintainer for usbrelay. @Michal you may add yourself to Uploaders if you are interested in taking care of the package in the future. Please run lintian with the flags -i -v -E --pedantic to get the maximum output. I recommend using pbuilder or sbuild to build in a clean environment. I usually use sbuild in combination with git-buildpackage to do my package builds. Both sbuild and pbuilder can lintian automatically after a finished package build. > 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
Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver
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 > * 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 >
