Re: Control header sent with done email didn't do what I expected, should it have?

[Don Armstrong]

On Mon, 25 Sep 2023, Jonathan Kamens wrote:
> Thank you! A canonical answer at last.

The reason why it wasn't implemented for -done and -forwarded is because
the psuedoheader parsing for -done is pretty different, and we aren't
doing any parsing for -forwarded.

There's no technical reason why it couldn't be done for both, but at the
time I implemented it, I didn't fully understand how much utility people
would find from it. [I underestimated the value of being able to mail
multiple bugs at the same time and use "Control: tag -1 foo".]

[Enabling it for nnn@ was really just a case of that happening for free
when I enabled it for submit@.]


-- 
Don Armstrong  https://www.donarmstrong.com

Any excuse will serve a tyrant.
 -- Aesop

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Andrey Rakhmatullin  [230925 15:13]:
> On Mon, Sep 25, 2023 at 01:55:22PM -0400, Jonathan Kamens wrote:
> > The documentation you inked to does not specify a tag that can be used
> > specifically to mark something as not actually a bug.
> Yes, we just close those. The Debian BTS is not as rich as e.g. a typical
> bugzilla installation in this regard. Though I guess not having a fixed
> version and not having the wontfix tag usually suggests the report was
> invalid.

How hard is it to add a 'notabug' tag?

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 01:55:22PM -0400, Jonathan Kamens wrote:
> The documentation you inked to does not specify a tag that can be used
> specifically to mark something as not actually a bug.
Yes, we just close those. The Debian BTS is not as rich as e.g. a typical
bugzilla installation in this regard. Though I guess not having a fixed
version and not having the wontfix tag usually suggests the report was
invalid.

