Upstreaming patches (Re: Ask for review)

[Lukas Schwaighofer]

Hi,

On Fri, 21 Apr 2017 11:32:26 +0200
Raphael Hertzog <hertzog at debian.org> wrote:

> It does not hurt, maybe it will help convince upstream to switch to
> github or something like this....
> 
> And if nobody answers, it can also be used as a sign that it's really
> dead and that maybe we should drop the package (here we would need to
> assess if the package is really useful or if we have better
> alternatives).

Thanks for your guidance, that makes sense. I've acted accordingly,
let's see if I get a reply.  Apart from reporting the rfdump
buildsystem patch I've checked if patches I've made for other packages
should also be upstreamed.

I've decided not to report changes made to dsniff as the latest (last?)
upstream version is a "beta" version from 2002.  Do we document the fact
that we consider upstream dead somewhere (or is the fact that our patch
queue has a length of 35 documentation enough…)?

For libnids I've opened two additional issues in the sourcefourge BTS.
I've added links in the DEP-3 headers of our patches.

Btw: is there a reason http://dep.debian.net is not available via https?
Is there a way to find out who (or which pseudo-package) is responsible
for that service?

Thanks
Lukas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-security-team/attachments/20170422/3d4cae84/attachment.sig>