Re: Unauthorised activity surrounding tbb package

2015-01-19 Thread Mathieu Malaterre
Steven,

While being in terrible position to tell you what you should or should
not do, I'd still suggest you to read:

https://www.debian.org/code_of_conduct
https://people.debian.org/~enrico/dcg/


On Fri, Jan 16, 2015 at 5:48 PM, Steven Capper  wrote:
> Mathieu,
> I'm writing to express my increasing frustration at activities you've
> instigated surrounding the tbb package that I maintain.

The wording 'frustration' is very accurate, see below.

> Over the Christmas period a bug report was raised:
> #773359 "package tbb_4.2~20140122-4 FTBFS on mips and mipsel"
>
> and answered by yourself:
> "While I do understand the bug severity, our intention with Steve
> Capper was to only support upstream arch."

Right, I did comment on the bug, which felt as if I had impersonate
you. Please also mention, this bug dates from Dec 17, and you've not
made any comment on an RC bug since.

> Whilst I may agree with your sentiments, we have had no discussion
> over #773359; your response is effectively placing words in my mouth
> and I will not tolerate that. To confound matters, I wasn't even CC'ed
> in on the response!

Again, this is very sorry, you did not include our private emails
surrounding #752820 (Jun 26). If I remember correctly I've sent you
multiple requests to have #752820 be fixed ASAP.
With your Makefiles talent, you quickly closed (Aug 21), thanks again
very much for this.
However this is where I failed to understand the following: why didn't
you request an unblock request at that point ? You knew Nov 5th was
coming quickly.

> Then there's:
> #775506 "unblock: tbb/4.2~20140122-4"
> and,
> #775263 "RM: tbb [s390x mips mipsel] -- ANAIS; #768040"
>
> Both of which have been raised without any discussion with me; I am
> the maintainer for tbb!

While I do agree with you that I should not have requested 775506
without contacted you first. Here is a linearized history of what
happen:

1)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775262
RM: openvdb [mipsel sparc] -- ANAIS; #768040

Before you were tbb maintainer I had to work on tbb fixed to have the
openvdb test suite to work on POWER arch. Therefore I'd appreciate
that only proper arches are available in tbb for any dependie package
to work correctly (openvdb maintainer hat on).
Now if you read this report, you'll think this is fairly dumb, since
there is only two options: source upload which will go against #773359
at some point. Or as clarified a couple of minutes ago:

block 775262 by 775263

2)
Which leads to 775263 you mentionned above as me stepping on your
shoes. It happens to me a lot that a bug is reported in my package,
but quickly discover that the bug is within an underlying package.
This is *exactly* what happen, I even clarified this with my `block`
request. I do believe this was my right for 775263 to do so.

> The technical work is hard enough, and I'm new to Debian and am
> learning the ropes still; it is not helpful to keep me in the dark
> over my own package.

This is exactly what was depicted in our private emails surrounding
#752820, and this was also my *assomption* when you uploaded it in Aug
but never requested an unblock request.
So as said above, this is an incorrect assumption, and I should not
have reported this unblock request. However as explained above this
adds extra work for package depending on tbb since mips* and s390x are
non-functional on this arches (IMHO, again I am not tbb maintainer,
simply a tbb user)

> I appreciate that you are trying to help, but I cannot maintain this
> package whilst continually looking over my shoulder. I welcome help,
> but I must insist that maintainer related tasks surrounding tbb are
> discussed with me before they are instigated.

Since our discussion about #752820, you've never ever mentionned this.
So I (incorrectly) assumed you appreciated my help on bug triaging.

> [ I've CC'ed in debian-devel@lists.debian.org, as this is the second
> time I've had to bring this sort of thing up with you. ].

You've forgotten to mentionned I deeply appologized for this (I know
you received the email, since you answered it).

I'd like to mention that so far I already had three legitimate unblock
requests refused, so I would really appreciate if you could clarify
your position on what arches should be available for tbb in jessie.
In turn I understand that I should have stopped right after #775263,
and never fill #775506 without your consent first. However as
explained above, please clarify your position on tbb's arches, and
mention you've never sent a single email to either me or the BTS about
this.

Regards
-M


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsxLj8BnyBjm=-=1zypeufbt7x5z8-l0non5uwdtybw...@mail.gmail.com



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Johannes Schauer
Hi,

Quoting Ben Hutchings (2015-01-19 02:03:52)
> On Mon, 2015-01-19 at 08:37 +0800, Paul Wise wrote:
> > I'd very much appreciate the ability to not be auto-subscribed to
> > every bug so please do implement the opt-out thing, preferably before
> > this change is rolled out.
> > 
> > Personally, I think subscriptions should work like this:
> > 
> > The default should be to auto-subscribe submitters and contributors to bugs.
> [...]
> 
> No, this would turn the BTS into a (worse) spam vector.

how about the other way round then:

 - by default everything stays as it is and there is no auto subscription
 - by sending an email to the bts I can activate that I'm automatically
   subscribed to all bugs I submitted or contributed (maybe separately
   configurable)

Would this not make both camps happy: those who would like to autosubscribe to
the bugs they file or contribute to and those who rather want to individually
subscribe to each bug report?

