Re: nmh 1.8?

2022-12-31 Thread Ken Hornstein
>I just did an upgrade at home to MacOS X Ventura; let me make sure the
>test suite passes and there are no obvious issues there.

Oof, wait.  I just did a "make distcheck" and I get:

depbase=`echo uip/mhical.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
cc -DHAVE_CONFIG_H -I. -I../.. -g -O2 -Wall -Wextra -MT 
uip/mhical.o -MD -MP -MF $depbase.Tpo -c -o uip/mhical.o uip/mhical.c &&\
mv -f $depbase.Tpo $depbase.Po
clang: error: no such file or directory: 'uip/mhical.c'
clang: error: no input files

I just committed a fix.

--Ken



Re: nmh 1.8?

2022-12-31 Thread Kevin Cosgrove
Is anyone here packaging nmh as part of a .deb file in the process of
testing?  I used to routinely do that for .rpm packages, but no longer find
myself on a system where that makes sense.
Thanks.

On Mon, Dec 26, 2022 at 3:48 PM David Levine  wrote:

> Greetings as we approach the new year.
>
> It's been a long time since nmh 1.7.1 was released, March 2018 to be
> specific.  What does everyone think of pushing out a 1.8 soon?  Here
> are changes since 1.7.1:
>
>
> https://git.savannah.nongnu.org/cgit/nmh.git/plain/docs/pending-release-notes
>
> While Ken has a worthy wish list at
> https://lists.gnu.org/archive/html/nmh-workers/2019-05/msg0.html
> and maybe more, I've reached the point where I don't think that we
> should hold up a release any longer.
>
> What triggered this?  I finally figured out how to package for Red Hat
> EPEL 8 and 9.  I don't think that should be done with 1.7.1.  And, the
> current HEAD has been stable for a while.  As always, new features and
> improvements can be added as they're ready.
>
> Question: is anyone besides me using the Gmail integration on the
> gmailapis branch?  It needs a fix, but if no one else is using it,
> that can wait.
>
> David
>
>


Re: nmh 1.8?

2022-12-31 Thread Ken Hornstein
>>Do you or anyone else have anything else you'd like to put in before
>>starting the 1.8 release cycle?
>
>I just did an upgrade at home to MacOS X Ventura; let me make sure the
>test suite passes and there are no obvious issues there.

I just did that, and it builds fine and passes the test suite fine.
I _can_ think of things I'd like to get in before 1.8, but I'd rather
not hold things up.  I say, "Start the engines!"

--Ken



Re: nmh 1.8?

2022-12-31 Thread Ken Hornstein
>Ralph, your last round of changes look good to me.  HEAD builds and
>tests cleanly for me on Fedora, Solaris 11, and Cygwin.
>
>Do you or anyone else have anything else you'd like to put in before
>starting the 1.8 release cycle?

I just did an upgrade at home to MacOS X Ventura; let me make sure the
test suite passes and there are no obvious issues there.

--Ken



Re: nmh 1.8?

2022-12-31 Thread Ralph Corderoy
Hi David,

> HEAD builds and tests cleanly for me on Fedora, Solaris 11, and
> Cygwin.

Good to hear.  I had a ‘All 118 tests passed’ with
1.7-branchpoint-884-gf116eb31 when doing ‘NMH_VALGRIND=1 VALGRIND_ME=1
make check’ on a friend's quicker PC running Manjaro.

> Do you or anyone else have anything else you'd like to put in before
> starting the 1.8 release cycle?

Nothing which should hold it up.  I'm dabbling with mh-chart.man and
the bash-completion generation at the moment, fixing a little bit of
degradation, but it way well not meet the cut and that wouldn't bother me.

-- 
Cheers, Ralph.



Re: nmh 1.8?

2022-12-31 Thread David Levine
Ralph, your last round of changes look good to me.  HEAD builds and
tests cleanly for me on Fedora, Solaris 11, and Cygwin.

Do you or anyone else have anything else you'd like to put in before
starting the 1.8 release cycle?

David



Re: send(1) and Draft-Folder.

2022-12-31 Thread David Levine
I wrote:

> Ralph wrote:

> > Is this equivalent?
> >
> > Draft-Folder: -draftfolder's default
>
> I don't like that, because then I have to figure out how -draftfolder
> fits in.

I might have come across as harsh on that.  In reality, I don't
have a preference.

David



Re: nmh 1.8?

2022-12-31 Thread Ralph Corderoy
Hi Ken,

> Sigh.  Ralph, you and I don't agree on Content-MD5, which is fine.

The issue is not the repeated distractions of only I used the options or
what was the point of them anyway.  It's that functionality was deleted
but at the same time documented as deprecated and the options left in as
no-ops so users wouldn't cotton on.

The better path given your opinion would have been to take a stand,
delete the code and the options and say it's just tough on the users.
That's effectively where we are now as I've removed the options and
lingering documentation.

-- 
Cheers, Ralph.