Re: What's needed for mutt 1.6? (Debian patches)

[TAKAHASHI Tamotsu]

Hi TAKIZAWA-san,

Could you explain the difference between
1.5.6-assumed.1 (Christoph's one) and 1.5.14-assumed.1?
I have a poor memory.


* Mon Feb 26 2007 TAKIZAWA Takashi <[EMAIL PROTECTED]>
> On Fri, Feb 23, 2007 at 11:11:49PM -0800,
>  Brendan Cully wrote:
> 
> > On Friday, 23 February 2007 at 00:04, Christoph Berg wrote:
> > > > >assumed-charset might be a good idea too.
> > > 
> > > http://svn.df7cb.de/debian/mutt/trunk/debian/patches/features/assumed-charset
> > 
> > I've applied this one.
> 
> The above-mentioned patch is very old. 
> New patches are the following three. 
> http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tt+tamo.assumed_charset.1
> http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tt.attach_charset.1
> http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tt.linear_white_space.1

Maybe it is not enough to say "it's very old."
Why should Brendan apply the new ones?

Concerning "+tamo" part, I've forgotten most of what I did.
But here are some:
http://bugs.mutt.org/2218
http://marc.theaimsgroup.com/?l=mutt-dev&m=110717251200761&w=2
These are, for some users (like Alain), quite serious changes.

-- 
tamo

Support for 'folder' capability keys for Mutt. Assistence needed.

[Rob Meijer]

After first having looked at creating patches for mutt for the full
implementation, I am now actively working on making a separate library
for implementing 'folder' capability keys, that when finished could be called
from more lightweight patches to mutt.

As these patches will need to go to many places, and I would not want to
violate any overall design doing so, I would like to know if someone on the
list who has a thorough understanding of mutt's design would be interested
in working with me on this.

The 'mail capability key' or mck library is meant as an anti-spam solution
using a 'folder extended' e-mail address as a capability key.

The mck library aims to implements the concept of using key-extended
e-mail addresses as capabilities in order to countermeasure the SPAM
problem.

The idea for this library came to be as a result of a discussion on the
cap-talk mailing list about using capabilities to solve the SPAM problem.

The concept is that by using the folder notation +@
where instead of a regular folder we use a password capability, we can
make e-mail addresses that can be used according to capability
paradigms. That is, the e-mail address becomes a single  unforgeable
and sharable reference to the target, that can be revoked when at
any time SPAM is received trough it, without the high impact of actually
requiring a new e-mail address.

The libmck library tries to implement the address as key in such a way
that the following specifications are met:

1)  A mailkey should be unforgeable.
2)  It should be possible to trace back a mailkey to the entity to what
it was originally issued.
3)  It should be possible and simple to filter (revoke) 'all' mailkeys
issued to a single entity.
4)  It should be possible to trace back 'when' a mailkey was issued.
5)  It should be possible to give a mailkey a certain validity period.
6)  It should be possible and simple to filter (revoke) a single mailkey.
7)  Sharing mailkeys as way of introduction should be encouraged, thus
new mailkeys should be created in some quantities in communication with
known peers.
8)  It should be possible to use mailkeys with 'unpatched' mailing list
servers.
9)  It should be possible to periodically start using a replacement master
secret key for mailkey generation without implicitly invalidating
mailkeys generated with the old key.
10) It should be possible to 'petname' individual keys in order to keep
track of keys used for introduction by peers.

Libmck is not yet completed, I am actively working on the implementation.
As the prime goal for this library is usage from a patched version of mutt
(and possibly procmail), I am searching for someone who would be
interested in working with me on this. Especially looking at the interface
libmck offers and finding the cleanest way to patch libmck usage into
mutt, while
not violating the overall design.

Rob

Rob

[2007-02-26] CVS repository changes

[Thomas Roessler]

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.


2007-02-25 01:32:31  Brendan Cully  <[EMAIL PROTECTED]>  (brendan)

* account.c, account.h, imap/imap.c, imap/message.c, main.c,
mutt_sasl.c: Update copyrights.

2007-02-24 07:01:24  Takashi TAKIZAWA  <[EMAIL PROTECTED]>  (brendan)

* UPDATING, charset.c, charset.h, globals.h, handler.c,
init.h, mutt.h, parse.c, rfc2047.c, rfc2231.c, sendlib.c: Add
$assumed_charset, $file_charset and $strict_mime.