cheers, josch


signature.asc
Description: signature


Re: Unauthorised activity surrounding tbb package

2015-01-19 Thread Mathieu Malaterre
On Mon, Jan 19, 2015 at 9:25 AM, Mathieu Malaterre  wrote:
> Steven,
>
> While being in terrible position to tell you what you should or should
> not do, I'd still suggest you to read:
>
> https://www.debian.org/code_of_conduct
> https://people.debian.org/~enrico/dcg/

Just to be clear: I was suggested those links in the past when I felt
animosity from another DD to resolve in the best possible manner the
conflict. At no time was I telling how to act, but rather where to
find help.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsx3cdLKTco+sX=bn6mtqjs4_ecfwvweuc84og3hhce...@mail.gmail.com



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Paul Wise
On Mon, Jan 19, 2015 at 4:30 PM, Johannes Schauer wrote:

> how about the other way round then:
>
>  - by default everything stays as it is and there is no auto subscription
>  - by sending an email to the bts I can activate that I'm automatically
>subscribed to all bugs I submitted or contributed (maybe separately
>configurable)
>
> Would this not make both camps happy: those who would like to autosubscribe to
> the bugs they file or contribute to and those who rather want to individually
> subscribe to each bug report?

I think that will just continue the current situation where people
don't know that they have to be subscribed to get followups, as they
are used to other bug trackers where both bug submission and even
posting a comment will get you on the subscribe list by default.

Maybe this:

New submitters get the autosubscribe bit by default.

People who have submitted before 2015 do not get the autosubscribe bit
by default.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6hh0mctv-bx01durougu---gvuzmpfnjwwo7okrhan...@mail.gmail.com



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Tomas Pospisek
Am 19.01.2015 um 02:03 schrieb Ben Hutchings:
> On Mon, 2015-01-19 at 08:37 +0800, Paul Wise wrote:
>> On Mon, Jan 19, 2015 at 8:06 AM, Don Armstrong wrote:
>>
>>> I'm going to put together a bit more firm of a proposal in the next few
>>> weeks, but I think that basically everything but nnn-done@ and
>>> nnn-submitter@ should be no different from mailing nnn@, and until I
>>> allow submitters to opt out of e-mail, mailing nnn-submitter@ should be
>>> no different from e-mailing nnn@ either.
>>
>> I'd very much appreciate the ability to not be auto-subscribed to
>> every bug so please do implement the opt-out thing, preferably before
>> this change is rolled out.
>>
>> Personally, I think subscriptions should work like this:
>>
>> The default should be to auto-subscribe submitters and contributors to bugs.
> [...]
> 
> No, this would turn the BTS into a (worse) spam vector.
> 
> But the acknowledgement mail should tell you how to subscribe, if you
> aren't already subscribed.

But isn't subscribing participants "natural"? Posting to a bug report
means participation and thus you'd get the follow-ups. Why would you
post to a bug report if you aren't interested in what happens with it,
how things proceed/evolve?

I can understand your point of view and I think also the why but isn't
that position the exception from the rule? That is shouldn't the process
be optimized for the "common" case and allow the exception?

Technically the exception could be implemented by adding a further
pseudo header to the message body:

  Subscribe: false

Another technical solution could be as noted in a different mail in this
thread to allow submitters to set a global flag that says don't
automatically subscribe me on participation.

?

Thanks
*t


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54bcc865.4090...@sourcepole.ch



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Paul Wise
On Mon, Jan 19, 2015 at 5:03 PM, Tomas Pospisek wrote:

> But isn't subscribing participants "natural"? Posting to a bug report
> means participation and thus you'd get the follow-ups. Why would you
> post to a bug report if you aren't interested in what happens with it,
> how things proceed/evolve?

It is only natural to people who are used to it happening on other bug
trackers. People often file bugs for issues they discover in software
they don't use or care about, getting followups to those isn't
necessary.

> I can understand your point of view and I think also the why but isn't
> that position the exception from the rule? That is shouldn't the process
> be optimized for the "common" case and allow the exception?

The problem is that there is no common case. The only generality I can
think of is that people who have been around for a long time generally
want the status quo and new people who are usually used to other bug
trackers want to be subscribed by default.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6enxdr+m1anjusqeue2cpo4iaasb88ykc8--s7aggk...@mail.gmail.com



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Stefano Zacchiroli
On Mon, Jan 19, 2015 at 05:14:18PM +0800, Paul Wise wrote:
> People often file bugs for issues they discover in software they don't
> use or care about, getting followups to those isn't necessary.

Uh? What's your rationale for this, and in particular for the "often"
part?

Surely the typical use case for a bug report is "I use this software ->
this feature doesn't work -> I submit a bug report"? That is the use
case we should optimize for, because taking the risk of leaving out the
original bug submitter from conversations around that bug increase
friction in the bug fixing process, in turn reducing the quality of our
distro.

The main use cases of someone reporting a bug against software they
don't use is quality-assurance activities. Which is clearly a very
important activity, but we should not optimize for it.

I've done my share of QA work in Debian, including mass bug filing, but
my gut feeling is that still, 90% of the bugs I've reported to Debian
throughout all my life are against software that I use and care about.

