On Sun, 08 Jun 2014, Vincent Cheng wrote: > On Sun, Jun 8, 2014 at 11:10 PM, Alexander Wirt <formo...@debian.org> wrote: > > On Sun, 08 Jun 2014, Vincent Cheng wrote: > > > >> On Sun, Jun 8, 2014 at 10:57 PM, Alexander Wirt <formo...@debian.org> > >> wrote: > >> > On Sun, 08 Jun 2014, Vincent Cheng wrote: > >> > > >> >> Hi Andreas, > >> >> > >> >> On Thu, Jun 5, 2014 at 3:35 PM, Andreas Rönnquist <gus...@gusnan.se> > >> >> wrote: > >> >> > The version in squeeze-proposed-updates (0.3.2-1+deb6u1) still got > >> >> > this > >> >> > wrong - running catfish from the terminal gives: > >> >> > > >> >> > python: can't open file '/usr/share/catfish/bin/catfish.py': [Errno > >> >> > 2] No such file or directory > >> >> > > >> >> > Where the /usr/bin/catfish has got: > >> >> > > >> >> > #!/usr/bin/env bash > >> >> > python /usr/share/catfish/bin/catfish.py "$@" > >> >> > > >> >> > it should be: > >> >> > > >> >> > #!/usr/bin/env bash > >> >> > python /usr/share/catfish/catfish.py "$@" > >> >> > > >> >> > (I just tested it in a Squeeze VM) > >> >> > >> >> Fixed and uploaded as 0.3.2-1+deb6u2, thanks! Jackson, I pinged you on > >> >> IRC, but since it doesn't look like you're going to respond anytime > >> >> soon, I just went ahead with a team upload. > >> >> > >> >> (Jackson: I can't believe I have to keep on saying this, but please > >> >> actually test your packages before asking for an upload!) > >> > if you uploaded the package, you have the same responsibility. I expect > >> > from > >> > anyone _uploading_ a package - be it a sponsor or the maintainer - to > >> > test > >> > their backports. That means installing the backport in a _fresh_ > >> > environment, > >> > before the upload. Testing means: > >> > - installation > >> > - using the software > >> > > >> > if you are uploading a bunch of dependencys, only upload after all > >> > backports > >> > are build and test with the whole dependency chain. > >> > >> #744820 has nothing to do with a backport. Also, I don't want to play > >> the blame game here, but I disagree with the assertion that sponsors > >> have the same set of responsibilities as the actual maintainer of the > >> package. In this specific case, I'm not a catfish user, I am merely > >> interested in fixing a bunch of CVEs against this package that have > >> gone unfixed for a while in stable/oldstable. > > Uhm, sorry. I got the wrong mailinglist. Anyhow, I disagree the sponsor has > > the same responsibility as the maintainer. If they don't understand the > > package, they shouldn't upload it. > > If sponsors were required to be domain experts in the packages that > they sponsor, then we'd see a lot less sponsoring taking place in > Debian, and a lot more packages bitrotting in the archive. I've always > advocated for lower barriers for contributing to Debian, and that > applies to both maintainership and sponsorship. In terms of > sponsorship, as long as the sponsor is able to fix anything he/she > breaks, that's fine by me; I don't see why we should be discouraging > people from sponsoring packages that they aren't necessarily familiar > with (and frankly, that's the last thing that we should be doing - > making it harder for prospective contributors to find someone, anyone, > who might be interested in sponsoring their package(s); just take a > look at the ever-increasing length of the sponsorship-requests queue). That way you are just wasting other peoples time, buildd time and so on. If such a policy prevents broken, packages with low quality and so on from being uploaded I am happy with it. And to just test some binarys, you don't have to be an expert.
Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org