2007-02-24 06:37:32  Brendan Cully  <[EMAIL PROTECTED]>  (brendan)

* globals.h, init.h, main.c, mutt_sasl.c, protos.h, send.c,
sendlib.c, smtp.c, url.c, url.h, Makefile.am, account.c,
account.h, configure.in: This patch adds ESMTP relay support to
mutt.  To use, set $smtp_url to the address of your smtp relay,
in the form:

smtp[s]://[user[:[EMAIL PROTECTED]:port]/

where port defaults to 25 for smtp and 465 for smtps.

You can also set $smtp_authenticators to control which
methods mutt will attempt to use during authentication. See
$imap_authenticators for details.

2007-02-24 06:12:20  Moritz Schulte  <[EMAIL PROTECTED]>
(brendan)

* UPDATING, configure.in, crypt-gpgme.c, crypt-gpgme.h,
crypt-mod-pgp-classic.c, crypt-mod-pgp-gpgme.c,
crypt-mod-smime-classic.c, crypt-mod-smime-gpgme.c,
crypt-mod.h, crypt.c, cryptglue.c, init.h, mutt.h, mutt_crypt.h,
Makefile.am: PKA signature verification via GPGME, controlled
by $crypt_use_pka.

2007-02-24 05:47:35  Vincent Lefevre  <[EMAIL PROTECTED]>  (brendan)

* po/fr.po: Updated French translation.

Re: mutt/2799: Avoid gpgme (AM_PATH_GPGME) dependency for autoconf

[Werner Koch]

The following reply was made to PR mutt/2799; it has been noted by GNATS.

From: Werner Koch <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: 
Subject: Re: mutt/2799: Avoid gpgme (AM_PATH_GPGME) dependency for autoconf
Date: Mon, 26 Feb 2007 13:15:28 +0100

 On Sun, 25 Feb 2007 02:32, [EMAIL PROTECTED] said:
 
 > To be able to run autoconf, one needs to have gpgme installed due to the use 
 > of the AM_PATH_GPGME macro. See 
 > . This 
 > dependency should be avoided.
 
 gpgme.m4 should be added to the m4/ directory or if not possible the
 old acinclude.m4 file.
 
 
 
 

OT: SPAM filtering at the MUA? (was: Re: Support for 'folder' capability keys for Mutt. Assistence needed.)

[Dave]

On Mon, Feb 26, 2007 at 09:12:35AM +0100, Rob Meijer wrote:

> The 'mail capability key' or mck library is meant as an anti-spam solution
> using a 'folder extended' e-mail address as a capability key.

Isn't the MDA (i.e., procmail) and the MTA (i.e., qmail-inject) the correct
place to implement this?  It might work something like this: {
 MDA: {
  A piece of mail comes in from the MTA.  The MDA looks to see whether the mck's
  been revoked; if so, it bounces the message, and aborts.  Next, the MDA sets
  appropriate header fields based on attributes of the mck in use.  It then
  delivers the message.
 }; MTA {
  A piece of mail arrives from the MUA.  The MTA looks to see if the From
  address has a valid mck; if not, it creates a new mck assigned to the
  recipient of the message.  It adds an appropriate header or two to annoy
  recipients, and sends the message off to the MTA proper.
}};

Implementing equivalent functionality in the MUA, IMHO - even as an external
library, is bloating the MUA for something that isn't even its job (even worse
than the recent decision to bundle SMTP support into Mutt).

> The mck library aims to implements the concept of using key-extended
> e-mail addresses as capabilities in order to countermeasure the SPAM
> problem.
> 
> The concept is that by using the folder notation +@
> where instead of a regular folder we use a password capability, we can
> make e-mail addresses that can be used according to capability
> paradigms. That is, the e-mail address becomes a single  unforgeable
> and sharable reference to the target, that can be revoked when at
> any time SPAM is received trough it, without the high impact of actually
> requiring a new e-mail address.

Note that many SPAMbots remove the SMTP resource (your "password") from email
addresses they send to their lists, so at best, this would only be a partial
solution.  (In particular, you'd still need to deal with mail sent to
"[EMAIL PROTECTED]" somehow.)