(Clearly, we should not make the QA use case needlessly painful. Hence
I'm all for the opt-out mechanism you and Don discussed in another part
of the thread. But I'm convinced that we should optimize for the other
use case.)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature


Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Thijs Kinkhorst
On Mon, January 19, 2015 10:14, Paul Wise wrote:
> On Mon, Jan 19, 2015 at 5:03 PM, Tomas Pospisek wrote:
>
>> But isn't subscribing participants "natural"? Posting to a bug report
>> means participation and thus you'd get the follow-ups. Why would you
>> post to a bug report if you aren't interested in what happens with it,
>> how things proceed/evolve?
>
> It is only natural to people who are used to it happening on other bug
> trackers.

The only seems to suggest this is a minority. I would however argue that
the majority of other bug tracking systems do subscribe you to bugs you
interact with.

It makes sense to me that you do not need intimate knowledge of the Debian
BTS to contribute, rather, it should by default behave as people with only
prior experience in other environments would expect it to.

> People often file bugs for issues they discover in software
> they don't use or care about, getting followups to those isn't
> necessary.

While this use case exists, this is again surely a minority and in general
people will file bugs because they ran into them or otherwise have an
interest. The defaults should match this; the power users can always
investigate how to best opt out.


Cheers,
Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/c0c487d45d5c224726070a5eb27e7878.squir...@aphrodite.kinkhorst.nl



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Wookey
+++ Paul Wise [2015-01-19 17:14 +0800]:
> On Mon, Jan 19, 2015 at 5:03 PM, Tomas Pospisek wrote:
> 
> > I can understand your point of view and I think also the why but isn't
> > that position the exception from the rule? That is shouldn't the process
> > be optimized for the "common" case and allow the exception?
> 
> The problem is that there is no common case. The only generality I can
> think of is that people who have been around for a long time generally
> want the status quo and new people who are usually used to other bug
> trackers want to be subscribed by default.

I want to be subscribed to bugs I submit (by default). It annoys me
that this doesn't happen and I miss replies or updates. Occaisionally
I submit bugs I'm not actually very interested in, but that's not the
usual case.

Can someone remind me what the current rules are (or where it's
written down). I know it doesn't work the way I expect it ought to, but
I forget/never-understood exactly how it does work.

