mutt: 7 new changesets

7 new changesets in mutt: http://dev.mutt.org/hg/mutt/rev/4f598543d7a5 changeset: 5041:4f598543d7a5 branch: HEAD tag: tip user:Brendan Cully <[EMAIL PROTECTED]> date:Sun Apr 01 23:12:45 2007 -0700 summary: Adjust context->size on IMAP load and expunge (closes #27

tempfile creation on NFS, VFAT, sshfs

Here are two patches that attempt to fix tempfile creation on NFS, VFAT and SSHFS. The NFS problem is bug #2707, where .muttxxx temp directories are left lying around. I've worked around this by closing the file after creating it O_EXCL. I believe this is safe, but I'd like the local paranoiacs to

Re: [Mutt] #1431: misleading --disable-external-dotlock

#1431: misleading --disable-external-dotlock functionality/ documentation vs. naming/ intuition Changes (by brendan): * milestone: => 1.6 Old description: > {{{ > Package: mutt > Version: mutt-1.5.3-1 > Severity: normal > > -- Please type your report below this line > > I configured mutt (sa

bug resolutions & servers (Re: [Mutt] #2551: imap_sync_mailbox: EXPUNGE failed when synching)

On Mon, Apr 02, 2007 at 03:22:35AM -, Mutt wrote: > #2551: imap_sync_mailbox: EXPUNGE failed when synching mailbox > > Changes (by brendan): > > * status: assigned => closed > * resolution: => wontfix > > Comment: > > Server error. > by any convention, this resolution does not make

Re: [Mutt] #1220: After telnet session dies, Mutt continues

On 2007-04-02 02:01:04 -, Mutt wrote: > #1220: After telnet session dies, Mutt continues running, gradually consuming > all > CPU resources. > > Changes (by brendan): > > * summary: mutt-: After telnet session dies, Mutt continues running, > gradually consuming all CPU resou

Re: [Mutt] #1220: After telnet session dies, Mutt continues running,

#1220: After telnet session dies, Mutt continues running, gradually consuming all CPU resources. Comment (by Vincent Lefevre): {{{ On 2007-04-02 02:01:04 -, Mutt wrote: > #1220: After telnet session dies, Mutt continues running, gradually consuming all > CPU resources. > > Changes (by

Re: bug resolutions & servers (Re: [Mutt] #2551:

On Monday, 02 April 2007 at 09:48, Oswald Buddenhagen wrote: > On Mon, Apr 02, 2007 at 03:22:35AM -, Mutt wrote: > > #2551: imap_sync_mailbox: EXPUNGE failed when synching mailbox > > > > Changes (by brendan): > > > > * status: assigned => closed > > * resolution: => wontfix > > > > Co

Re: [Mutt] #1220: After telnet session dies, Mutt continues running,

#1220: After telnet session dies, Mutt continues running, gradually consuming all CPU resources. Changes (by brendan): * cc: [EMAIL PROTECTED] (added) * reporter: T L Hall <[EMAIL PROTECTED]> => T L Hall -- Ticket URL:

Re: [Mutt] #2194: mutt hanging in endless loop

#2194: mutt hanging in endless loop Changes (by brendan): * status: new => closed * resolution: => duplicate Comment: Duplicate of #1220 -- Ticket URL:

Re: tempfile creation on NFS, VFAT, sshfs

On Mon, Apr 02, 2007 at 12:18:11AM -0700, Brendan Cully wrote: > Here are two patches that attempt to fix tempfile creation on NFS, > VFAT and SSHFS. I'd personally like to take a look at these, but I won't have time until later in the week... What bug number(s) are the SSHFS/VFAT bugs? (or, I c

mutt.org DNS (was Re: bug resolutions & servers (Re: [Mutt] #2551:)

On Mon, Apr 02, 2007 at 07:58:53AM -0700, Brendan Cully wrote: > > btw, www.mutt.org is down. > > not here. > > > the wiki still links to bugs.mutt.org, which is still active. is this > > intended? > > bugs.mutt.org is supposed to point to dev.mutt.org/trac/. > $ host bugs.mutt.org ns.gbnet.net

Re: mutt.org DNS (was Re: bug resolutions & servers (Re: [Mutt]

On 2007-04-02 11:35:56 -0400, Derek Martin wrote: > $ dig @kamino.does-not-exist.org www.mutt.org |grep www > ; <<>> DiG 9.2.1 <<>> @kamino.does-not-exist.org www.mutt.org > ;www.mutt.org. IN A > www.mutt.org. 86400 IN CNAME mutt.org. > [???] kamino knows

Re: mutt.org DNS (was Re: bug resolutions & servers (Re: [Mutt]

On Monday, 02 April 2007 at 17:42, Thomas Roessler wrote: > On 2007-04-02 11:35:56 -0400, Derek Martin wrote: > > > $ dig @kamino.does-not-exist.org www.mutt.org |grep www > > ; <<>> DiG 9.2.1 <<>> @kamino.does-not-exist.org www.mutt.org > > ;www.mutt.org. IN A > > www.mutt.o

Re: tempfile creation on NFS, VFAT, sshfs

On Monday, 02 April 2007 at 11:07, Derek Martin wrote: > On Mon, Apr 02, 2007 at 12:18:11AM -0700, Brendan Cully wrote: > > Here are two patches that attempt to fix tempfile creation on NFS, > > VFAT and SSHFS. > > I'd personally like to take a look at these, but I won't have time > until later in

Re: mutt.org DNS (was Re: bug resolutions & servers (Re: [Mutt]

On Mon, Apr 02, 2007 at 08:49:22AM -0700, Brendan Cully wrote: > looks like the serial has lost a digit. Steve, can you change > 200703302 > to > 2007033000 It likely won't matter unless you already previously did a zone transfer with out of date data using 2007033000 as the serial, but since you

Re: mutt.org DNS (was Re: bug resolutions & servers (Re: [Mutt]

On Mon, Apr 02, 2007 at 11:59:26AM -0400, Derek Martin wrote: > On Mon, Apr 02, 2007 at 08:49:22AM -0700, Brendan Cully wrote: > > looks like the serial has lost a digit. Steve, can you change > > 200703302 > > to > > 2007033000 > It likely won't matter unless you already previously did a zone >

Re: tempfile creation on NFS, VFAT, sshfs

On Mon, Apr 02, 2007 at 08:58:50AM -0700, Brendan Cully wrote: > > I'd personally like to take a look at these, but I won't have time > > until later in the week... What bug number(s) are the SSHFS/VFAT > > bugs? (or, I can just search for them when I get the chance...) > > I don't think they ha

Re: mutt.org DNS (was Re: bug resolutions & servers (Re: [Mutt]

On Mon, Apr 02, 2007 at 11:35:56AM -0400, Derek Martin wrote: > $ dig @ns.sigpipe.org www.mutt.org |grep www > ; <<>> DiG 9.2.1 <<>> @ns.sigpipe.org www.mutt.org > [No answer] It seems to be responding from some places, but not others. I am working on fixing the problem. Same issue is happening

Re: mutt.org DNS (was Re: bug resolutions & servers (Re: [Mutt]

On Mon, Apr 02, 2007 at 05:04:32PM +0100, Steve Kennedy wrote: > OK serial changed to 2007040300 and my dates are in GMT :) I'm slaving both to ns.gbnet.net and the other one... looks like ns.gbnet isn't picking up the NOTIFY Apr 2 11:50:44 mitch named[26233]: transfer of 'mutt.org/IN' from 194

Re: mutt.org DNS (was Re: bug resolutions & servers (Re: [Mutt]

On Mon, Apr 02, 2007 at 11:35:56AM -0400, Derek Martin wrote: > 1. NS.SIGPIPE.ORG is not answering queries for mutt.org, but it is > listed as a name server. FYI, I have removed ns.sigpipe.org as a NS. No idea why it isn't working. Instead, I have added ns2.veggiechinese.net in its place. me

#2846: Security vulnerability in APOP authentication

On Sunday, 18 March 2007 at 17:36, Rocco Rutte wrote: > I was looking at some mutt code for this issue and other issues that > report broken threading upon invalid message-ids. It seems that mutt > happily accepts the following syntax: '<.*>' which is just plain wrong. > > I looked at rfc822

Re: [Mutt] #2846: Security vulnerability in APOP authentication

#2846: Security vulnerability in APOP authentication Comment (by Brendan Cully): {{{ On Sunday, 18 March 2007 at 17:36, Rocco Rutte wrote: > I was looking at some mutt code for this issue and other issues that > report broken threading upon invalid message-ids. It seems that mutt > happil

Re: IMAP regression after rev 5024

off-list, it was confirmed that this patch fixes things. And after a little more thought, I understand why :) So I've pushed it. On Sunday, 01 April 2007 at 12:46, Brendan Cully wrote: > I don't see this. Can you run mutt with -d3 and send me ~/.muttdebug0? > > I haven't worked out how it's broke

Re: [Mutt] #1638: Fails silently if $EDITOR fails

#1638: Fails silently if $EDITOR fails Changes (by brendan): * component: mutt => display Old description: > {{{ > Package: mutt > Version: ? > Severity: normal > > [NOTE: this bug report has been submitted to the debian BTS as > Bug#209244. > Please Cc all your replies to [EMAIL PROTECTED]

Re: [Mutt] #1638: Fails silently if $EDITOR fails

#1638: Fails silently if $EDITOR fails Changes (by brendan): * status: new => closed * resolution: => fixed Comment: Fixed in [527589b0b7dd] -- Ticket URL:

Re: [Mutt] #2839: GnuPG and GnuPG clients unsigned data injection

#2839: GnuPG and GnuPG clients unsigned data injection vulnerability Changes (by brendan): * component: mutt => crypto * milestone: => 1.6 Old description: > {{{ > Forwarding #413688 here as well... > > The attached mbox is available at http://bugs.debian.org/413688. > > - Forwarde

Re: [Mutt] #2646: check_new incorrectly uses mh_seq_unseen

#2646: check_new incorrectly uses mh_seq_unseen Changes (by brendan): * milestone: => 1.6 Old description: > {{{ > When using MH-format mailboxes, mutt monitors any sequence for new mail. > It should instead use the sequence defined by mh_seq_unseen. > > With this behavior, replying to a mes

Re: [Mutt] #2646: check_new incorrectly uses mh_seq_unseen

#2646: check_new incorrectly uses mh_seq_unseen Comment (by Brendan Cully): {{{ Reading over mh.c, the logic for reading unseen looks correct. But I did notice an off-by-one in mhs_alloc that looks like it could cause mutt to randomly discover new mail depending on whatever happened to be in

Re: [Mutt] #2646: check_new incorrectly uses mh_seq_unseen

#2646: check_new incorrectly uses mh_seq_unseen Comment (by brendan): Reading over mh.c, the logic for reading unseen looks correct. But I did notice an off-by-one in mhs_alloc that looks like it could cause mutt to randomly discover new mail depending on whatever happened to be in mhs->flags

Re: [Mutt] #2682: mutt should let me specify the Sender: header

#2682: mutt should let me specify the Sender: header Old description: > {{{ > mutt should let me compose messages and specify a Sender: field. Instead, > mutt silently drops the Sender: field that I add in. > > For instance, RFC2822 gives us the sample where John's secretary Michael > sends a mes

Re: [Mutt] #2682: mutt should let me specify the Sender: header

#2682: mutt should let me specify the Sender: header Changes (by brendan): * status: new => closed * resolution: => fixed Comment: I've applied a slightly modified version of your path (which does depend on !privacy, though I don't think anyone is using mixmaster anymore). -- Ticket U

Re: [Mutt] #2820: Mutt doesn't build with --without-wc-funcs

#2820: Mutt doesn't build with --without-wc-funcs Changes (by brendan): * status: new => closed * resolution: => fixed Old description: > {{{ > When I configure Mutt using --without-wc-funcs (this should be better > under Mac OS X as its wcwidth function is buggy), I get the following > e

Re: [Mutt] #2811: Bug#413014: mutt: Handling of e-mails with

#2811: Bug#413014: mutt: Handling of e-mails with multiple Message-IDs Changes (by brendan): * priority: minor => trivial * type: defect => enhancement Old description: > {{{ > > Hi, > > the following was submitted as Debian bug #413014: > > - Forwarded message from Mark Brown <[EMAIL

Re: [Mutt] #2791: problems with filename MIME parameter and newlines

#2791: problems with filename MIME parameter and newlines Changes (by brendan): * component: mutt => display Old description: > {{{ > Create a file with embedded newlines. Attach it in mutt. Mail it. View > the results in mutt and see that part of the filename ends up shown as > attachmen

Re: [Mutt] #2776: Header colors not applied to MIME subpart headers

#2776: Header colors not applied to MIME subpart headers Changes (by brendan): * component: mutt => display Old description: > {{{ > Header colors (e.g., "color hdrdefault yellow black") are not applied to > the headers in MIME subparts when displaying headers. The headers are > shown in the

Re: [Mutt] #2386: underscore problems of chinese filename

#2386: underscore problems of chinese filename Changes (by brendan): * status: new => closed * resolution: => wontfix Old description: > {{{ > When viewing the attachment with chinese filename with external program, > the chinese words of the filename shown in the title bar is underscores

Re: [Mutt] #2168: :my_hdr CC: command sets To: field

#2168: :my_hdr CC: command sets To: field Old description: > {{{ > The my_hdr CC: \"Guess Who\" <[EMAIL PROTECTED]> commands appears to set > the To: field instead of the CC field in the latest Debian release of > mutt, either through the .muttrc file or mutt command line. The my_hdr > To: com

Re: [Mutt] #1881: muttbug utilizes localized messages

#1881: muttbug utilizes localized messages Changes (by brendan): * status: assigned => closed * resolution: => fixed Old description: > {{{ > Package: mutt > Version: 1.4.2.1i > Severity: normal > > -- Please type your report below this line > > This one is really funny: > If LC_MESSAGES

Re: [Mutt] #1809: false new mail notifications in MH folder

#1809: false new mail notifications in MH folder Changes (by brendan): * status: new => closed * resolution: => fixed Old description: > {{{ > Package: mutt > Version: 1.5.6i > Severity: normal > > -- Please type your report below this line > > I get false "new mail in ..." notifications.

Re: [Mutt] #1843: cannot read some s/mime signed messages

#1843: cannot read some s/mime signed messages Changes (by brendan): * status: assigned => closed * resolution: => worksforme Old description: > {{{ > Package: mutt > Version: 1.5.5.1-200401 > Severity: normal > > -- Please type your report below this line > > Mutt is unable to display s/

Re: [Mutt] #755: Strange behaviour when attaching files on filename

#755: Strange behaviour when attaching files on filename completion Changes (by brendan): * status: new => closed * resolution: => fixed * component: mutt => display Old description: > {{{ > Package: mutt > Version: 1.3.21i > Severity: normal > > -- Please type your report below this l

Re: [Mutt] #902: Generated boundary was in attached file

#902: Generated boundary was in attached file Changes (by brendan): * status: new => closed * resolution: => fixed Old description: > {{{ > Package: mutt > Version: 1.3.23.2i > Severity: normal > > -- Please type your report below this line > > I have recently sent a message which contain

Re: [Mutt] #1641: Mutt does not quit when receiving new messages

#1641: Mutt does not quit when receiving new messages Changes (by brendan): * status: new => closed * resolution: => duplicate Old description: > {{{ > Package: mutt > Version: 1.5.4-1 > Severity: normal > > -- Please type your report below this line > > I have Mutt here with a Maildir ma