>This bug won't be fixed. Possibly because this is a choice
>between two arbitrary ways of doing things and the maintainer
>and submitter prefer different ways of doing things, possibly
>because changing the behaviour will cause other, worse, problems
>for others, or */possibly for other reasons./*
> 
> "I don't consider this a bug" seems, to me, to fit under "other reasons."
Other reasons why *this bug won't be fixed*, which doesn't apply if this
is not a bug.

> Is there some harm that is done by marking a bug that falls into this
> category with "wontfix"?
I think there is some: it having wontfix suggests the bug is valid but
won't be fixed.
The harm is minimal though, because likely nobody will read this report if
it doesn't correspond to anything affecting other people.

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Jonathan Kamens  [230925 12:56]:
> Closed bugs are available for direct search for 30 days after they're
> closed.
> 
> After that you can still search them by selecting either "Archived" or
> "Archived and Unarchived" under "Misc Options" on the search page.

Except that in the general case, this is not very useful for avoiding
the duplicated filing of a bug that has already been discussed and
rejected.

> All that aside, in this particular case I closed the bug because it wasn't
> actually a bug, but rather a PEBKAC issue (user complaining that a program
> wasn't respecting his locale when he had LC_ALL set to "C" so he was
> essentially telling the program to ignore his locale).

That is a very good reason to close the bug.  Your original message did
not refer to the bug or even the package, so I had no knowledge of the
details.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Russ Allbery  [230925 12:43]:
> Marvin Renich  writes:
> 
> > I've seen differing opinions about closing "wontfix" bugs, but as a
> 
> I think it's a trade-off.

Which is why I said there are differing opinions.  This has come up on
this list before.

> There are some bugs that seem unlikely to ever
> come up again or that aren't helpfully worded, and I'm more willing to
> close those.

Agreed.

> Also, in the abstract, I don't like using the BTS as a documentation
> system, which is sort of what collecting wontfix amounts to.  If it's

Except that if it looks like a bug to me, I am going to fire up
reportbug without looking at README.Debian, and I think many users do
the same.  But, I do go through existing bugs to try to avoid
duplication.  I know not everyone does, but they should.

I feel that even though this was not the original intent of the BTS, it
is the most useful and pragmatic place to document this sort of thing.
Documenting it in a bug script may be more in line with its intended
use, but is probably a poorer use of Debian resources, as it uses Debian
and mirror archive space and download resources (both Debian and user)
for something that is only going to come up every 10,000 package
downloads.

> something that I think is going to come up a lot, it feels better to put
> it into the actual documentation (README.Debian, a bug script if it's
> reported really often, etc.).  You're also expecting everyone filing a bug
> to read through all the existing wontfix bugs (at least their titles),
> which in some cases is fine but in some cases can become overwhelming.

I wasn't trying to start a lengthy discussion or get Debian to make an
official policy, just stating a preference.  I expect that most
maintainers use good judgement, and adding the reasoning for my
preference might help them decide which wontfix bugs to close and which
to leave open.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

The documentation you inked to does not specify a tag that can be used 
specifically to mark something as not actually a bug.


That documentation does say the following about the "wontfix" tag 
(*/emphasis/* added by me):


   |wontfix|
   This bug won't be fixed. Possibly because this is a choice
   between two arbitrary ways of doing things and the maintainer
   and submitter prefer different ways of doing things, possibly
   because changing the behaviour will cause other, worse, problems
   for others, or */possibly for other reasons./*

"I don't consider this a bug" seems, to me, to fit under "other reasons."

Is there some harm that is done by marking a bug that falls into this 
category with "wontfix"?


  jik

On 9/25/23 13:40, Andrey Rakhmatullin wrote:

On Mon, Sep 25, 2023 at 12:55:16PM -0400, Jonathan Kamens wrote:

All that aside, in this particular case I closed the bug because it wasn't
actually a bug, but rather a PEBKAC issue (user complaining that a program
wasn't respecting his locale when he had LC_ALL set to "C" so he was
essentially telling the program to ignore his locale).

wontfix is a wrong tag for such bugs according to
https://www.debian.org/Bugs/Developer#tags  though.

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 12:55:16PM -0400, Jonathan Kamens wrote:
> All that aside, in this particular case I closed the bug because it wasn't
> actually a bug, but rather a PEBKAC issue (user complaining that a program
> wasn't respecting his locale when he had LC_ALL set to "C" so he was
> essentially telling the program to ignore his locale).
wontfix is a wrong tag for such bugs according to
https://www.debian.org/Bugs/Developer#tags though.

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

Closed bugs are available for direct search for 30 days after they're 
closed.


After that you can still search them by selecting either "Archived" or 
"Archived and Unarchived" under "Misc Options" on the search page.


All that aside, in this particular case I closed the bug because it 
wasn't actually a bug, but rather a PEBKAC issue (user complaining that 
a program wasn't respecting his locale when he had LC_ALL set to "C" so 
he was essentially telling the program to ignore his locale).


  jik

On 9/25/23 12:13, Marvin Renich wrote:

* Jonathan Kamens  [230925 07:17]:

Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag all at
once by sending my explanation to ###-d...@bugs.debian.org with "Control:
tags ### wontfix" as the first line of my message body. The bug was closed
but the tags command wasn't processed.

I've seen differing opinions about closing "wontfix" bugs, but as a
user, I appreciate when they are left open.  Whether it is a simple
wishlist feature request or a crash when the user abuses the software,
if I go to file the same or similar bug at a later time, if the bug is
closed I will not see it and file a duplicate.  If it is left open, I
can see the maintainer has already thought about it and intentionally
decided not to fix it, so I can save the trouble of refiling.  Also, I
might gain some insight about the circumstances.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Russ Allbery]

Marvin Renich  writes:

> I've seen differing opinions about closing "wontfix" bugs, but as a
> user, I appreciate when they are left open.  Whether it is a simple
> wishlist feature request or a crash when the user abuses the software,
> if I go to file the same or similar bug at a later time, if the bug is
> closed I will not see it and file a duplicate.  If it is left open, I
> can see the maintainer has already thought about it and intentionally
> decided not to fix it, so I can save the trouble of refiling.  Also, I
> might gain some insight about the circumstances.

I think it's a trade-off.  There are some bugs that seem unlikely to ever
come up again or that aren't helpfully worded, and I'm more willing to
close those.

Also, in the abstract, I don't like using the BTS as a documentation
system, which is sort of what collecting wontfix amounts to.  If it's
something that I think is going to come up a lot, it feels better to put
it into the actual documentation (README.Debian, a bug script if it's
reported really often, etc.).  You're also expecting everyone filing a bug
to read through all the existing wontfix bugs (at least their titles),
which in some cases is fine but in some cases can become overwhelming.

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

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Jonathan Kamens  [230925 07:17]:
> Hi all,
> 
> I recently tried to close a bug, explain why, and set a "wontfix" tag all at
> once by sending my explanation to ###-d...@bugs.debian.org with "Control:
> tags ### wontfix" as the first line of my message body. The bug was closed
> but the tags command wasn't processed.

I've seen differing opinions about closing "wontfix" bugs, but as a
user, I appreciate when they are left open.  Whether it is a simple
wishlist feature request or a crash when the user abuses the software,
if I go to file the same or similar bug at a later time, if the bug is
closed I will not see it and file a duplicate.  If it is left open, I
can see the maintainer has already thought about it and intentionally
decided not to fix it, so I can save the trouble of refiling.  Also, I
might gain some insight about the circumstances.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

Thank you! A canonical answer at last.

On 9/25/23 10:53, Andrey Rakhmatullin wrote:

On Mon, Sep 25, 2023 at 07:16:56AM -0400, Jonathan Kamens wrote:

I recently tried to close a bug, explain why, and set a "wontfix" tag all at
once by sending my explanation to ###-d...@bugs.debian.org with "Control:
tags ### wontfix" as the first line of my message body. The bug was closed
but the tags command wasn't processed.

It doesn't work for NNN-done@ according to
https://www.donarmstrong.com/posts/control_at_submit/

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 07:16:56AM -0400, Jonathan Kamens wrote:
> I recently tried to close a bug, explain why, and set a "wontfix" tag all at
> once by sending my explanation to ###-d...@bugs.debian.org with "Control:
> tags ### wontfix" as the first line of my message body. The bug was closed
> but the tags command wasn't processed.
It doesn't work for NNN-done@ according to
https://www.donarmstrong.com/posts/control_at_submit/

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 10:04:17AM -0400, Jonathan Kamens wrote:
> I did find this here  after I emailed
> the list:
> 
>QUESTION: Can you do all the control-server actions by using fields
>in a pseudo header in an email to bugnumber@b.d.o
> or do you need to use control@b.d.o
>?
> 
>ANSWER: You need to use the explicit control@ mail copy, automatic
>parsing isn't done. From what I understood it's worked on but it
>might take a bit to make it reliable and not catch something it
>shouldn't.
This is about plain commands, not about the Control: pseudo-header.
This QA transcript is from 2010, the feature was added in 2012.

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

...and I just successfully used a Control: header in an email to 
###@bugs.debian.org, so the only question remaining in my mind is 
whether the one that didn't work failed because it was sent to ###-done, 
or failed because of the base64 encoding. I can't think of any other 
reasons why the Control: header would have been ignored.

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 02:44:19PM +0100, Peter B wrote:
> On 25/09/2023 14:25, Jonathan Kamens wrote:
> > 
> > So putting a Control: line in the pseudo-header of a message sent to 
> > ###-d...@bugs.debian.org doesn't work at all?
> > 
> 
> It should work if the syntax is correct. The + character was missing.
Please read https://www.debian.org/Bugs/server-control#tag

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

According to https://www.debian.org/Bugs/server-control#tag the plus is 
optional.


Once again, my question was, should a valid Control: header on the first 
line of an email message sent to ###-d...@bug.debian.org work, and if 
so, is the reason why it didn't work in my case because the MIME part it 
was included in was base64-encoded, and if not, what other reason could 
explain why it didn't work?


I did find this here  after I 
emailed the list:


   QUESTION: Can you do all the control-server actions by using fields
   in a pseudo header in an email to bugnumber@b.d.o
    or do you need to use control@b.d.o
   ?

   ANSWER: You need to use the explicit control@ mail copy, automatic
   parsing isn't done. From what I understood it's worked on but it
   might take a bit to make it reliable and not catch something it
   shouldn't.

So, if this is correct, then I apparently what I tried to do just 
doesn't work. :shrug:


On 9/25/23 09:44, Peter B wrote:

On 25/09/2023 14:25, Jonathan Kamens wrote:


So putting a Control: line in the pseudo-header of a message sent to 
###-d...@bugs.debian.org doesn't work at all?




It should work if the syntax is correct. The + character was missing.

Re: Control header sent with done email didn't do what I expected, should it have?

[Peter B]

On 25/09/2023 14:25, Jonathan Kamens wrote:


So putting a Control: line in the pseudo-header of a message sent to 
###-d...@bugs.debian.org doesn't work at all?



It should work if the syntax is correct. The + character was missing.

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 02:06:44PM +0100, Peter B wrote:
> > I recently tried to close a bug, explain why, and set a "wontfix" tag
> > all at once by sending my explanation to ###-d...@bugs.debian.org with
> > "Control: tags ### wontfix" as the first line of my message body. The
> > bug was closed but the tags command wasn't processed.
> > 
> > Looking at the raw message file that I sent, I see that my mailer
> > encoded the text/plain MIME body part with base64 because I had pasted
> > into the body a quote from a web site that used non-ASCII quotation
> > marks (d'oh). Is that why BTS failed to process the "Control:" command?
> > 
> > If yes, then is this a known thing that's not going to change that I
> > should just live with ;-), or should I file a bug about it?
> > 
> > If no, then can anyone tell me what else I did wrong to cause the 
> > "Control:" command not to be processed?
> > 
> > Thanks,
> > 
> > jik
> > 
> 
> see
> https://www.debian.org/Bugs/server-refcard
> 
> It should be
> tags bugnumber + wontfix
> 
> sent to cont...@bugs.debian.org
Please check https://www.debian.org/Bugs/Reporting#control

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

So putting a Control: line in the pseudo-header of a message sent to 
###-d...@bugs.debian.org doesn't work at all?


On 9/25/23 09:06, Peter B wrote:

On 25/09/2023 12:16, Jonathan Kamens wrote:


Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag 
all at once by sending my explanation to ###-d...@bugs.debian.org 
with "Control: tags ### wontfix" as the first line of my message 
body. The bug was closed but the tags command wasn't processed.


Looking at the raw message file that I sent, I see that my mailer 
encoded the text/plain MIME body part with base64 because I had 
pasted into the body a quote from a web site that used non-ASCII 
quotation marks (d'oh). Is that why BTS failed to process the 
"Control:" command?


If yes, then is this a known thing that's not going to change that I 
should just live with ;-), or should I file a bug about it?


If no, then can anyone tell me what else I did wrong to cause the 
"Control:" command not to be processed?


Thanks,

jik



see
https://www.debian.org/Bugs/server-refcard

It should be
tags bugnumber + wontfix

sent to cont...@bugs.debian.org

best to have
package foo

on the first line in case of typos in the bug number!

Re: Control header sent with done email didn't do what I expected, should it have?

[Peter B]

On 25/09/2023 12:16, Jonathan Kamens wrote:


Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag all at once by sending my explanation to 
###-d...@bugs.debian.org with "Control: tags ### wontfix" as the first line of my message body. The bug was closed but 
the tags command wasn't processed.


Looking at the raw message file that I sent, I see that my mailer encoded the text/plain MIME body part with base64 
because I had pasted into the body a quote from a web site that used non-ASCII quotation marks (d'oh). Is that why BTS 
failed to process the "Control:" command?


If yes, then is this a known thing that's not going to change that I should just live with ;-), or should I file a bug 
about it?


If no, then can anyone tell me what else I did wrong to cause the "Control:" 
command not to be processed?

Thanks,

jik



see
https://www.debian.org/Bugs/server-refcard

It should be
tags bugnumber + wontfix

sent to cont...@bugs.debian.org

best to have
package foo

on the first line in case of typos in the bug number!

Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag 
all at once by sending my explanation to ###-d...@bugs.debian.org with 
"Control: tags ### wontfix" as the first line of my message body. The 
bug was closed but the tags command wasn't processed.


Looking at the raw message file that I sent, I see that my mailer 
encoded the text/plain MIME body part with base64 because I had pasted 
into the body a quote from a web site that used non-ASCII quotation 
marks (d'oh). Is that why BTS failed to process the "Control:" command?


If yes, then is this a known thing that's not going to change that I 
should just live with ;-), or should I file a bug about it?


If no, then can anyone tell me what else I did wrong to cause the 
"Control:" command not to be processed?


Thanks,

jik