Do maintainers always get the initial mail to a bug, but not the rest,
unless they subscribe? That seems rather unhelpful if so (as
illustrated by Mr Capper's frustration at the start of this thread)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150119092640.gc4...@stoneboat.aleph1.co.uk



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Russell Stuart
On Mon, 2015-01-19 at 10:03 +0100, Tomas Pospisek wrote:
> Am 19.01.2015 um 02:03 schrieb Ben Hutchings:
> > No, this would turn the BTS into a (worse) spam vector.
> > 
> > But the acknowledgement mail should tell you how to subscribe, if you
> > aren't already subscribed.
> 
> But isn't subscribing participants "natural"?

It may be natural, but IMO you are underestimating the spam vector
problem.

Debian's bug submission mechanism does not try to verify you control the
email address you are submitting from.  Most other bug tracking systems
do such authentication, usually by requiring you to create an account.
Since there is no verification it becomes trivial to sign someone up to
1000's of bugs using a script.

Treating every bug submission as a subscribe request (by putting a
subscribe link in the ack) is one compromise. (I am sort of surprised
that doesn't happen already.)  Automatically subscribing a DD to any bug
he sends a signed message to is another.

I am partial to the latter, even though it is a partial solution.  It
encourages DD to sign their bug reports.  IMHO anything we can do to
encourage DD's to sign their emails to the project improves our
security.


signature.asc
Description: This is a digitally signed message part


Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Eugene Zhukov
On Mon, Jan 19, 2015 at 11:26 AM, Wookey  wrote:
> +++ Paul Wise [2015-01-19 17:14 +0800]:
>> On Mon, Jan 19, 2015 at 5:03 PM, Tomas Pospisek wrote:
>>
>> > I can understand your point of view and I think also the why but isn't
>> > that position the exception from the rule? That is shouldn't the process
>> > be optimized for the "common" case and allow the exception?
>>
>> The problem is that there is no common case. The only generality I can
>> think of is that people who have been around for a long time generally
>> want the status quo and new people who are usually used to other bug
>> trackers want to be subscribed by default.
>
> I want to be subscribed to bugs I submit (by default). It annoys me
> that this doesn't happen and I miss replies or updates. Occaisionally
> I submit bugs I'm not actually very interested in, but that's not the
> usual case.
>
> Can someone remind me what the current rules are (or where it's
> written down). I know it doesn't work the way I expect it ought to, but
> I forget/never-understood exactly how it does work.
>
> Do maintainers always get the initial mail to a bug, but not the rest,
> unless they subscribe? That seems rather unhelpful if so (as
> illustrated by Mr Capper's frustration at the start of this thread)

Through my experience this is not the case - even the maintainer
doesn't get mail about a bug.
For example I'm listed as a maintainer of epubcheck package, but I
didn't receive
any email about reported bug #773366.
I've sent a mail to ow...@bugs.debian.org asking about absence of any
notification about reported bug, but no response since 12/22/14.

Eugene


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/capqgmflvr7fq7yv67ybhpj1vwgaz5m5am82aauoi8p5ikbu...@mail.gmail.com



Re: Who gets an email when with bugreports

2015-01-19 Thread Joachim Breitner
Hi,

Am Montag, den 19.01.2015, 19:41 +1000 schrieb Russell Stuart:
> Debian's bug submission mechanism does not try to verify you control the
> email address you are submitting from.

At least trac allows you to put other people’s email address in the CC
header, at least in some configurations.

> Most other bug tracking systems
> do such authentication, usually by requiring you to create an account.
> Since there is no verification it becomes trivial to sign someone up to
> 1000's of bugs using a script.

There are easier way to annoy people. I would not worry too much about
this. At least not until we have evidence of this being a real problem.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part


Re: new pre-dependency: perl{,-base,-modules} -> dpkg (>= 1.17.17)

2015-01-19 Thread Guillem Jover
[ CCing debian-release. ]

Hi!

On Sun, 2015-01-18 at 20:12:55 +0200, Niko Tyni wrote:
> In order to fix trigger related wheezy->jessie upgrade failures in
> xfonts-traditional (#774844, cc'd), I intend to make the main perl
> binary packages (perl, perl-base, and perl-modules) Pre-Depend on dpkg
> (>= 1.17.17), which has this change:
> 
>   * Defer trigger processing if the package does not fulfill dependencies.
> Closes: #671711
> 
> Together with making the jessie perl-modules and perl-base Break the
> wheezy perl, this should ensure that the xfonts-traditional trigger will
> not run when perl is in a broken state during upgrades.
> 
> Please see the #774844 bug log for details, and let me know if you have
> objections or other suggestions.

I've not looked into the details yet, but just to comment that there's
been talk about possibly reverting that fix, because in some error
situations it can get apt into an unrecoverable state (#774124). :(

Of course reverting that fix brings back all upgrade issues related
to trigger processing w/o the required dependencies. Which are
probably more, and easier to get into.

(I guess this just calls for both a fixed apt, and a dpkg that
workarounds any such situation.)

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150119101504.gc20...@gaara.hadrons.org



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Adam D. Barratt

On 2015-01-19 10:03, Eugene Zhukov wrote:

Through my experience this is not the case - even the maintainer
doesn't get mail about a bug.
For example I'm listed as a maintainer of epubcheck package,


No, you're not:

Maintainer: Debian XML/SGML Group 



You're listed in the "Uploaders" field, which is approximately 
"co-maintainers". Those indeed don't receive mail from the BTS.



but I didn't receive
any email about reported bug #773366.


The maintainer received it just fine. See 
http://lists.alioth.debian.org/pipermail/debian-xml-sgml-pkgs/2014-December/011832.html


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/7f7bd0331167cbf2fa6cac147aba0...@mail.adsl.funky-badger.org



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Mattia Rizzolo
On Mon, Jan 19, 2015 at 09:26:41AM +, Wookey wrote:
> Can someone remind me what the current rules are (or where it's
> written down). I know it doesn't work the way I expect it ought to, but
> I forget/never-understood exactly how it does work.
> 
> Do maintainers always get the initial mail to a bug, but not the rest,
> unless they subscribe? That seems rather unhelpful if so (as
> illustrated by Mr Capper's frustration at the start of this thread)

The package maintainer gets all the email releated to the bugs (including
responses from control@b.d.o), unless the emails are sent to -quiet@b.d.o.

If other people want to receive such emails (e.g. comaintainers) they should
subscribe through the PTS (or the tracker, with its nice UI and the big
"Subscribe" bottom in the top-right edge) at the relevant keywords:
- bts: for normal "discussion" emails
- bts-control: for control@b.d.o replies

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me:  http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page:   https://wiki.ubuntu.com/MattiaRizzolo


signature.asc
Description: Digital signature


Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Adam D. Barratt

On 2015-01-19 10:47, Mattia Rizzolo wrote:

On Mon, Jan 19, 2015 at 09:26:41AM +, Wookey wrote:

Can someone remind me what the current rules are (or where it's
written down). I know it doesn't work the way I expect it ought to, 
but

I forget/never-understood exactly how it does work.

Do maintainers always get the initial mail to a bug, but not the rest,
unless they subscribe? That seems rather unhelpful if so (as
illustrated by Mr Capper's frustration at the start of this thread)


The package maintainer gets all the email releated to the bugs 
(including
responses from control@b.d.o), unless the emails are sent to 
-quiet@b.d.o.


That's incorrect. nnn-submitter doesn't get sent to the maintainer 
either, as covered earlier in this thread.


There's a reference list on 
https://www.debian.org/Bugs/Developer#followup


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/d777148cf3a3131f1b362e8826351...@mail.adsl.funky-badger.org



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Wookey
+++ Adam D. Barratt [2015-01-19 11:01 +]:
> On 2015-01-19 10:47, Mattia Rizzolo wrote:
> >On Mon, Jan 19, 2015 at 09:26:41AM +, Wookey wrote:
> >>Can someone remind me what the current rules are (or where it's
> >>written down). I know it doesn't work the way I expect it ought
> >>to, but I forget/never-understood exactly how it does work.

> >The package maintainer gets all the email releated to the bugs
> >(including responses from control@b.d.o), unless the emails are
> >sent to -quiet@b.d.o.

> That's incorrect. nnn-submitter doesn't get sent to the maintainer
> either, as covered earlier in this thread.
> 
> There's a reference list on
> https://www.debian.org/Bugs/Developer#followup

Ah yes, and that list has no option for 'maintainer and submitter' or
'everybody who replied to this bug' which both seem like things one
would like to use. Also, so far as I can tell, neither of those are
default cases either. 

I recall looking at that list for the 'maintainer and submitter'
option, and being disappointed not to find one. Am I right that the
only way to expliticly mail the submitter and the maintainer is to
look the submitter's mail up in the initial bugrep and just CC it,
whilst replying to bugnum@b.d.o, which will automatically include the
maintainer? (which feels like work the BTS could do for me, maybe even
by default). Or should I mail both nnn@b.d.o _and_ nnn-submitter@b.d.o
to get the desired effect? Doesn't that result in two mails to
debian-bugs-dist, which seems wrong/unhelpful?

I can see that the system goes to a lot of trouble to make sure people
don't get mail they didn't want, but it seems to make it hard to
ensure thast everyone _does_ get responses. Perhaps I am failing to
understand how to use it, but in that case I claim that it's not very
obvious.

I think Stefano accurately described how I think it should work.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150119113120.ge4...@stoneboat.aleph1.co.uk



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Adam D. Barratt

On 2015-01-19 11:31, Wookey wrote:

I recall looking at that list for the 'maintainer and submitter'
option, and being disappointed not to find one. Am I right that the
only way to expliticly mail the submitter and the maintainer is to
look the submitter's mail up in the initial bugrep and just CC it,
whilst replying to bugnum@b.d.o, which will automatically include the
maintainer?


Yes. If it's done "right" from the start, you don't have to look their 
address up though. The Reply-To on the copy of the submission mail sent 
by the BTS is set to include both the submitter and n@bugs (and 
therefore the maintainer).


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/6bc31fef80cf4868adc557ddafaf0...@mail.adsl.funky-badger.org



Bug#775743: ITP: caveexpress -- 2D platformer with physics-based gameplay

2015-01-19 Thread Markus Koschany
Package: wnpp
Severity: wishlist
Owner: Markus Koschany 

* Package name: caveexpress
  Version : 2.1
  Upstream Author : Martin Gerhardy 
* URL : http://www.caveproductions.org
* License : GPL3+, CC-BY-SA-4.0
  Programming Lang: C++, Lua
  Description : 2D platformer with physic-based gameplay

CaveExpress is a classic 2D platformer with physics-based gameplay and
dozens of levels. Master your pedal-powered flying machine to pick up
packages from your cave-dwelling clients and drop them off at the
collection point.

But beware! Mighty mastodons, terrifying pterodactyls and others would
rather see you extinct.

I intend to maintain this game as part of the Debian Games team.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150119133947.7942.27452.reportbug@conan



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Ian Jackson
Firstly, I should say: I'm sorry that I got the design of this wrong
when I set up the BTS.  I hadn't appreciated at the time that bug
reports are actually (amongst other things) ad-hoc mailing lists.

Paul Wise writes ("Re: Who gets an email when with bugreports [was: Re: 
Unauthorised activity surrounding tbb package]"):
> Personally, I think subscriptions should work like this:
> 
> The default should be to auto-subscribe submitters and contributors to bugs.

Yes for submitters.

No for contributors; that wouldn't be very opt-in.  Instead,
contributors should get an auto-subscribe confirmation request email
when they first email a particular bug.

> Every email address can have an auto-subscribe value associated with
> it to override that.

This would be nice but is IMO not essential.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21693.8751.967879.605...@chiark.greenend.org.uk



Re: new pre-dependency: perl{,-base,-modules} -> dpkg (>= 1.17.17)

2015-01-19 Thread Ian Jackson
Guillem Jover writes ("Re: new pre-dependency: perl{,-base,-modules} -> dpkg 
(>= 1.17.17)"):
> On Sun, 2015-01-18 at 20:12:55 +0200, Niko Tyni wrote:
> > In order to fix trigger related wheezy->jessie upgrade failures in
> > xfonts-traditional (#774844, cc'd), I intend to make the main perl
> > binary packages (perl, perl-base, and perl-modules) Pre-Depend on dpkg
> > (>= 1.17.17), which has this change:
> > 
> >   * Defer trigger processing if the package does not fulfill dependencies.
> > Closes: #671711
> > 
> > Together with making the jessie perl-modules and perl-base Break the
> > wheezy perl, this should ensure that the xfonts-traditional trigger will
> > not run when perl is in a broken state during upgrades.
> > 
> > Please see the #774844 bug log for details, and let me know if you have
> > objections or other suggestions.

Thanks, Niko, I think you have the correct fix.  I was meaning to
follow up suggesting a Pre-Depends.

> I've not looked into the details yet, but just to comment that there's
> been talk about possibly reverting that fix, because in some error
> situations it can get apt into an unrecoverable state (#774124). :(
> 
> Of course reverting that fix brings back all upgrade issues related
> to trigger processing w/o the required dependencies. Which are
> probably more, and easier to get into.

Yes.

> (I guess this just calls for both a fixed apt, and a dpkg that
> workarounds any such situation.)

Do we know what change is needed to apt ?

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21693.9092.311523.933...@chiark.greenend.org.uk



Bug#775753: ITP: opensurgsim -- A free platform for surgical simulation

2015-01-19 Thread Paul Novotny
Package: wnpp
Severity: wishlist
Owner: Paul Novotny 

* Package name: opensurgsim
  Version : 0.6.0
  Upstream Author : Paul Novotny 
* URL : http://www.opensurgsim.org/
* License : Apache 2.0
  Programming Lang: C++
  Description : A free platform for surgical simulation

OpenSurgSim is an open-source project dedicated to real-time surgical
simulation. It offers an open framework that includes the necessary building
blocks for surgical simulations, such as native device support, haptic
feedback, graphics, discrete collision detection and physics simulation.
OpenSurgSim is flexible. Developers can refactor the physics engine, swap
models, ODE solvers, or linear system solvers.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150119160923.2759.76266.reportbug@revlaptop



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Russ Allbery
Tomas Pospisek  writes:

> But isn't subscribing participants "natural"? Posting to a bug report
> means participation and thus you'd get the follow-ups. Why would you
> post to a bug report if you aren't interested in what happens with it,
> how things proceed/evolve?

Most other bug systems require at least a weak authentication step before
letting you comment on a bug, so there's some reasonable binding of
identity of the person commenting with an email address.  This is not true
for the Debian BTS.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d26ahg4x@hope.eyrie.org



Bug#775764: ITP: pyvisa-py -- A PyVISA backend implemented in pure Python

2015-01-19 Thread Ruben Undheim
Package: wnpp
Severity: wishlist
Owner: Ruben Undheim 

* Package name: pyvisa-py
  Version : 0.1~20150106gitd86fb71
  Upstream Author : Hernan E. Grecco
* URL : https://github.com/hgrecco/pyvisa-py
* License : MIT
  Programming Lang: Python
  Description : A PyVISA backend implemented in pure Python

PyVISA started as wrapper for the NI-VISA library and therefore you need to 
install
National Instruments VISA library in your system. This works most of the time,
for most people. But NI-VISA is a proprietary library that only works on certain
systems. That is when PyVISA-py jumps in.

Starting form version 1.6, PyVISA allows to use different backends. These 
backends can be
dynamically loaded. PyVISA-py is one of such backends. It implements most of 
the methods
for Message Based communication (Serial/USB/GPIB/Ethernet) using Python and 
some well developed,
easy to deploy and cross platform libraries

This package is useful in Debian since it replaces a huge proprietary library
needed in many instrumentation facilities.

I plan to maintain it as part of the Python Modules team.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150119182052.31251.63497.report...@miniserver.beebeetle.com



Re: Unauthorised activity surrounding tbb package

2015-01-19 Thread Steven Capper
On 19 January 2015 at 08:25, Mathieu Malaterre  wrote:
> Steven,

Hi Mathieu,

>
> While being in terrible position to tell you what you should or should
> not do, I'd still suggest you to read:
>
> https://www.debian.org/code_of_conduct
> https://people.debian.org/~enrico/dcg/
>

Thanks, I will give these a read.

>
> On Fri, Jan 16, 2015 at 5:48 PM, Steven Capper  
> wrote:
>> Mathieu,
>> I'm writing to express my increasing frustration at activities you've
>> instigated surrounding the tbb package that I maintain.
>
> The wording 'frustration' is very accurate, see below.
>
>> Over the Christmas period a bug report was raised:
>> #773359 "package tbb_4.2~20140122-4 FTBFS on mips and mipsel"
>>
>> and answered by yourself:
>> "While I do understand the bug severity, our intention with Steve
>> Capper was to only support upstream arch."
>
> Right, I did comment on the bug, which felt as if I had impersonate
> you. Please also mention, this bug dates from Dec 17, and you've not
> made any comment on an RC bug since.
>
>> Whilst I may agree with your sentiments, we have had no discussion
>> over #773359; your response is effectively placing words in my mouth
>> and I will not tolerate that. To confound matters, I wasn't even CC'ed
>> in on the response!
>
> Again, this is very sorry, you did not include our private emails
> surrounding #752820 (Jun 26). If I remember correctly I've sent you
> multiple requests to have #752820 be fixed ASAP.
> With your Makefiles talent, you quickly closed (Aug 21), thanks again
> very much for this.
> However this is where I failed to understand the following: why didn't
> you request an unblock request at that point ? You knew Nov 5th was
> coming quickly.

That was a big mistake on my part.

>
>> Then there's:
>> #775506 "unblock: tbb/4.2~20140122-4"
>> and,
>> #775263 "RM: tbb [s390x mips mipsel] -- ANAIS; #768040"
>>
>> Both of which have been raised without any discussion with me; I am
>> the maintainer for tbb!
>
> While I do agree with you that I should not have requested 775506
> without contacted you first. Here is a linearized history of what
> happen:
>
> 1)
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775262
> RM: openvdb [mipsel sparc] -- ANAIS; #768040
>
> Before you were tbb maintainer I had to work on tbb fixed to have the
> openvdb test suite to work on POWER arch. Therefore I'd appreciate
> that only proper arches are available in tbb for any dependie package
> to work correctly (openvdb maintainer hat on).
> Now if you read this report, you'll think this is fairly dumb, since
> there is only two options: source upload which will go against #773359
> at some point. Or as clarified a couple of minutes ago:
>
> block 775262 by 775263
>
> 2)
> Which leads to 775263 you mentionned above as me stepping on your
> shoes. It happens to me a lot that a bug is reported in my package,
> but quickly discover that the bug is within an underlying package.
> This is *exactly* what happen, I even clarified this with my `block`
> request. I do believe this was my right for 775263 to do so.
>
>> The technical work is hard enough, and I'm new to Debian and am
>> learning the ropes still; it is not helpful to keep me in the dark
>> over my own package.
>
> This is exactly what was depicted in our private emails surrounding
> #752820, and this was also my *assomption* when you uploaded it in Aug
> but never requested an unblock request.
> So as said above, this is an incorrect assumption, and I should not
> have reported this unblock request. However as explained above this
> adds extra work for package depending on tbb since mips* and s390x are
> non-functional on this arches (IMHO, again I am not tbb maintainer,
> simply a tbb user)
>
>> I appreciate that you are trying to help, but I cannot maintain this
>> package whilst continually looking over my shoulder. I welcome help,
>> but I must insist that maintainer related tasks surrounding tbb are
>> discussed with me before they are instigated.
>
> Since our discussion about #752820, you've never ever mentionned this.
> So I (incorrectly) assumed you appreciated my help on bug triaging.

I'm happy for any help I can get, I just need to be CC'ed into
responses to bugs (the system didn't send me feedback) and a quick
heads-up if something does need doing and I've obviously not noticed.

>
>> [ I've CC'ed in debian-devel@lists.debian.org, as this is the second
>> time I've had to bring this sort of thing up with you. ].
>
> You've forgotten to mentionned I deeply appologized for this (I know
> you received the email, since you answered it).

You did apologise.

>
> I'd like to mention that so far I already had three legitimate unblock
> requests refused, so I would really appreciate if you could clarify
> your position on what arches should be available for tbb in jessie.
> In turn I understand that I should have stopped right after #775263,
> and never fill #775506 without your consent first. However as
> explained above

Re: Bug#775743: ITP: caveexpress -- 2D platformer with physics-based gameplay

2015-01-19 Thread Adam Borowski
On Mon, Jan 19, 2015 at 02:39:47PM +0100, Markus Koschany wrote:
> * Package name: caveexpress
> * URL : http://www.caveproductions.org
>   Description : 2D platformer with physic-based gameplay
> 
> CaveExpress is a classic 2D platformer with physics-based gameplay and
> dozens of levels. Master your pedal-powered flying machine to pick up
> packages from your cave-dwelling clients and drop them off at the
> collection point.
> 
> But beware! Mighty mastodons, terrifying pterodactyls and others would
> rather see you extinct.

You mean, Ugh? :p

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150119202447.ga28...@angband.pl



Re: Bug#775743: ITP: caveexpress -- 2D platformer with physics-based gameplay

2015-01-19 Thread Markus Koschany
On Mon, 19. Jan 21:24 Adam Borowski  wrote:

> You mean, Ugh? :p

Yes, that's the remake of Ugh, a great C-64/Amiga game but adapted to
modern hardware. :-) It also provides a HTML5 flavour, AFAIK the first
one of its kind in Debian.


signature.asc
Description: Digital signature


Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Octavio Alvarez
On 19/01/15 01:14, Paul Wise wrote:
> On Mon, Jan 19, 2015 at 5:03 PM, Tomas Pospisek wrote:
> 
>> But isn't subscribing participants "natural"? Posting to a bug 
>> report means participation and thus you'd get the follow-ups. Why 
>> would you post to a bug report if you aren't interested in what 
>> happens with it, how things proceed/evolve?
> 
> It is only natural to people who are used to it happening on other 
> bug trackers. People often file bugs for issues they discover in 
> software they don't use or care about, getting followups to those 
> isn't necessary.
>> 
>> I can understand your point of view and I think also the why but 
>> isn't that position the exception from the rule? That is shouldn't 
>> the process be optimized for the "common" case and allow the 
>> exception?
> 
> The problem is that there is no common case. The only generality I 
> can think of is that people who have been around for a long time 
> generally want the status quo and new people who are usually used to 
> other bug trackers want to be subscribed by default.

Hi.

It is far better to get the surprise that you got subscribed and
having to unsubscribe than to get the surprise that you did not get
subscribed and missing real-time conversation.

Also, automatic subscription would definitely lower the barrier for
potential contributors, as it is expected to be subscribed; it also
makes continued contribution require less effort. Experts that want to
nitpick each case could have a flag available and their default could be
changed by one or another way.

Best regards.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54bd7a61.7040...@alvarezp.ods.org



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Michael Gilbert
On Mon, Jan 19, 2015 at 4:41 AM, Russell Stuart wrote:
>> But isn't subscribing participants "natural"?
>
> It may be natural, but IMO you are underestimating the spam vector
> problem.
>
> Debian's bug submission mechanism does not try to verify you control the
> email address you are submitting from.  Most other bug tracking systems
> do such authentication, usually by requiring you to create an account.
> Since there is no verification it becomes trivial to sign someone up to
> 1000's of bugs using a script.

Isn't the spam vector already wide open for
nn-subscr...@bugs.debian.org, which isn't much (ab)used today?

I fail to see how any of the discussed changes open an abuse vector
that doesn't already exist.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANTw=MO6gKhnJtrjKFiGWYm4vFpb-PjcrOTKJ4WM8-LQ0t=z...@mail.gmail.com



Bug#775789: ITP: libauthen-htpasswd-perl -- Perl module to read and modify Apache .htpasswd files

2015-01-19 Thread Christopher Hoskin
Package: wnpp
Severity: wishlist
Owner: Christopher Hoskin 

* Package name: libauthen-htpasswd-perl
  Version : 0.171
  Upstream Author : Matt S Trout 
* URL : https://metacpan.org/release/Authen-Htpasswd
* License : Perl
  Programming Lang: Perl
  Description : Perl module to read and modify Apache .htpasswd files

Authen::Htpasswd provides a convenient, object-oriented interface to 
Apache-style .htpasswd files.

It supports passwords encrypted via MD5, SHA1, and crypt, as well as plain 
(cleartext) passwords.

Additional fields after username and password, if present, are accessible via 
the extra_info array.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150119220956.7530.95359.reportbug@Debian



Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread Russell Stuart
On Mon, 2015-01-19 at 16:57 -0500, Michael Gilbert wrote:
> Isn't the spam vector already wide open for
> nn-subscr...@bugs.debian.org, which isn't much (ab)used today?
> 
> I fail to see how any of the discussed changes open an abuse vector
> that doesn't already exist.

OK, so let me help you see.

The vector you are pointing to doesn't exist.  You can _not_ subscribe
to a bug by sending email to -subscr...@bugs.debian.org.  You
subscribe to a bug by sending an email to an address that looks like
this:

  
701234-subyes-8aba1368a9ac33362ea1f68c28446c15-65bf3bd3886fb8abfe59d40709c84...@bugs.debian.org

I presume this "invite" address is unforgeable (because Ian Jackson's
expertise is in crypto, and he said earlier he designed the system).

Sending an email to -subscr...@bugs.debian.org just asks the system
to send an invite containing such an address to someone.  I'm not sure
what email address gets the invite - it could be the envelope MAIL FROM,
or the Reply-To, or the From.  But really "who" doesn't matter.  All the
matters is the only a person controlling an email address is able to
subscribe it to a bug, not some random noob.

For what it's worth, the invitation contains full text of the
subscription request, including all the RFC5322 headers.  If it was
someone doing something unpleasant it gives you some hope of tracking
them down, or blocking them.

In other words the current system contains robust defences against such
an attack.  All I (and I presume Ben) are saying is removing those
defences is not a good idea, given it's easy enough to design a system
that keeps them.  Currently most of the auto subscription proposals
appearing here do remove them.


signature.asc
Description: This is a digitally signed message part


Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

2015-01-19 Thread James McCoy
On Mon, Jan 19, 2015 at 11:31:20AM +, Wookey wrote:
> Am I right that the
> only way to expliticly mail the submitter and the maintainer is to
> look the submitter's mail up in the initial bugrep and just CC it,
> whilst replying to bugnum@b.d.o, which will automatically include the
> maintainer? (which feels like work the BTS could do for me, maybe even
> by default). Or should I mail both nnn@b.d.o _and_ nnn-submitter@b.d.o
> to get the desired effect?

The latter.  The forward to debian-bugs-dist is handled by the BTS so it
will deduplicate the message.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150120005418.gi22...@freya.jamessan.com



Bug#775796: ITP: libapache-session-memcached-perl -- Perl module for storing persistent data using memcached

2015-01-19 Thread Christopher Hoskin
Package: wnpp
Severity: wishlist
Owner: Christopher Hoskin 

* Package name: libapache-session-memcached-perl
  Version : 0.03
  Upstream Author : Enrico Sorcinelli 
* URL : https://metacpan.org/release/Apache-Session-Memcached
* License : Perl 5.8.1 or later
  Programming Lang: Perl, Python, etc.
  Description : Perl module for storing persistent data using memcached

Apache::Session::Memcached is a bridge between Apache::Session and memcached, a 
distributed memory cache daemon.

More informations about memcached are available at 
http://www.danga.com/memcached.

Apache::Session::Memcached provides a way to use Cache::Memcached (memcached 
Perl API) as Apache::Session storage implementation.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150120051551.1161.18796.reportbug@Debian