A more correct solution is to have "user" be a SPAM trap rather than your real
email addy, so "smart" SPAM bots end up getting the short end of the stick.
Also, make sure that the resource starts with something canned (say, 'pswd'), so
stupid SPAM bots that don't recognize '+' as a legit character in an email addy
(so "[EMAIL PROTECTED]" becomes "[EMAIL PROTECTED]" in their lists) can have
their mail redirected to [EMAIL PROTECTED], and trapped along with your other 
SPAM.

> The libmck library tries to implement the address as key in such a way
> that the following specifications are met:
> 
> 1)  A mailkey should be unforgeable.
> 2)  It should be possible to trace back a mailkey to the entity to what
> it was originally issued.
> 3)  It should be possible and simple to filter (revoke) 'all' mailkeys
> issued to a single entity.
> 4)  It should be possible to trace back 'when' a mailkey was issued.
> 5)  It should be possible to give a mailkey a certain validity period.
> 6)  It should be possible and simple to filter (revoke) a single mailkey.
> 7)  Sharing mailkeys as way of introduction should be encouraged, thus
> new mailkeys should be created in some quantities in communication with
> known peers.
> 8)  It should be possible to use mailkeys with 'unpatched' mailing list
> servers.
> 9)  It should be possible to periodically start using a replacement master
> secret key for mailkey generation without implicitly invalidating
> mailkeys generated with the old key.
> 10) It should be possible to 'petname' individual keys in order to keep
> track of keys used for introduction by peers.

If you control your own domain, aren't there systems that satisfy those
requirements already available, that are implemented in the server layer, rather
than at the client end?

HTH,
 - Dave

Re: What's needed for mutt 1.6? (Debian patches)

[TAKIZAWA Takashi]

Hi, Tamotsu-san.

Perhaps the difference is:
  - a bugfix concerning memory allocation
  - "+tamo" part, which is result thing of discussion by Tamotsu and Alain
  - a new patch is safer. 

On Mon, Feb 26, 2007 at 05:01:21PM +0900,
 TAKAHASHI Tamotsu wrote:

> Could you explain the difference between
> 1.5.6-assumed.1 (Christoph's one) and 1.5.14-assumed.1?
> I have a poor memory.
> 
> 
> * Mon Feb 26 2007 TAKIZAWA Takashi <[EMAIL PROTECTED]>
> > On Fri, Feb 23, 2007 at 11:11:49PM -0800,
> >  Brendan Cully wrote:
> > 
> > > On Friday, 23 February 2007 at 00:04, Christoph Berg wrote:
> > > > > >assumed-charset might be a good idea too.
> > > > 
> > > > http://svn.df7cb.de/debian/mutt/trunk/debian/patches/features/assumed-charset
> > > 
> > > I've applied this one.
> > 
> > The above-mentioned patch is very old. 
> > New patches are the following three. 
> > http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tt+tamo.assumed_charset.1
> > http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tt.attach_charset.1
> > http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tt.linear_white_space.1
> 
> Maybe it is not enough to say "it's very old."
> Why should Brendan apply the new ones?
> 
> Concerning "+tamo" part, I've forgotten most of what I did.
> But here are some:
> http://bugs.mutt.org/2218
> http://marc.theaimsgroup.com/?l=mutt-dev&m=110717251200761&w=2
> These are, for some users (like Alain), quite serious changes.

-- 
TAKIZAWA Takashi
http://www.emaillab.org/

Re: What's needed for mutt 1.6?

[Andriy N. Gritsenko]

Hi, Brendan Cully!

Sometime (on Thursday, February 22 at 19:31) I've received something...
>I intend to cut 1.5.14 this weekend. I'd like to make 1.5.15 the last
>proper dev release for 1.6 - that is, feature-freeze after
>1.5.15. So, I'd like to hear once again which patches everyone would
>like to see in 1.6 (and which patches people object to).

>On my list at the moment:
>I'll probably apply my ESMTP patch (*dons flame suit*)
>And I think the configurable umask patch is handy.

>assumed-charset might be a good idea too.

>I do not intend to visit the great config-var rename topic until after
>1.6 by the way. I think it would need too much time to deal with the
>fallout.

When it will be time to include NNTP support into Mutt? It is very
stable for years (as old as century) and is need by many people so they
have to patch all Mutt sources by themself (and still no localizations
are available for NNTP because it's patch).
Please, don't start any war again - using some sorts of external
programs (that are still mail<->news gateways) isn't efficient way to
work with NNTP due to many unavoidable restrictions.

With best wishes.
Andriy.

Re: What's needed for mutt 1.6? (Debian patches)

[Rocco Rutte]

Hi,

* Brendan Cully [07-02-23 23:10:57 -0800] wrote:


It doesn't sound like a bad idea to me. But can someone remind me what
the objections were to the compressed-folder patch?


I don't really like the implementation because it enforces mbox. It 
would be much nicer (and have a much better design) if it could just 
uncompress the file and let mutt itself decide what to do with it.


  bye, Rocco
--
:wq!

Re: What's needed for mutt 1.6?

[Brendan Cully]

On Monday, 26 February 2007 at 18:37, Andriy N. Gritsenko wrote:
> Hi, Brendan Cully!
> 
> Sometime (on Thursday, February 22 at 19:31) I've received something...
> >I intend to cut 1.5.14 this weekend. I'd like to make 1.5.15 the last
> >proper dev release for 1.6 - that is, feature-freeze after
> >1.5.15. So, I'd like to hear once again which patches everyone would
> >like to see in 1.6 (and which patches people object to).
> 
> >On my list at the moment:
> >I'll probably apply my ESMTP patch (*dons flame suit*)
> >And I think the configurable umask patch is handy.
> 
> >assumed-charset might be a good idea too.
> 
> >I do not intend to visit the great config-var rename topic until after
> >1.6 by the way. I think it would need too much time to deal with the
> >fallout.
> 
> When it will be time to include NNTP support into Mutt? It is very
> stable for years (as old as century) and is need by many people so they
> have to patch all Mutt sources by themself (and still no localizations
> are available for NNTP because it's patch).
> Please, don't start any war again - using some sorts of external
> programs (that are still mail<->news gateways) isn't efficient way to
> work with NNTP due to many unavoidable restrictions.

I'm still not convinced mutt should be a newsreader. But Michael
Elkins has mentioned an interest in creating a plug-in system for
mutt, which I think would be a fairly nice way to add NNTP support
without having to patch mutt itself. I think it's a good idea, and one
I've even started on myself a couple of times in the past.

Re: What's needed for mutt 1.6?

[Brendan Cully]

On Sunday, 25 February 2007 at 19:08, Matthias Andree wrote:
> Brendan Cully <[EMAIL PROTECTED]> writes:
> 
> > I intend to cut 1.5.14 this weekend. I'd like to make 1.5.15 the last
> > proper dev release for 1.6 - that is, feature-freeze after
> > 1.5.15. So, I'd like to hear once again which patches everyone would
> > like to see in 1.6 (and which patches people object to).
> 
> Haven't been able to look into recent developments, an IMAP folder
> browser would be nice, and I have seen patches floating around, but am
> unaware of their actuality or quality.

mutt's had IMAP folder browsing for about as long as I can
remember. It's got a lot of warts, but I think it mostly works.

Re: What's needed for mutt 1.6?

[Rocco Rutte]

Hi,

* Brendan Cully [07-02-22 09:30:33 -0800] 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).


What I really love is the replacement patch for format=flowed messages 
as a result of the mutt-ng fork. The code is much simpler (and easier to 
maintain) and it's capable of really flowing text according to user's 
settings.


Also still open: we can't really restore flags from hcache because it 
still stores pointers. I've tried to clean it up several times but 
failed everytime. The only thing which worked was some patch I sent 
which did copy the header-to-be-stored not completely but only the 
interesting parts.


To have the latter fixed is important to get full message flag support 
for POP and a number of other improvements. It would make a 1.6 release 
look better with hcache/body cache in all places...



On my list at the moment:
I'll probably apply my ESMTP patch (*dons flame suit*)


Please add this one.

  bye, Rocco
--
:wq!

Re: What's needed for mutt 1.6? (xterm title)

[Christoph Berg]

Re: Brendan Cully 2007-02-24 <[EMAIL PROTECTED]>
> > Small remark: it seems to have a hardwired set of "good"
> > terminals. Neither or mine (rxvt-unicode and screen-256color-bce)
> > is one it. Or is that just for the default setting, overridable? No
> > ncurses/slang query for this capability?
> 
> The last time I remember this getting heavily discussed, I thought
> someone proposed the approach of having mutt simply expose the current
> folder name etc as variables that could be expanded in a shell
> expansion called from a folder hook. This seems a lot more general and
> elegant to me.

The terminal title might need updating every time the status bar is
updated since there can be message counts etc. Calling a subshell
every time for that sounds a bit unelegant. Besides, the variables
approach would need adding raw escape sequences (which are always the
same, btw) to $status_format which isn't especially nice either.

As another argument for the integration, vim supports setting the
terminal title too.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: What's needed for mutt 1.6? (compressed folders)

[Christoph Berg]

Re: Rocco Rutte 2007-02-26 <[EMAIL PROTECTED]>
> >It doesn't sound like a bad idea to me. But can someone remind me what
> >the objections were to the compressed-folder patch?

I think the main objection is that it breaks if the compressed folder
is opened while the compressed file is modified (e.g. new mail).
Writing back changes from mutt will overwrite the compressed version.
As the main use is for archive folders which either don't get new mail
or will be opened read-only I don't think that restriction is too bad.
(And there could be a check that the mtime of the folder is still the
same - which might already be there, didn't check.)

> I don't really like the implementation because it enforces mbox. It 
> would be much nicer (and have a much better design) if it could just 
> uncompress the file and let mutt itself decide what to do with it.

Some time ago I tried to make it read mboxes given an URL with a
sh+wget wrapper which failed because
http://bugs.debian.org/123&mbox=yes is not a local file, but that
could be fixed.

Generally I would prefer the addition of the (working) patch over
delaying it indefinitely until someone implements something more
elegant.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: What's needed for mutt 1.6?

[Brendan Cully]

On Friday, 23 February 2007 at 03:21, Vincent Lefevre wrote:
> On 2007-02-22 09:30:33 -0800, Brendan Cully wrote:
> > I intend to cut 1.5.14 this weekend. I'd like to make 1.5.15 the last
> > proper dev release for 1.6 - that is, feature-freeze after
> > 1.5.15. 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 use the following patches. Those I've written and those I had to
> modify (because of new code in Mutt or clashes between patches) are
> available on .
> 
> * My "Save History" patch, to be able to save the history between
> sessions.
> 
> http://www.vinc17.org/mutt/patches/patch-1.5.12.vl.savehist.1

I like this one too, and I've applied it.

> * The namequot patch, fixing Mutt's bug 2014 (see bug report).

I don't know about this one. I like mutt's automatic dequoting. It may
be a bit too aggressive, but the patch appears to completely destroy
it.

> * A patch to show the version of the curses library (runtime) with
> "mutt -v".
> 
> http://www.vinc17.org/mutt/patches/patch-1.5.13cvs.vl.curses_version.1

I've applied a variant of this.


pgpAcaiu1fvth.pgp
Description: PGP signature

Re: What's needed for mutt 1.6?

[Rocco Rutte]

Hi,

* Rocco Rutte [07-02-26 16:59:30 +] wrote:

* Brendan Cully [07-02-22 09:30:33 -0800] wrote:


What I really love is the replacement patch for format=flowed messages as a result of the mutt-ng fork. The code is much simpler (and easier to maintain) and it's capable 
of really flowing text according to user's settings.


It needs some style tweaks and I'm still not fully sure if the 
space-stuffing it does it totally right (especially when editing the 
same message several times via compose menu), but anyway:


  


  bye, Rocco
--
:wq!

Re: Support for 'folder' capability keys for Mutt. Assistence needed.

[Brendan Cully]

This sounds a lot like what TMDA already does. And I don't see why it
needs to patch mutt to work.

On Monday, 26 February 2007 at 09:12, Rob Meijer wrote:
> After first having looked at creating patches for mutt for the full
> implementation, I am now actively working on making a separate library
> for implementing 'folder' capability keys, that when finished could be called
> from more lightweight patches to mutt.
> 
> As these patches will need to go to many places, and I would not want to
> violate any overall design doing so, I would like to know if someone on the
> list who has a thorough understanding of mutt's design would be interested
> in working with me on this.
> 
> The 'mail capability key' or mck library is meant as an anti-spam solution
> using a 'folder extended' e-mail address as a capability key.
> 
> The mck library aims to implements the concept of using key-extended
> e-mail addresses as capabilities in order to countermeasure the SPAM
> problem.
> 
> The idea for this library came to be as a result of a discussion on the
> cap-talk mailing list about using capabilities to solve the SPAM problem.
> 
> The concept is that by using the folder notation +@
> where instead of a regular folder we use a password capability, we can
> make e-mail addresses that can be used according to capability
> paradigms. That is, the e-mail address becomes a single  unforgeable
> and sharable reference to the target, that can be revoked when at
> any time SPAM is received trough it, without the high impact of actually
> requiring a new e-mail address.
> 
> The libmck library tries to implement the address as key in such a way
> that the following specifications are met:
> 
> 1)  A mailkey should be unforgeable.
> 2)  It should be possible to trace back a mailkey to the entity to what
> it was originally issued.
> 3)  It should be possible and simple to filter (revoke) 'all' mailkeys
> issued to a single entity.
> 4)  It should be possible to trace back 'when' a mailkey was issued.
> 5)  It should be possible to give a mailkey a certain validity period.
> 6)  It should be possible and simple to filter (revoke) a single mailkey.
> 7)  Sharing mailkeys as way of introduction should be encouraged, thus
> new mailkeys should be created in some quantities in communication with
> known peers.
> 8)  It should be possible to use mailkeys with 'unpatched' mailing list
> servers.
> 9)  It should be possible to periodically start using a replacement master
> secret key for mailkey generation without implicitly invalidating
> mailkeys generated with the old key.
> 10) It should be possible to 'petname' individual keys in order to keep
> track of keys used for introduction by peers.
> 
> Libmck is not yet completed, I am actively working on the implementation.
> As the prime goal for this library is usage from a patched version of mutt
> (and possibly procmail), I am searching for someone who would be
> interested in working with me on this. Especially looking at the interface
> libmck offers and finding the cleanest way to patch libmck usage into
> mutt, while
> not violating the overall design.
> 
> Rob
> 
> Rob

