Bug reporting
Uday S Reddy
I would like to encourage people to use these functions to report bugs because they transmit valuable information to us about the state of the VM system when the problems occur. It is best to describe as much about the problem as possible and try to be as specific about the problem as possible. For example, don't say "whenever the attachment name has a $ sign". Specify the exact attachment name that caused the problem, because there could be other features of the name that might have been responsible. The Emacs manual has some valuable guidance on how to report bugs.
Ulrich and I have waded through all the bug reports that had accumulated during the last year or so. We resolved most of them, but there were also several reports that had too little information for us to track down the problems. You can see the current status at the launchpad page for the 8.1.0-beta release:
https://launchpad.net/vm/+milestone/8.1.0-beta
You can see the other unresolved bug reports by clicking on 'Bugs'. Please feel free to add more detail to the bugs that are marked 'incomplete'.
Cheers,
Uday
Robert Marshall
> M-x vm-submit-bug-report is a long-standing VM feature, written by
> Kyle Jones, for reporting bugs in VM. Rob and I had beefed it up a
> bit during the last couple of years. I also added variants such
> vm-imap-start-bug-report etc. for tracking the interactions with mail
> servers. All of these are described in the VM manual (or will be,
> shortly, in the new release).
So the email address in the submit-bug-report still gets to you as well
as Rob?
I tried running it (I have a bug to report :-) ) and it took around 10
minutes to prepare the email - so I think there's a bug in the bug
submission!
When it gets to vm-shrunken-headers-keymap there's miscellaneous garbage
- around 1.2 meg of it - mainly spaces but with occasional variables in it
This is with
Emacs : GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.18.3)
of 2009-11-09 on faure.capuchin.co.uk
Package: VM 8.0.14
I think there are also privacy issues in the bug submission there are an
awful lot of private bits of information encoded in the variables like
vm-auto-folder-alist (at least in my case!)
I think it needs some way of obfuscating sensitive data.
(My bug was that if I - from the summary view a message, delete it and
move backwards in the summary the help button in the toolbar gets
corrupted - I think it says
-Part 1
-Part Z
But maybe you're now missing the crucial data? )
Robert
--
La grenouille songe..dans son château d'eau
Links and things http://rmstar.blogspot.com/
Uday S Reddy
> So the email address in the submit-bug-report still gets to you as well
> as Rob?
If it is Rob's email address, it won't get to us. Please use
v...@lists.launchpad.net as the 'to' address. We have been updating the
devo version files with the right email address, but you might have an
older version.
> I tried running it (I have a bug to report :-) ) and it took around 10
> minutes to prepare the email - so I think there's a bug in the bug
> submission!
I love that! Bug in the bug submission!
> When it gets to vm-shrunken-headers-keymap there's miscellaneous garbage
> - around 1.2 meg of it - mainly spaces but with occasional variables in it
>
> This is with
>
> Emacs : GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.18.3)
> of 2009-11-09 on faure.capuchin.co.uk
> Package: VM 8.0.14
>
> I think there are also privacy issues in the bug submission there are an
> awful lot of private bits of information encoded in the variables like
> vm-auto-folder-alist (at least in my case!)
>
> I think it needs some way of obfuscating sensitive data.
Please feel free to delete whatever bits seem sensitive and/or wasteful.
If you tell me which variables have potentially sensitive data and
which seem wasteful (the keymap certainly is), I will remove them from
the list.
The precise history of this thing is that Kyle used to have a selected
list of variables to snapshot, which he decided based on experience,
but Rob seems to have automatically included every variable declared
in vm-vars.el. Hence the list is bloated.
Cheers,
Uday
Uday S Reddy
> (My bug was that if I - from the summary view a message, delete it and
> move backwards in the summary the help button in the toolbar gets
> corrupted - I think it says
> -Part 1
> -Part Z
Well, I just tried this sequence with the devo version as well as
8.0.x, and the Help button worked fine. Perhaps if you tell me the
precise sequence of keystrokes & mouse clicks, that might make a
difference. M-x view-lossage produces a record of the last few
keystrokes. (It isn't perfect though.)
Cheers,
Uday
Robert Marshall
C-x C-f . e m a <tab> <return> C-s 8 . C-e C-x C-e
<escape> x v m - v i s <tab> f <tab> <return> I N B
<tab> v <tab> <return> y q SPC p C-x ? <switch-frame>
<switch-frame> <select-window> <help-echo> <help-echo>
<switch-frame> s C-x 1 <next> <next> <next> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<return> n p n p <escape> x v i e w - l o s <tab>
<return>
Is a record of the complete session, I went to .emacs and modifying
the load path to use 8.0.14, visited a test folder, the q and s are due
to bbdb grouching that there's something else (another emacs) with
possession of .bbdb (switch frame because help pops up in a separate
frame).
It didn't happen for me on the first message, but I scrolled down the
summary window and at that point the corruption happened - as you see
from the above deleting a message was not necessary
There's nothing in *Messages* which looks appropriate
Robert Marshall
> Robert Marshall wrote:
>
>> So the email address in the submit-bug-report still gets to you as
>> well as Rob?
>
> If it is Rob's email address, it won't get to us. Please use
> v...@lists.launchpad.net as the 'to' address. We have been updating the
> devo version files with the right email address, but you might have an
> older version.
>
>> I tried running it (I have a bug to report :-) ) and it took around
>> 10 minutes to prepare the email - so I think there's a bug in the bug
>> submission!
>
> I love that! Bug in the bug submission!
>
I thought you'd enjoy that
>> When it gets to vm-shrunken-headers-keymap there's miscellaneous
>> garbage
>> - around 1.2 meg of it - mainly spaces but with occasional variables in it
>>
>> This is with
>>
>> Emacs : GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.18.3)
>> of 2009-11-09 on faure.capuchin.co.uk
>> Package: VM 8.0.14
>>
>> I think there are also privacy issues in the bug submission there are
>> an awful lot of private bits of information encoded in the variables
>> like vm-auto-folder-alist (at least in my case!)
>>
>> I think it needs some way of obfuscating sensitive data.
>
> Please feel free to delete whatever bits seem sensitive and/or
> wasteful.
>
> If you tell me which variables have potentially sensitive data and
> which seem wasteful (the keymap certainly is), I will remove them from
> the list.
In my setup
vm-auto-folder-alist
vm-imap-server-list - people *might* put passwords there (I know they
shouldn't - they might have written some code which adds it?)
Maybe a prominent warning at the head of the message saying please
check for sensitive data to the submitter and how to signal that it
has been removed?
vm-imap-auto-expunge-alist ditto
vm-spool-files
vm-pop-foler-alist
vm-mail-folder-alist
vm-mail-fcc-default
vmpc-actions
vmpc-conditions
vmpc-reply-alist (maybe)
In 8.0.14 the To: address is ha...@robf.de
Maybe when the list is shorter due to that keymap being removed it might
be easier to scan it for privacy related stuff before the user sends it.
Uday S Reddy
> C-x C-f . e m a <tab> <return> C-s 8 . C-e C-x C-e
> <escape> x v m - v i s <tab> f <tab> <return> I N B
> <tab> v <tab> <return> y q SPC p C-x ? <switch-frame>
> <switch-frame> <select-window> <help-echo> <help-echo>
> <switch-frame> s C-x 1 <next> <next> <next> <down>
> <down> <down> <down> <down> <down> <down> <down> <down>
> <return> n p n p <escape> x v i e w - l o s <tab>
> <return>
I still have no success in reproducing the problem. C-x 1 suggests
that you have just the summary window open and a few movement commands
(<next>). For me, these movement commands do nothing. They are just
bound to next-line! So, you probably have them bound to something
more interesting.
In any case, I can hazard a guess. I have noticed that the Help
button also doubles as a "MIME" button. It turns into a MIME button
when you select a MIME message and it is in non-decoded and non-button
state. But I didn't actually get this MIME button to do anything.
When I click on it, it turns back into a Help button again. Strange!
So, my guess is that you are seeing is some mix-up of the two
functionalities (Help and MIME).
When you say the Help button gets corrupted, what actually happens?
Cheers,
Uday
Uday S Reddy
>
> In my setup
> vm-auto-folder-alist
> vm-imap-server-list - people *might* put passwords there (I know they
> shouldn't - they might have written some code which adds it?)
> Maybe a prominent warning at the head of the message saying please
> check for sensitive data to the submitter and how to signal that it
> has been removed?
The variables vm-spool-files, vm-imap-auto-expunge-alist,
vm-pop-auto-expunge-alist and vm-pop-folder-alist were excluded by
Kyle precisely because some people might passwords there. I have
extended the list yesterday and changed the code to scrub passwords
instead of deleting the variables themselves.
You are now saying that there are other variables like
vm-auto-folder-alist where people might put passwords? I will check
that, and also add a warning for users to check for sensitive info.
Cheers,
Uday
Robert Marshall
Thanks, I think it was my initial concern that I was - in effect -
passing large parts of my address book to the bug tracker and I might
also not want to make, however public that is, elements of my
categorisation known
e.g.
(setq vm-auto-folder-alist '(
("From"
("manager@company" . "pinHeadedBoss")
("@choke" . "excitableIdiots")
("troll@usenet" . "/dev/null"))))
You get the idea? (I would emphasise that I don't have any entries like
this but some people might)
Robert Marshall
>
> Robert Marshall wrote:
>
>> C-x C-f . e m a <tab> <return> C-s 8 . C-e C-x C-e
>> <escape> x v m - v i s <tab> f <tab> <return> I N B
>> <tab> v <tab> <return> y q SPC p C-x ? <switch-frame>
>> <switch-frame> <select-window> <help-echo> <help-echo>
>> <switch-frame> s C-x 1 <next> <next> <next> <down>
>> <down> <down> <down> <down> <down> <down> <down> <down>
>> <return> n p n p <escape> x v i e w - l o s <tab> <return>
>
> I still have no success in reproducing the problem. C-x 1 suggests
> that you have just the summary window open and a few movement commands
> (<next>). For me, these movement commands do nothing. They are just
> bound to next-line! So, you probably have them bound to something
> more interesting.
For me, p is bound to vm-previous-message. It looks as if I have to view
a message and then some motion within the summary buffer causes the
strange behaviour
>
> In any case, I can hazard a guess. I have noticed that the Help
> button also doubles as a "MIME" button. It turns into a MIME button
> when you select a MIME message and it is in non-decoded and non-button
> state. But I didn't actually get this MIME button to do
> anything. When I click on it, it turns back into a Help button again.
> Strange!
>
> So, my guess is that you are seeing is some mix-up of the two
> functionalities (Help and MIME).
>
Yes it is mime related - the messages where I see it have multiple
parts, though pressing that toolbar button doesn't do anything.
So maybe it is intended it is just that the backend isn't working and
that - for me - it is nearly impossible to read the text on the button
> When you say the Help button gets corrupted, what actually happens?
>
http://brock-marshall.no-ip.info/~robert/vm-tb.jpg for a screenshot
I guess that's the mime button but you need younger eyes that mine to
tell it - just looks like squiggles here.
I think, intended behaviour, but needs tweaking to get that behaviour to
happen and the UI needs a bit more help.
Uday S Reddy
> http://brock-marshall.no-ip.info/~robert/vm-tb.jpg for a screenshot
>
> I guess that's the mime button but you need younger eyes that mine to
> tell it - just looks like squiggles here.
I think there is a way to put text labels on the icons. (I have them,
but I don't know how, probably by default.)
But, on the whole, I think that trying to use Emacs through menus and
toolbars is probably unworkable. Emacs is really a keyboarder's
application. (Please feel free to disagree!)
Cheers,
Uday
Uday S Reddy
>
> Thanks, I think it was my initial concern that I was - in effect -
> passing large parts of my address book to the bug tracker and I might
> also not want to make, however public that is, elements of my
> categorisation known
The vm-submit-bug-report function only sends the bug report to us, the
maintainers. We might put some kind of summary of the problem on the
launchpad bug tracker once we confirm that it is indeed a bug, but we
will not put the whole bug-report message on the tracker. When we do
so, we will not include the values of variables except those that
matter for the problem.
If I were sending a bug-report, I would feel comfortable attaching
email messages that are not particularly sensitive. The rest of you
can suit yourselves. Please feel free to notate anything in the
bug-report as PRIVATE if you definitely do not want it to go on the
bug tracker. But it is more important to give us the information we
need to track down problems than to worry about the bug tracker.
"Bugs" often arise because the system is made to go through unexpected
situations that the developers didn't anticipate. So, we would like
to get as much information as possible about the situation that gave
rise to the problem. Holding back information will make it harder for
us to track things down.
Cheers,
Uday