headers
Brendan Cully | 1 Oct 18:06
Gravatar

Re: Changeset 2050b44407bf and qdbm

On Monday, 29 September 2008 at 17:47, Kyle Wheeler wrote:
> After changeset 2050b44407bf, I’m unable to compile with qdbm. I see that 
> configure.in is testing for $use_qdbm, but never sets it. Equivalent logic 
> is used in the tokyocabinet stuff, but I don’t see how that could possibly 
> work *either*, since $use_tokyocabinet is never set.

Ah. It looks like this bug is tripped only if you explicitly set
--use-qdbm or --use-tokyocabinet. If you leave out the options and let
mutt select the first one it finds, everything's fine. I'll push a
modified version of your patch.

> A small patch is attached that corrects that and lets it build properly.
>
> ~Kyle

> diff -r 9e569296190b configure.ac
> +++ b/configure.ac	Mon Sep 29 17:47:29 2008 -0500
> @@ -851,7 +851,7 @@
>           db_found=yes],
>          [CPPFLAGS="$OLDCPPFLAGS"
>           LDFLAGS="$OLDLDFLAGS"]))
> -      if test -n "$with_tokyocabinet" && test "$use_tokyocabinet" != yes
> +      if test -n "$with_tokyocabinet" && test "$db_found" != yes
>        then
>          AC_MSG_ERROR([Tokyo Cabinet could not be used. Check config.log for details.])
>        fi
> @@ -883,7 +883,7 @@
>          [CPPFLAGS="$OLDCPPFLAGS"
>           LDFLAGS="$OLDLDFLAGS"])
>        LIBS="$saved_LIBS"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brendan Cully | 2 Oct 09:00
Gravatar

mutt: new changeset

New changeset in mutt:

http://dev.mutt.org/hg/mutt/rev/13a831a945be
changeset:   5538:13a831a945be
branch:      HEAD
tag:         tip
user:        Brendan Cully <brendan <at> kublai.com>
date:        Wed Oct 01 09:33:39 2008 -0700
summary:     Clean up autoconf header cache engine selection.

--

-- 
Repository URL: http://dev.mutt.org/hg/mutt
Permalink | Reply | 0 comments |
headers
Mutt | 2 Oct 23:13

Re: [Mutt] #2995: Mutt is folding subject line folds using a tab,

#2995: Mutt is folding subject line folds using a tab, which appears to be against
RFC 2822
----------------------+-----------------------------------------------------
  Reporter:  frnkblk  |       Owner:  mutt-dev                  
      Type:  defect   |      Status:  new                       
  Priority:  minor    |   Milestone:  1.6                       
 Component:  mutt     |     Version:  1.5.17                    
Resolution:           |    Keywords:  header folding white-space
----------------------+-----------------------------------------------------

Comment(by Frank Bulk):

 {{{
 Note: unfolding is discussed in the newly released RFC 5322, which
 supersedes 2822.  That may be relevant to this bug.

 Frank

 --
 Ticket URL: <http://dev.mutt.org/trac/ticket/2995#comment:>
 }}}

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2995#comment:>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 0 comments |
headers
Sergei Gerasenko | 3 Oct 21:08
Favicon

curious about some implementation issues

I've been curious about two things about mutt.

1) If I understand correctly, marking a message as "read" involves
inserting a "Status:RO" line into the header of the message. How does
mutt do that pricesely? I mean, is it modifying the file in place or
does it create a temporary file, which is then renamed? I've been
ignorant of this and similar problems (e.g. working with flat files) for
two long and it's about time I ask!

2) How does mutt make sure that while it's modifying the mailbox, the
delivery agent is not adding something to it at the same time?

Thanks for your time.

Sergei
Permalink | Reply | 4 comments |
headers
Kyle Wheeler | 3 Oct 23:14

Re: curious about some implementation issues

On Friday, October  3 at 03:08 PM, quoth Sergei Gerasenko:
> 1) If I understand correctly, marking a message as "read" involves 
> inserting a "Status:RO" line into the header of the message.

That's only true of messages stored in mbox and MH format mailboxes. 
Maildir mailboxes store that information in the name of the message 
file.

> How does mutt do that pricesely? I mean, is it modifying the file in 
> place or does it create a temporary file, which is then renamed? 

In my experience, it seems to be the latter...

> 2) How does mutt make sure that while it's modifying the mailbox, 
> the delivery agent is not adding something to it at the same time?

In the case of mbox, the mailbox is locked using the dot-lock program. 
The exact method used depends on the filesystem... the fastest method 
is an fcntl lock, but NFS sometimes doesn't have a functional lock 
protocol, so dot-lock files are created. You can read a more detailed 
explanation of what goes on in general on Wikipedia: 
http://en.wikipedia.org/wiki/Mbox

~Kyle
--

-- 
They say marriages are made in Heaven. But so is thunder and 
lightning.
                                                      -- Clint Eastwood
Permalink | Reply | 2 comments |
headers
Dinusha & Namal | 4 Oct 15:28
Favicon

Re: curious about some implementation issues

Hello Mutt Administrators,

Could you please unsubscribe me from the email alias mutt-dev <at> mutt.org.

Thank you
Namal

Sergei Gerasenko wrote:

>I've been curious about two things about mutt.
>
>1) If I understand correctly, marking a message as "read" involves
>inserting a "Status:RO" line into the header of the message. How does
>mutt do that pricesely? I mean, is it modifying the file in place or
>does it create a temporary file, which is then renamed? I've been
>ignorant of this and similar problems (e.g. working with flat files) for
>two long and it's about time I ask!
>
>2) How does mutt make sure that while it's modifying the mailbox, the
>delivery agent is not adding something to it at the same time?
>
>Thanks for your time.
>
>Sergei
>
>  
>
Permalink | Reply | 0 comments |
headers
Sergei Gerasenko | 4 Oct 00:24
Favicon

Re: curious about some implementation issues

> That's only true of messages stored in mbox and MH format mailboxes.  
> Maildir mailboxes store that information in the name of the message  
> file.

Yes, I was talking only about mbox files. Good point.

> In the case of mbox, the mailbox is locked using the dot-lock program.  
> The exact method used depends on the filesystem... the fastest method is 
> an fcntl lock, but NFS sometimes doesn't have a functional lock  
> protocol, so dot-lock files are created. You can read a more detailed  
> explanation of what goes on in general on Wikipedia:  
> http://en.wikipedia.org/wiki/Mbox

Cool. The only thing I don't understand is that it seems that all file
locking in Unix is "advisory" and it's totally up to the program
accessing the file whether to respect it or not. Is that true?
Permalink | Reply | 1 comment |
headers
Kyle Wheeler | 4 Oct 01:21

Re: curious about some implementation issues

On Friday, October  3 at 06:24 PM, quoth Sergei Gerasenko:
> Cool. The only thing I don't understand is that it seems that all 
> file locking in Unix is "advisory" and it's totally up to the 
> program accessing the file whether to respect it or not. Is that 
> true?

Yes, exactly. What that essentially means is that in order for locking 
to work, everyone involved has to agree to use the same mechanism, 
which can be a problem given that there are three or more "standard" 
ways of doing file locks on Unix systems.

Generally, though, the most common method is to use fcntl if available 
and dot-locking as a fall back. That's what mutt does, and that what 
most MTAs do as well.

~Kyle
--

-- 
The sharpest criticism often goes hand in hand with the deepest 
idealism and love of country.
                                                   -- Robert F. Kennedy
Permalink | Reply | 0 comments |
headers
Mutt | 7 Oct 00:10

[Mutt] #3123: [patch] make mutt build with without HAVE_LIBIDN

#3123: [patch] make mutt build with without HAVE_LIBIDN
-----------------------------+----------------------------------------------
 Reporter:  gp               |       Owner:  mutt-dev
     Type:  defect           |      Status:  new     
 Priority:  major            |   Milestone:          
Component:  mutt             |     Version:          
 Keywords:  compilation fix  |  
-----------------------------+----------------------------------------------
 mutt_idna.o: In function `mutt_addr_for_display':
 /home/gregory/dev/mutt/mutt_idna.c:248: undefined reference to `check_idn'
 mutt_idna.o: In function `mutt_addrlist_to_local':
 /home/gregory/dev/mutt/mutt_idna.c:219: undefined reference to `check_idn'
 collect2: ld returned 1 exit status

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3123>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 2 comments |
headers
Mutt | 7 Oct 16:25

Re: [Mutt] #3122: mutt doesn't build without idn support

#3122: mutt doesn't build without idn support
---------------------+------------------------------------------------------
  Reporter:  pdmef   |       Owner:  mutt-dev
      Type:  defect  |      Status:  new     
  Priority:  major   |   Milestone:  1.6     
 Component:  build   |     Version:  1.5.18  
Resolution:          |    Keywords:          
---------------------+------------------------------------------------------

Comment(by pdmef):

 See #3123.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3122#comment:1>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 0 comments |

Gmane