Re: What's needed for mutt 1.6? (compressed folders)

[Christoph Berg]

Re: To Mutt Developers 2007-02-26 <[EMAIL PROTECTED]>
> (And there could be a check that the mtime of the folder is still the
> same - which might already be there, didn't check.)

Looking into the patch it does check the original folder:

int mutt_check_mailbox_compressed (CONTEXT* ctx)
{
  COMPRESS_INFO *ci = (COMPRESS_INFO *) ctx->compressinfo;
  if (ci->size != get_size (ctx->realpath))
  {
FREE (&ctx->compressinfo);
FREE (&ctx->realpath);
mutt_error _("Mailbox was corrupted!");
return (-1);
  }
  return (0);
}

So that moves "possible mail loss" to "error message printed, but mutt
doesn't fix the problem itself".

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: mutt/2799: Avoid gpgme (AM_PATH_GPGME) dependency for autoconf

[Vincent Lefevre]

The following reply was made to PR mutt/2799; it has been noted by GNATS.

From: Vincent Lefevre <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: 
Subject: Re: mutt/2799: Avoid gpgme (AM_PATH_GPGME) dependency for autoconf
Date: Tue, 27 Feb 2007 00:39:03 +0100

 On 2007-02-26 14:05:01 +0100, Werner Koch wrote:
 >  gpgme.m4 should be added to the m4/ directory or if not possible the
 >  old acinclude.m4 file.
 
 I tested the latest CVS without gpgme installed, and it is now OK.
 This bug can be closed.
 
 --=20
 Vincent Lef=E8vre <[EMAIL PROTECTED]> - Web: 
 100% accessible validated (X)HTML - Blog: 
 Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
 

Re: mutt/2799: Avoid gpgme (AM_PATH_GPGME) dependency for autoconf

[Brendan Cully]

Synopsis: Avoid gpgme (AM_PATH_GPGME) dependency for autoconf

State-Changed-From-To: open->closed
State-Changed-By: brendan
State-Changed-When: Tue, 27 Feb 2007 00:54:55 +0100
State-Changed-Why:
gpgme.m4 is now bundled.



 Comment added by brendan on Tue, 27 Feb 2007 00:54:55 +0100 
 

Re: What's needed for mutt 1.6? (compressed folders)

[Cameron Simpson]

On 26Feb2007 18:43, Christoph Berg <[EMAIL PROTECTED]> wrote:
| Re: Rocco Rutte 2007-02-26 <[EMAIL PROTECTED]>
[...]
| > I don't really like the implementation because it enforces mbox. It 
| > would be much nicer (and have a much better design) if it could just 
| > uncompress the file and let mutt itself decide what to do with it.
| 
| Some time ago I tried to make it read mboxes given an URL with a
| sh+wget wrapper which failed because
| http://bugs.debian.org/123&mbox=yes is not a local file, but that
| could be fixed.

Suppose there was a generic folder name intercept hook, eg something like:

  folder-name-close-hook shell-command# takes folder name,
# returns mbox file path
  folder-name-close-hook shell-command   # takes folder name and mbox file 
path

Then you could write an open-hook script (unrealisticly simple):

  #!/bin/sh
  case "$1" in
some-pattern-for-compressed folders)
  tmpf=/tmp/foo
  folderpath=$MAILDIR/$1.gz
  gunzip < "$folderpath" >"$tmpf" && echo "$tmpf"
  ;;
