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

[Ken Hornstein]

>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 branched 1.6 in
April of 2014, and Paul Fox added that code in May of 2014.  I did notice
it on MacOS 10.6, but that OS was old at the time so I think it just
fell off everyone's radar.

>Could we perhaps include a configure test and a fallback implementation
>such as the one below (it is a public domain implementation tweaked
>to use mh_xmalloc etc)?

In terms of Autoconf, there is AC_REPLACE_FUNCS designed for this
exact purpose, so the replacment function could be in it's own file.
You'll need to add LIBOJBS to LIBADD as well.  Like, I think this in
configure.ac:

AC_CONFIG_LIBOBJ_DIR([sbr])
AC_REPLACE_FUNCS([getline])

Makefile.am:

sbr_libmh_a_LIBADD = $(LIBOBJS)

and put the implementation in sbr/getline.c.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Tom Lane]

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
> tar file?  If it's the latter, it shouldn't matter what Autotools version
> is installed.

Normal expectation is that builds should be done from a released tarball
if the upstream publishes such.  In my former life as a Red Hat employee,
I did maintain some packages that needed to have patches applied to
configure.in and then were re-autoconf'd from there, but I believe that
was the exception (and generally an indication of poor autoconfiscation,
or a ridiculously ancient autoconf version used by upstream).

I do not know how David came to the conclusion that EL5 does not have
autoconf/automake packaged, but I will state for a fact that it does,
and so did very many Red Hat releases before it, because I maintained
packages that depended on them.

regards, tom lane

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Oliver Kiddle]

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 on
older systems that predate that.

Could we perhaps include a configure test and a fallback implementation
such as the one below (it is a public domain implementation tweaked
to use mh_xmalloc etc)?

I'm not quite sure which file would be appropriate for this to be
included in. sbr/utils.c seemed a reasonable choice but one of the
test cases also depends on getline and my automake knowledge was not
sufficient to work out how to handle the dependencies for that without
listing loads of object files. I also can't work out how to run the
tests by the way. make test doesn't work and the README file provides no
indication of how to run them.

Oliver

#ifndef HAVE_GETLINE

ssize_t getline(char **lineptr, size_t *n, FILE *stream) {
int c;
size_t alloced = 0;
char *linebuf;

if (*lineptr == NULL) {
alloced = 256;
linebuf = mh_xmalloc(sizeof(char) * alloced);
} else {
linebuf = *lineptr;
alloced = *n;
}
ssize_t linelen = 0;

do {
c = fgetc(stream);
if (c == EOF) {
break;
}
if (linelen >= alloced) {
alloced += (alloced + 1)/2;
linebuf = mh_xrealloc(linebuf, sizeof(char) * alloced);
}
*(linebuf + linelen) = (unsigned char)c;
linelen++;
} while (c != '\n');

if (linelen == 0) {
if (linebuf && !*lineptr) {
free(linebuf);
linebuf = NULL;
}
linelen = -1;
*n = alloced;
} else {
if (linebuf) {
linebuf[linelen] = '\0';
}
*n = alloced;
*lineptr = linebuf;
}

return linelen;
}

#endif


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Paul Fox]

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 specifications but may still be lacking on
 > older systems that predate that.
 > 
 > Could we perhaps include a configure test and a fallback implementation
 > such as the one below (it is a public domain implementation tweaked
 > to use mh_xmalloc etc)?

as i recall, after i changed most everything to use getline(), lyndon
was working on such a replacement, but i don't know what happened with
that.  oh -- here:
http://lists.nongnu.org/archive/html/nmh-workers/2014-08/msg00033.html
looks like it was never finished.  the target at the time was OS X, not
solaris.

paul


 > 
 > I'm not quite sure which file would be appropriate for this to be
 > included in. sbr/utils.c seemed a reasonable choice but one of the
 > test cases also depends on getline and my automake knowledge was not
 > sufficient to work out how to handle the dependencies for that without
 > listing loads of object files. I also can't work out how to run the
 > tests by the way. make test doesn't work and the README file provides no
 > indication of how to run them.
 > 
 > Oliver
 > 
 > #ifndef HAVE_GETLINE
 > 
 > ssize_t getline(char **lineptr, size_t *n, FILE *stream) {
 > int c;
 > size_t alloced = 0;
 > char *linebuf;
 > 
 > if (*lineptr == NULL) {
 > alloced = 256;
 > linebuf = mh_xmalloc(sizeof(char) * alloced);
 > } else {
 > linebuf = *lineptr;
 > alloced = *n;
 > }
 > ssize_t linelen = 0;
 > 
 > do {
 > c = fgetc(stream);
 > if (c == EOF) {
 > break;
 > }
 > if (linelen >= alloced) {
 > alloced += (alloced + 1)/2;
 > linebuf = mh_xrealloc(linebuf, sizeof(char) * alloced);
 > }
 > *(linebuf + linelen) = (unsigned char)c;
 > linelen++;
 > } while (c != '\n');
 > 
 > if (linelen == 0) {
 > if (linebuf && !*lineptr) {
 > free(linebuf);
 > linebuf = NULL;
 > }
 > linelen = -1;
 > *n = alloced;
 > } else {
 > if (linebuf) {
 > linebuf[linelen] = '\0';
 > }
 > *n = alloced;
 > *lineptr = linebuf;
 > }
 > 
 > return linelen;
 > }
 > 
 > #endif
 > 
 > 
 > ___
 > Nmh-workers mailing list
 > Nmh-workers@nongnu.org
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers
 > 


