Re: trial conversion from gnats to trac

ow. 750GB doesn't go as far as it used to... should be fixed now. On Thursday, 29 March 2007 at 09:58, Armin Wolfermann wrote: > * Brendan Cully <[EMAIL PROTECTED]> [27.03.2007 04:59]: > > I've just done a trial conversion of the gnats BTS to trac: > > > > http://dev.mutt.org/trac/ > > > > I've

Re: mutt cache sensitivity

On Wednesday, 28 March 2007 at 17:32, Kyle Wheeler wrote: > On Wednesday, March 28 at 02:07 PM, quoth Brendan Cully: > >>It seems to me that mutt should cache messages to a temporary location and > >>only move them into the official message cache once the message has been > >>fully downloaded. >

Re: mutt cache sensitivity

On Wed, Mar 28, 2007 at 05:32:47PM -0600, Kyle Wheeler wrote: > hurry, so I kill mutt (ctrl-\, because ctrl-c won't stop a download). > The cache will be corrupted, because mutt didn't get a chance to > unlink it out of the cache. That's a good example. It also means mutt won't get a chance to

Re: mutt cache sensitivity

Hi, * Paul Walker [07-03-29 11:23:47 +0100] wrote: On Wed, Mar 28, 2007 at 05:32:47PM -0600, Kyle Wheeler wrote: hurry, so I kill mutt (ctrl-\, because ctrl-c won't stop a download). The cache will be corrupted, because mutt didn't get a chance to unlink it out of the cache. That's a good

Re: mutt cache sensitivity

Hi, * Brendan Cully [07-03-28 18:06:14 -0700] wrote: It seemed like it might be nice to validate the cache file on fetch if possible. At first I thought I'd just stat the file and compare its size with the size stored in the headers, but there doesn't seem to be an appropriate combination of fi

Re: mutt cache sensitivity

On Thu, Mar 29, 2007 at 12:20:52PM +, Rocco Rutte wrote: > Once we find a solution for aborted writes, I think the user is > responsible for maintaince of the cache as he's it now for header cache > too. And this is one of the reasons I don't like the header cache much. It makes things faster

Re: mutt cache sensitivity

Hi, * Paul Walker [07-03-29 14:30:48 +0100] wrote: Once we find a solution for aborted writes, I think the user is responsible for maintaince of the cache as he's it now for header cache too. And this is one of the reasons I don't like the header cache much. It makes things faster, but I'm k

Re: mutt cache sensitivity

On Thursday, March 29 at 02:34 PM, quoth Rocco Rutte: Second, these problems are more or less solved. The header cache does checksum validation on its own, so we only need to bump an internal id field upon each incompatible layout change. Mutt then silently does the right thing. The crashes are

Re: mutt cache sensitivity

On Thursday, March 29 at 11:23 AM, quoth Paul Walker: hurry, so I kill mutt (ctrl-\, because ctrl-c won't stop a download). The cache will be corrupted, because mutt didn't get a chance to unlink it out of the cache. That's a good example. It also means mutt won't get a chance to unlink the f

Re: mutt cache sensitivity

On Thursday, March 29 at 12:33 PM, quoth Rocco Rutte: Ideally, the tempfile resides in the final target directory to avoid lengthy buffer copies for large messages (e.g. you wait ages for a 50 MB message to download and then some more time of moving it from tmpdir to cache dir). If the tempfile

Re: mutt cache sensitivity

On Thursday, 29 March 2007 at 12:33, Rocco Rutte wrote: > Hi, > I think we should take a database transaction approach with a tempfile: open > a tempfile, write the file and afterwards rename (i.e. commit) with blocking > all signals. > Ideally, the tempfile resides in the final target director

Re: [PATCH] Remove absolute paths from gpg.rc

Hi Thomas, On Thursday, March 15, 2007 at 12:54:37 -0400, Thomas E. Dickey wrote: > Making it [gpg path] configurable from a single point is probably a > better way to go Good idea: What about the attached additional patch? It makes use of $my_variables to allow a single point of configurat

mutt/2870: color index foo foo ~h pattern causes many fileops on resync only

>Number: 2870 >Notify-List: >Category: mutt >Synopsis: color index foo foo ~h pattern causes many fileops on resync >only >Confidential: no >Severity: normal >Priority: medium >Responsible:mutt-dev >State: open >Keywords: >Class: s

Re: mutt cache sensitivity

Hi, * Kyle Wheeler [07-03-29 08:44:48 -0600] wrote: On Thursday, March 29 at 12:33 PM, quoth Rocco Rutte: Ideally, the tempfile resides in the final target directory to avoid lengthy buffer copies for large messages (e.g. you wait ages for a 50 MB message to download and then some more time o

Re: mutt cache sensitivity

On Thursday, 29 March 2007 at 08:14, Brendan Cully wrote: > I'll add a bcache_move operation and create the tempfile as id.tmp, > then rename it to id. rename should be atomic, so there's no need for > signal handling, and if we use a fixed name, the natural result is > that it'll simply get overwr

Re: mutt cache sensitivity

On Thursday, 29 March 2007 at 12:20, Rocco Rutte wrote: > Hi, > For example, messages may get changed server-side (at least for POP since > IIRC there's no exact specification of how the checksum per message is to be > computed, or users may edit IMAP message manually on the server) without > mu

Re: [Mutt] #2868: $implicit_autoview shouts error for nothing

#2868: $implicit_autoview shouts error for nothing Changes (by ab): * priority: minor => blocker * resolution: => wontfix * status: new => closed * component: MIME => mutt Comment: BC> This bug report is likely to be lost when I do the final import, I'm afraid. No problem,

Re: trial conversion from gnats to trac

On Wednesday, 28 March 2007 at 18:57, Steve Kennedy wrote: > On Wed, Mar 28, 2007 at 10:45:31AM -0700, Brendan Cully wrote: > > > On Monday, 26 March 2007 at 19:58, Brendan Cully wrote: > > > Hi all, > > > I've just done a trial conversion of the gnats BTS to trac: > > > http://dev.mutt.org/trac/

Re: [PATCH] Re: Bug#226500: mutt: "a" (alias) command fails if

On Monday, 26 March 2007 at 00:02, Christoph Berg wrote: > tags 226500 + patch > thanks > > # HG changeset patch > # User Christoph Berg <[EMAIL PROTECTED]> > # Date 1174860003 -7200 > # Node ID a9ce9fc0185bb9afff31ee571a120134d688b0f4 > # Parent 82d3e0a90f91a2c41b72d14903c0196bfd7c06e3 > Use ~/.

Re: mutt/2538: "make -j2 dist" does not work (bad dependency?)

Synopsis: "make -j2 dist" does not work (bad dependency?) State-Changed-From-To: open->closed State-Changed-By: brendan State-Changed-When: Fri, 30 Mar 2007 00:45:19 +0200 State-Changed-Why: This is fixed in tip (at least make -j2 and make -j2 dist work for me now) Comment added by brendan

Re: change_folder_next patch

On Monday, 05 March 2007 at 13:43, Antoine Reilles wrote: > Hi, > > A patch to add a (change_folder_next) option to mutt was proposed long > time ago. It allow the change-folder command to start at the folder > after the current folder. The reason is that it may be annoying > that the 'c' (change

Re: What's needed for mutt 1.6?

On Saturday, 17 March 2007 at 02:38, Matthias Andree wrote: > Paul Walker <[EMAIL PROTECTED]> writes: > > > On Sat, Mar 17, 2007 at 01:11:18AM +0100, Matthias Andree wrote: > > > >> Yup, these are just too many keypresses if you're not using that > >> folder=... stuff. > > > > I still can't quite

Re: mutt/2870: color index foo foo ~h pattern causes many fileops

The following reply was made to PR mutt/2870; it has been noted by GNATS. From: Michael Elkins <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: mutt/2870: color index foo foo ~h pattern causes many fileops on resync only Date: Thu, 29 Mar 2007 18:44:04 -0700 On Thu, Mar 29, 20

Re: [Mutt] #2790: re-executing a "too long" 'color body ...' cmd

#2790: re-executing a "too long" 'color body ...' cmd causes segv crash after a while Comment (by me): I just did a test running Mutt under valgrind with the following in my ~/.muttrc : color body green white 'this is a really long string that has an (optional|opt) field inside of it and wil

Re: [Mutt] #2869: This is a test of the trac gateway to mutt-dev

#2869: This is a test of the trac gateway to mutt-dev Comment (by bac): Test from another account -- Ticket URL:

Re: mutt/2800: mutt crashes if piped mail to send and sendmail

The following reply was made to PR mutt/2800; it has been noted by GNATS. From: Michael Elkins <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: mutt/2800: mutt crashes if piped mail to send and sendmail fails. Date: Thu, 29 Mar 2007 20:09:45 -0700 --sdtB3X0nJg68CQEu Content-T

Re: mutt/2870: color index foo foo ~h pattern causes many fileops

The following reply was made to PR mutt/2870; it has been noted by GNATS. From: Marc MERLIN <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mutt/2870: color index foo foo ~h pattern causes many fileops Date: Thu, 29 Mar 2007 19:48:44 -0700 On Fri, Mar 30, 2007 at 04:

Re: mutt/2800: mutt crashes if piped mail to send and sendmail fails.

The following reply was made to PR mutt/2800; it has been noted by GNATS. From: Brendan Cully <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: mutt/2800: mutt crashes if piped mail to send and sendmail fails. Date: Thu, 29 Mar 2007 21:10:18 -0700 On Monday, 26 February 2007 at 02:47,

Re: mutt/2800: mutt crashes if piped mail to send and sendmail fails.

Synopsis: mutt crashes if piped mail to send and sendmail fails. State-Changed-From-To: open->closed State-Changed-By: brendan State-Changed-When: Fri, 30 Mar 2007 06:51:00 +0200 State-Changed-Why: fixed in http://dev.mutt.org/hg/mutt/rev/359d9fbb5fda Comment added by brendan on Fri, 30 Ma

Re: imap/2543: auth_sasl does not fallback on IMAP_CMD_BAD

Synopsis: auth_sasl does not fallback on IMAP_CMD_BAD State-Changed-From-To: open->closed State-Changed-By: brendan State-Changed-When: Fri, 30 Mar 2007 06:53:44 +0200 State-Changed-Why: fixed some time ago. 1.5.14 works correctly at any rate. Comment added by brendan on Fri, 30 Mar 2007 0

mutt: 5 new changesets

5 new changesets in mutt: http://dev.mutt.org/hg/mutt/rev/359d9fbb5fda changeset: 5024:359d9fbb5fda tag: tip user:Brendan Cully <[EMAIL PROTECTED]> date:Thu Mar 29 21:08:28 2007 -0700 summary: Do not page sendmail error in batch mode. (closes: #2800) http://dev.mutt.

Re: What's needed for mutt 1.6?

On Friday, 23 February 2007 at 13:40, Jorgen Hermanrud Fjeld wrote: > Hello! > > On 2007-02-22 09:30:33, Brendan Cully wrote: > > So, I'd like to hear once again which patches everyone would > > like to see in 1.6 (and which patches people object to). > > > I would like my imap_recent patch, it i

Re: change_folder_next patch

On 29-03-2007 16:03:15 -0700, Brendan Cully wrote: > On Monday, 05 March 2007 at 13:43, Antoine Reilles wrote: > > A patch to add a (change_folder_next) option to mutt was proposed long > > time ago. It allow the change-folder command to start at the folder > > after the current folder. The reason