*)exit 0
  ;;
  esac

If the exit status is non-zero, fail the folder open.
If the exit status is zero,
  if the output is empty,
open the folder in the normal builtin fashion
  else
open the pathname returned by the script output,
  which might be a plain mbox or a maildir or an IMAP URL or ...

and folder-name-close-hook script:

  #!/bin/sh
  folderpath=$MAILDIR/$1.gz
  tmpf=$2
  gzip < "$tmpf" >"$folderpath" && rm "$tmpf"

Obviously real hooks would be more elaborate, but the approach seems
agnostic enough to externt.

| Generally I would prefer the addition of the (working) patch over
| delaying it indefinitely until someone implements something more
| elegant.

Me too. It works well enough provided users understand the limitations.
-- 
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/

Deep into the monitor peering, long I sat there wond'ring, fearing,
Doubting, while the disk kept churning, turning yet to churn some more.

"Save!" I said, "You cursed mother! Save my data from before!"
One thing did the phosphors answer, only this and nothing more,
Just, "Abort, Retry, Ignore?"

Re: What's needed for mutt 1.6?

[Vincent Lefevre]

On 2007-02-26 09:45:19 -0800, Brendan Cully wrote:
> On Friday, 23 February 2007 at 03:21, Vincent Lefevre wrote:
> > * My "Save History" patch, to be able to save the history between
> > sessions.
> > 
> > http://www.vinc17.org/mutt/patches/patch-1.5.12.vl.savehist.1
> 
> I like this one too, and I've applied it.

