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 <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. 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 upload required, no > visible activity on > the package >6months) @Tino thanks for pointing Michal in this direction > 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. Kind regards Jan -- Jan Dittberner - Debian Developer GPG-key: 4096R/0xA73E0055558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD https://portfolio.debian.net/ - https://people.debian.org/~jandd/
signature.asc
Description: PGP signature