=--
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 53.8 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[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?

> Possibly implemented by checking the specified unseen sequence for
> the presence of the Sequence-negation prefix and behaving
> appropriately (FX: waves hands vigorously).

I'm not sure what you're trying to accomplish.  Do you want the
unseen sequence to be maintained?

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[David Levine]

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 should attribute it,
at least with the URL and ideally with the the author name.

Just looking at it quickly, the unsigned char cast will probably cause
a compile warning on some platforms.  And I don't see why it's necessary.

> I'm not quite sure which file would be appropriate for this to be
> included in. sbr/utils.c seemed a reasonable choice

Agreed.

> but one of the test cases also depends on getline

Add $(LDADD) here, in Makefile.am:
test_fakehttp_LDADD = $(LDADD) $(POSTLINK)

> I also can't work out how to run the tests by the way. make test
> doesn't work and the README file provides no indication of how
> to run them.

tests/README says:
To run these tests you can do "make check" via the top-level Makefile.

It's also mentioned under "nmh test suite" in docs/README.developers.

This isn't mentioned in the source tree, but Lyndon's buildbot results are
available at http://orthanc.ca:8010/waterfall

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[norm]

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 the public domain. For example, for a while AT leased it for their
internal use.

Norman Shapiro

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[William Hay]

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 coming soon.
> 
> At this point, I'd like to put out a call; if there are any features or
> bugs you'd like fixed in 1.7, now is the time to speak up.  Obviously
> priority will be given to feature requests that come with code :-)
> We can still implement bug fixes during a release cycle, but I'd like
> to get as many out of the way beforehand.
> 
> So this is your chance; if there's something missing in nmh you'd like
> to see implemented in 1.7, please speak up now!
>
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.  Possibly implemented by checking the specified 
unseen sequence for the presence of the Sequence-negation prefix and
behaving appropriately (FX: waves hands vigorously).

William

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[David Levine]

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

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[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 muck with it thereby avoiding a need for the MDA
>to lock the .mh_sequence file.

I think in practice too much code depends right now on the current sematics
of the unseen sequence.

Also, what's the big deal with locking the sequence file, anyway?  I think
we've got that all straightened out.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[William Hay]

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 tell the difference between messages I'd read and 
newly
delivered messages.

> 
> > Possibly implemented by checking the specified unseen sequence for
> > the presence of the Sequence-negation prefix and behaving
> > appropriately (FX: waves hands vigorously).
> 
> I'm not sure what you're trying to accomplish.  Do you want the
> unseen sequence to be maintained?

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 the MDA
to lock the .mh_sequence file.


William

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[William Hay]

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 muck with it thereby avoiding a need for the MDA
> >to lock the .mh_sequence file.
> 
> I think in practice too much code depends right now on the current sematics
> of the unseen sequence.

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 potentially) be a no-op for new messages.

> 
> Also, what's the big deal with locking the sequence file, anyway?  I think
> we've got that all straightened out.

You may have but not every mda even attempts to update the sequence.

William

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>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 potentially) be a no-op for new messages.

Yeah, the implementation is huge part of the details, though.  Unseen is
handled special; every program would have to be changed.

>>
>> Also, what's the big deal with locking the sequence file, anyway?  I
>> think we've got that all straightened out.
>
>You may have but not every mda even attempts to update the sequence.

I'm ... confused?  AFAIK, the MDAs just pipe it into rcvstore, which
does update the sequence.  I am aware that procmail can write to a
MH folder directly, but it can also just pipe to rcvstore.  I'm trying
to understand the use case where "use rcvstore" isn't an option, because
it would require a LOT of careful surgery.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[P Vixie]

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 option, defaulting to off.

On September 27, 2016 7:49:13 PM GMT+02:00, William Hay  wrote:
>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 muck with it thereby avoiding a need for
>the MDA
>> >to lock the .mh_sequence file.
>> 
>> I think in practice too much code depends right now on the current
>sematics
>> of the unseen sequence.
>
>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 potentially) be a no-op for new
>messages.
>
>> 
>> Also, what's the big deal with locking the sequence file, anyway?  I
>think
>> we've got that all straightened out.
>
>You may have but not every mda even attempts to update the sequence.
>
>William
>
>___
>Nmh-workers mailing list
>Nmh-workers@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/nmh-workers

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[David Levine]

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 on EL5:  I don't see any autoconf or automake.

Unless someone wants this enough to guide me through these,
I won't bother.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[David Levine]

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 has sufficient
prerequisities.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>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 what Autotools version
is installed.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers