[2003-02-26] CVS repository changes

This message was generated and sent automatically.  It contains a
summary of the CVS commits over the last 48 hours.  These changes
should be propagated to the public repository within at most a day
or two.  Most probably, they have already been propagated.

2003-02-25 22:00:38  Thomas Roessler  <roessler <at> does-not-exist.org>
(roessler)

	* commands.c, recvcmd.c: Fix some (too lazy and tired to do all)
	of the inconsistencies between message and attachment bouncing.

	* crypt.c: I should test-compile things before committing.
	Stupid typo.

2003-02-25 21:41:32  Michael Elkins  <me <at> sigpipe.org>  (roessler)

	* query.c: Use mutt_strwidth for query response formatting.
	(#1477)

2003-02-25 21:37:59  Christian Vogel  <vogelchr <at> vogel.cx>  (roessler)

	* mx.c: Recognize MH folders used by sylpheed.

2003-02-25 21:35:24  jesus.climent <at> hispalinux.es  (roessler)

	* po/es.po: Fix a typo. (#1482)

2003-02-25 21:33:16  Thomas Roessler  <roessler <at> does-not-exist.org>
(roessler)

Re: GnuPG, mutt, and exit codes

On 2003-02-25 18:48:25 -0500, David Shaw wrote:

> GnuPG does set a non-zero exit code when it fails.  Is there some
> reason that mutt doesn't check it?  Here's a patch.

I'm not entirely sure any more, but this rings some bell in the back
of my mind that old PGP versions may return "failure" exit codes
when encryption succeeds, but the recipients' keys weren't
completely valid.  So, yes, I think there was some reason for doing
it this way.

(On the other hand -- who uses PGP 2.6 any more?)

--

-- 
Thomas Roessler				<roessler <at> does-not-exist.org>

bug#1488: Mail-Followup-To should use Reply-To address rather than From address

Package: mutt
Version: 1.5.3-3
Severity: normal

[NOTE: this bug report has been submitted to the debian BTS as Bug#182526.
Please Cc all your replies to 182526 <at> bugs.debian.org .]

From: Peter Palfrader <weasel <at> debian.org>
Subject: Mail-Followup-To should use Reply-To address rather than From address
Date: Wed, 26 Feb 2003 10:25:42 +0100

Say I have a mailinglist configured in lists:

} lists mailinglist <at> example.org

Now I compose mail to this list with
| From: from <at> example.com
| Reply-to: replyto <at> example.com
| To: mailinglist <at> example.org

mutt builds the following header:

| Mail-Followup-To: <from <at> example.com>, <mailinglist <at> example.org>

In my opinion if should really use the reply-to address if it exists:

| Mail-Followup-To: <replyto <at> example.com>, <mailinglist <at> example.org>

TIA,
[severity varies from wishlist to normal, I've set normal]

Introducing fast_reply / Cleanup of the two bounce functions

I implemented the fast_bounce option as quadoption as requested by Thomas
Roessler.

While I was around I removed the bug, which was yesterday introduced showing
"...? ...?"  while bouncing messages.

	Bounce message to Thomas Glanzmann <sithglan <at> stargo.gernoth.loc>...?...?  ([no]/yes):

When bouncing tagged messages or attachments the user is now informed about the
sucess of the bouncing.

When fast_reply is set to no ... the user is informed about the fact that he
can't bounce messages and why when he tries to.

Maybe we should rename 'fast_bounce' into simply 'bounce' (it is now good for
other things that just fast bouncing. )

	Thomas

? cscope.out
? csope.files
Index: commands.c
===================================================================
RCS file: /home/roessler/cvs/mutt/commands.c,v
retrieving revision 3.15
diff -u -r3.15 commands.c
--- commands.c	25 Feb 2003 22:00:38 -0000	3.15
+++ commands.c	26 Feb 2003 15:11:21 -0000
@@ -229,6 +229,15 @@

Re: GnuPG, mutt, and exit codes

On Wed, Feb 26, 2003 at 11:16:02AM +0100, Thomas Roessler wrote:
> On 2003-02-25 18:48:25 -0500, David Shaw wrote:
> 
> > GnuPG does set a non-zero exit code when it fails.  Is there some
> > reason that mutt doesn't check it?  Here's a patch.
> 
> I'm not entirely sure any more, but this rings some bell in the back
> of my mind that old PGP versions may return "failure" exit codes
> when encryption succeeds, but the recipients' keys weren't
> completely valid.  So, yes, I think there was some reason for doing
> it this way.

Hmm.  I wouldn't want to break things for old versions.  Here's an
updated patch that adds an $pgp_check_exit option, enabled by default.

> (On the other hand -- who uses PGP 2.6 any more?)

Judging by the email I get about interoperability, a very small, but
VERY vocal group..

David

? autom4te-2.53.cache
? stamp-h1
Index: init.h
===================================================================
RCS file: /home/roessler/cvs/mutt/init.h,v
retrieving revision 3.34
diff -u -r3.34 init.h

Re: sig verification

Paul Walker wrote on Tue, Feb 25, 2003 at 09:08:57PM +0000 :
> 
> > This started the day I switched from 1.4i to cvs snapshots on Nov 12 and
> > started using inline sigs instead of mime attachments.
> Just to check, what value are you using for pgp_good_sign?

For reference, I did not have the pgp_good_sign set (it was working fine
up to this point with it unset).  Paul had me add:

set pgp_good_sign="`gettext -d gnupg -s 'Good signature from "' | tr -d '"'`"

and now it works for both inline and mime sigs.

Blue skies...			Todd
--

-- 
           MandrakeSoft USA   http://www.mandrakesoft.com
Mandrake: An amalgam of good ideas from RedHat, Debian, and MandrakeSoft.
All in all, IMHO, an unbeatable combination.   --Levi Ramsey on Cooker ML
      Mandrake Cooker Devel Version, Kernel 2.4.21pre4-10mdk

Re: Occasionally fatal bug in handler.c?

mutt <at> garydjones.mailshell.com wrote:
: Anyone got any suggestions as to how to get mutt debugged under gdb, it
: doesn't seem to like it here.

By attaching to the running mutt process:

    gdb mutt <pid-of-running-mutt>

or
    gdb mutt
    (gdb) attach <pid-of-running-mutt>

--

-- 
Andrew W. Nosenko    (awn <at> bcs.zp.ua)

Re: Occasionally fatal bug in handler.c?

On 2003-02-26, mutt <at> garydjones.mailshell.com wrote:
> Is there a potential buffer overrun in mutt_decode_xbit? It seems that
> in some circumstances the variable 'l' indicating the position at
> which to insert a character into the buffer may not be changed on
> return from convert_to_state (with disastrous results), at least
> that's what it looks like from my debugging but then I'm trying to do
> it with dprint which doesn't exactly make life easy.

Can you describe the circumstances under which you believe an overflow
might occur?  It looks to me like the only case in which 'l' is not set
upon return is when 'bufi' is NULL, which is the final call from
mutt_decode_xbit and thus 'l' is no longer used.