Re: [Nmh-workers] Starting the final call for features for 1.7

>The latest code in git is failing to build on Solaris because it >relies on getline(3). getline was a GNU extension that has now been >added to recent POSIX specifications but may still be lacking on >older systems that predate that. Hm, I thought this was an issue for 1.6, but no ... we

Re: [Nmh-workers] Starting the final call for features for 1.7

Ken Hornstein writes: >> For EL6, the build needs to use autoconf268 instead of >> autoconf. And it needs automake 1.12, but it looks like >> automake 1.11 is installed, so that might be a show stopper. > Do they want to actually build from a git checkout, or a distribution >

Re: [Nmh-workers] Starting the final call for features for 1.7

On 23 Sep, Ken Hornstein wrote: > I think that we are starting to get close to being ready for a 1.7 The latest code in git is failing to build on Solaris because it relies on getline(3). getline was a GNU extension that has now been added to recent POSIX specifications but may still be lacking

Re: [Nmh-workers] Starting the final call for features for 1.7

oliver wrote: > On 23 Sep, Ken Hornstein wrote: > > I think that we are starting to get close to being ready for a 1.7 > > The latest code in git is failing to build on Solaris because it > relies on getline(3). getline was a GNU extension that has now been > added to recent POSIX

Re: [Nmh-workers] Starting the final call for features for 1.7

William wrote: > I'd prefer a seen sequence to an unseen sequence as this would let > an MDA deliver directly into an nmh folder without needing to update > the .mh_sequences file. So would rcvstore -nounseen, can you use that? > Possibly implemented by checking the specified unseen sequence

Re: [Nmh-workers] Starting the final call for features for 1.7

Oliver wrote: > Could we perhaps include a configure test Easy, just add getline to the AC_CHECK_FUNCS in configure.ac. > and a fallback implementation such as the one below (it is a > public domain implementation tweaked to use mh_xmalloc etc)? If we include that implementation, I think we

Re: [Nmh-workers] Starting the final call for features for 1.7

Lyndon Nerenberg writes: . > >MH started as a public domain project. While I can live with the current >copyright on the distribution, I always preferred everything staying in the >public domain. Not quite. MH was maybe 5 years old, maybe older, when RAND released it into

Re: [Nmh-workers] Starting the final call for features for 1.7

Thus spake Ken Hornstein: > Greetings all, > > I think that we are starting to get close to being ready for a 1.7 > release. I believe all of the features I wanted for 1.7 have been > merged into master; there are one two other features I know that are > being worked on, but I think that will be

Re: [Nmh-workers] Starting the final call for features for 1.7

Tom wrote: > Normal expectation is that builds should be done from a released tarball > if the upstream publishes such. The spec had autoreconf -force. I removed that and the auto* dependencies, and now builds succeed. I'll submit. Thanks! David

Re: [Nmh-workers] Starting the final call for features for 1.7

>I'd like to be able to distinguish between seen and unseen messages without >requiring the MDA to update the .mh_sequence file. If the sequence was a list >of messages that were read rather than unread then only the interactive >mh commands would need to muck with it thereby avoiding a need for

Re: [Nmh-workers] Starting the final call for features for 1.7

Thus spake David Levine: > William wrote: > > > I'd prefer a seen sequence to an unseen sequence as this would let > > an MDA deliver directly into an nmh folder without needing to update > > the .mh_sequences file. > > So would rcvstore -nounseen, can you use that? That wouldn't allow me to

Re: [Nmh-workers] Starting the final call for features for 1.7

Thus spake Ken Hornstein: > >I'd like to be able to distinguish between seen and unseen messages without > >requiring the MDA to update the .mh_sequence file. If the sequence was a > >list > >of messages that were read rather than unread then only the interactive > >mh commands would need to

Re: [Nmh-workers] Starting the final call for features for 1.7

>Which is why I suggested implemenation by checking for the sequence >negation prefix when using the unseen sequence. The semantics remain >the same although the implementation differs. Adding to the unseen >sequence is translated to removing from the seen sequence which would(at >least

Re: [Nmh-workers] Starting the final call for features for 1.7

The .mh_sequences file is read directly by some MUAs. That's likely wrong and they should use shell commands to get at the data. But I don't think we should violate their expectations at this late date. Negative sequences is a better design. But if we put it in it has to be a .mh_ profile

Re: [Nmh-workers] Starting the final call for features for 1.7

Valdis wrote: > It's not in the EPEL repos either (which are basically extras > from Fedora built for Red Hat). For EL6, the build needs to use autoconf268 instead of autoconf. And it needs automake 1.12, but it looks like automake 1.11 is installed, so that might be a show stopper. And worse

Re: [Nmh-workers] Starting the final call for features for 1.7

I wrote: > For EL6, the build needs to use autoconf268 instead of > autoconf. And it needs automake 1.12, but it looks like > automake 1.11 is installed, so that might be a show stopper. > > And worse on EL5: I don't see any autoconf or automake. I requested an EPEL7 branch. It looks like it

Re: [Nmh-workers] Starting the final call for features for 1.7

>For EL6, the build needs to use autoconf268 instead of >autoconf. And it needs automake 1.12, but it looks like >automake 1.11 is installed, so that might be a show stopper. Do they want to actually build from a git checkout, or a distribution tar file? If it's the latter, it shouldn't matter