Thanks (and at 17:17, well done :).

You should also add history.c to po/POTFILES.in. And I've noticed
that mutt_sasl.c and smtp.c are missing too.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: What's needed for mutt 1.6?

[Brendan Cully]

On Tuesday, 27 February 2007 at 02:06, Vincent Lefevre wrote:
> On 2007-02-26 09:45:19 -0800, Brendan Cully wrote:
> > On Friday, 23 February 2007 at 03:21, Vincent Lefevre wrote:
> > > * My "Save History" patch, to be able to save the history between
> > > sessions.
> > > 
> > > http://www.vinc17.org/mutt/patches/patch-1.5.12.vl.savehist.1
> > 
> > I like this one too, and I've applied it.
> 
> Thanks (and at 17:17, well done :).
> 
> You should also add history.c to po/POTFILES.in. And I've noticed
> that mutt_sasl.c and smtp.c are missing too.

Whoops. Done, thanks.


pgpDDYxc0xyox.pgp
Description: PGP signature

[2007-02-27] CVS repository changes

[Thomas Roessler]

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.


2007-02-27 01:10:57  Brendan Cully  <[EMAIL PROTECTED]>  (brendan)

* po/POTFILES.in: Add some missing files. This should probably
be autogenerated somehow.

2007-02-26 18:39:52  Brendan Cully  <[EMAIL PROTECTED]>  (brendan)

* m4/gpgme.m4: Add gpgme.m4 to distribution to avoid an error
running autoconf on systems that do not have gpgme installed.

* main.c: Add curses_version to mutt -v output (thanks to Vincent
Lefevre for the initial patch), and reformat library information.

2007-02-26 17:17:13  Vincent Lefevre  <[EMAIL PROTECTED]>  (brendan)

* UPDATING, enter.c, globals.h, history.c, history.h, init.c,
init.h: Add $history_file and $save_history, for saving command
history across sessions.

2007-02-26 16:54:26  Roland Rosenfeld  <[EMAIL PROTECTED]>  (brendan)

* po/de.po: Updated German translation.

2007-02-25 01:32:31  Brendan Cully  <[EMAIL PROTECTED]>  (brendan)

* account.c, account.h, imap/imap.c, imap/message.c, main.c,
mutt_sasl.c: Update copyrights.