Re: [Nmh-workers] message rewrite/fix up

2013-03-18 Thread Ken Hornstein
CentOS 5 is on Automake 1.7, but I upgraded to build mhfixmsg once I figured out what the problem was... It's worth noting that Automake 1.7 was released in September ... of 2002. Also, versions of Automake older 1.11.6 and 1.12.2 have a security issue in their generated make distcheck rules.

[Nmh-workers] rmpproc

2013-03-18 Thread belg4mit
Would it be possible to expose rmmproc as an option for rmm? I currently have my profile rmmproc set to rm, since in my shell rm is aliased to 'refile -normmproc !* +Trash' and empty is '/usr/local/bin/rmm +Trash !*; folder -pack' However this makes it difficult to have backups for mhfixmsg, and

Re: [Nmh-workers] rmpproc

2013-03-18 Thread David Levine
Jerrad wrote: Would it be possible to expose rmmproc as an option for rmm? Just a thought, though I understand if it seems like Yet Another Switch I had that feeling when putting rmmproc support in mhfixmsg. But, I agree that it would be useful. Unless there's strenuous objection, I'll add

Re: [Nmh-workers] message rewrite/fix up

2013-03-18 Thread Tethys
Ken Hornstein writes: CentOS 5 is on Automake 1.7, but I upgraded to build mhfixmsg once I figured out what the problem was... It's worth noting that Automake 1.7 was released in September ... of 2002. Also, versions of Automake older 1.11.6 and 1.12.2 have a security issue in their generated

Re: [Nmh-workers] message rewrite/fix up

2013-03-18 Thread Ken Hornstein
Also, versions of Automake older 1.11.6 and 1.12.2 have a security issue in their generated make distcheck rules. That's not actually true. The version in RHEL 5 (and hence CentOS) has been patched to fix this (and other known vulnerabilities). You can't tell simply by looking at the version

[Nmh-workers] configure --prefix problem with whatnow/post

2013-03-18 Thread belg4mit
I configured and compiled with --prefix /usr/local and things worked fine. Unfortunately, the whatnow prompt reports the following when I try to send: unable to exec /usr/local/nmh/lib/post: No such file or directory post is installed in /usr/local/lib/ as per my configure...

Re: [Nmh-workers] configure --prefix problem with whatnow/post

2013-03-18 Thread belg4mit
Hmm, after remaking and installing (because I notced my attempt to change the hash backup to the delete-compatible .# in configure did not carry over, and manually tweaked config.h instead) the problem seems to have gone away?? * delete, a friendlier version of rm

Re: [Nmh-workers] configure --prefix problem with whatnow/post

2013-03-18 Thread Ken Hornstein
I configured and compiled with --prefix /usr/local and things worked fine. Unfortunately, the whatnow prompt reports the following when I try to send: unable to exec /usr/local/nmh/lib/post: No such file or directory post is installed in /usr/local/lib/ as per my configure... Is it possible

[Nmh-workers] --prefix=/usr/local issues

2013-03-18 Thread Lyndon Nerenberg
On 2013-03-18, at 7:36 PM, belg4...@pthbb.org wrote: I configured and compiled with --prefix /usr/local and things worked fine. Unfortunately, the whatnow prompt reports the following when I try to send: unable to exec /usr/local/nmh/lib/post: No such file or directory Unrelated, but this

Re: [Nmh-workers] configure --prefix problem with whatnow/post

2013-03-18 Thread Jerrad Pierce
Ahh, yes, probably a dirty tree/funky dependencies. I extracted this evening's tarball over yesterday's build, but I would have expected a reinvocation of configure to force any necessary updates... however make has its own way with things :-P As for Lyndon's comment, yes, having things be in a

Re: [Nmh-workers] --prefix=/usr/local issues

2013-03-18 Thread Ken Hornstein
Currently we install the etc stuff into ${prefix}/etc, which spams /usr/local/etc pretty hard when faced with --prefix=/usr/local. Personally, I'm not a fan of the /usr/local/nmh default prefix, and would prefer to see it changed to /usr/local, with the configdir stuff pushed down a level to

Re: [Nmh-workers] --prefix=/usr/local issues

2013-03-18 Thread Lyndon Nerenberg
On 2013-03-18, at 8:30 PM, Ken Hornstein wrote: To me there is no obvious right answer. Can you and Norm just have a steel-cage match and the winner gets to pick? That would save us from having to make a decision :-) No, I think I will just change it to match the rest of the world. And

[Nmh-workers] 1.6

2013-03-18 Thread Lyndon Nerenberg
On 2013-03-18, at 8:32 PM, Lyndon Nerenberg wrote: No, I think I will just change it to match the rest of the world. And then unplug the Ethernet cable and go sailing for a month ;-) A bit less glibly, it might be time to lay down the anchor for the 1.6-branch. I think we have a few more

Re: [Nmh-workers] 1.6

2013-03-18 Thread Lyndon Nerenberg
On 2013-03-18, at 8:53 PM, Lyndon Nerenberg wrote: 1.6-branch 1.5. Doh. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] --prefix=/usr/local issues

2013-03-18 Thread Lyndon Nerenberg
On 2013-03-18, at 8:30 PM, Ken Hornstein wrote: Norm spoke up that he liked it the old way (even though it was causing him man page problems that he ultimately resolved). Yes, but Norm is just a grumpy old Dad :-) ___ Nmh-workers mailing list

Re: [Nmh-workers] 1.6

2013-03-18 Thread Ken Hornstein
A bit less glibly, it might be time to lay down the anchor for the 1.6-branch. I think we have a few more 'breakage' things in the queue we've been waiting to inflict on the masses ... Maybe I'm not up on my nautical termology, and I know you sent out a revision that said 1.5, but I'm confused.

Re: [Nmh-workers] 1.6

2013-03-18 Thread Lyndon Nerenberg
On 2013-03-18, at 9:29 PM, Ken Hornstein wrote: Maybe I'm not up on my nautical termology, and I know you sent out a revision that said 1.5, but I'm confused. Is it you're thinking that 1.5 is getting a bit long in the tooth (was released in June of last year) and you want to think about a

Re: [Nmh-workers] configure --prefix problem with whatnow/post

2013-03-18 Thread Ken Hornstein
Ahh, yes, probably a dirty tree/funky dependencies. I extracted this evening's tarball over yesterday's build, but I would have expected a reinvocation of configure to force any necessary updates... however make has its own way with things :-P Ah, I see. The problem is that those paths are