Re: new release?

David wrote: > Same thing happens on macOS 12.3.1 with Apple clang 13.1.6 on > arm64-apple-darwin21.4.0 (i.e. lynx works, elinks breaks). elinks support isn't fully functional. See this comment in etc/mhn.defaults.sh: M. Levinson noted that -eval "set document.codepage.assume='$charset'"

Re: new release?

> Ken wrote: > > > What I'd like is to have mhical simply > > edit out everything that makes the iCal file a REQUEST (which I think > > is just the METHOD:REQUEST, or whatever that thing is, plus the list > > of attendees) > > The convert_to_reply() function does close to that, converting >

Re: new release?

Simon wrote: > > > FAIL: test/mhshow/test-cte-binary > > > > I'll fix that test. > > After a "git pull": > > == > All 111 tests passed > (7 tests were not run) > == I don't know why test-cte-binary passed for you on this run, because I

Re: new release?

Hi David, > I rely on the exit status of build_nmh, and only look at the log file > if indicates failure. Ah, I was considering any tests skipped as failure because I was trying to get them all to run. :-) I agree in the general case that's not wanted. > Should we output the summary to the

Re: new release?

Hi David, > > > Both releases saw a spew of "Broken pipe" errors after > > > test-mhparam, not sure if that's expected or not. > > > > That's not expected. The test immediately after that test-mhparam > > is test/oauth/test-send. So Jay's later email showed EPIPE was being returned and that

Re: new release?

Hi Eric, > I've pushed f188de902b613110d5943210f212adb680a2b44a to master > now, which should resolve this test failure. Thanks, but could you, and any other committers, try to use Git's rebase rather than merge as it preserves your commits and their messages rather than ‘Merge commit

Re: new release?

David Levine wrote: >Jay wrote: [...] >> Both releases >> saw a spew of "Broken pipe" errors after test-mhparam, not sure if >> that's expected or not. > >That's not expected. The test immediately after that test-mhparam >is test/oauth/test-send. I tried running it under "sh -x" but >that

Re: new release?

David Levine wrote: > Simon wrote: > > > Details below. First time I've run these tests, hope this is helpful. > > Yes, thank you! Cool, thanks! > > FAIL: test/mhical/test-mhical > > Eric already fixed. > > [ ... ] > > > FAIL: test/mhshow/test-cte-binary > > I'll fix that test. After a "git

Re: new release?

On Wed, 20 Apr 2022 17:29:39 -0700, David Levine writes: >Should any of those debian-specific patches be considered for >upstream? i don't think so; by now the delta is really minimal (i tend to report functional issues upstream anyway, and the most recent difference was the bcc handling which is

Re: new release?

Ken wrote: > What I'd like is to have mhical simply > edit out everything that makes the iCal file a REQUEST (which I think > is just the METHOD:REQUEST, or whatever that thing is, plus the list > of attendees) The convert_to_reply() function does close to that, converting REQUEST to REPLY. >

Re: new release?

Ralph wrote: > Sometimes, the summary of the tests run by build_nmh do not appear on > the terminal. Always, actually. > They're tacked onto the end of the log file, as if the restoration of > stdout failed. It's all working as designed. I rely on the exit status of build_nmh, and only look

Re: new release?

Simon wrote: > Details below. First time I've run these tests, hope this is helpful. Yes, thank you! > FAIL: test/mhical/test-mhical Eric already fixed. > *** /home/simonb/src/mail/nmh/nmh-git/test/testdir/5969.expectedWed > Apr 20 23:34:58 2022 > ---

Re: new release?

Ralph wrote: > MACHINES mentions: > > gdbm-devel, db4-devel or libdb-devel/libdb-dev (only needed for > slocal(1)) > > There's no db4-devel. I'll remove that. THere isn't one for Fedora, either. > There's no gdbm-devel, There is for Fedora. Maybe it's time to split out the RedHat and

Re: new release?

az wrote: > i've pulled master, massaged it a bit with the (few remaining) debian-specific > patches, and built it. Should any of those debian-specific patches be considered for upstream? If one is for port 25, my feeling is to leave that as it is. > one test fails: mhical apparently has

Re: new release?

>> FAIL: test/mhical/test-mhical This reminds of me ONE feature enhancement I'd like. I find myself receiving a number of ical meeting invites, which, fine. I can use mhical to respond to them. But AFTER I respond to them I'd like to store them in my Apple iCloud calendar. That's fine; I can

Re: new release?

Jay wrote: > Clean build on 22.04; 16.04 got the following compiler warnings: Both from code generated by flex, and fixed in the later version. > Both releases > saw a spew of "Broken pipe" errors after test-mhparam, not sure if > that's expected or not. That's not expected. The test

Re: new release?

Andy wrote: > sbr/fmt_rfc2047.c:391:12: error: use of undeclared identifier 'initialdstlen' > return initialdstlen - dstlen; >^ Thanks. That happens when building without iconv. I'll fix. David

Re: new release?

ken wrote: > >But here's the thing: when configure doesn't find lex or flex, it > >sets the value of the program to ":". wth? Wouldn't "false" be > >a far more effective substitute? If there's a way to tell configure > >to change that behavior, we should consider it. > > This behavior

Re: new release

on Manjaro (21.2.6, "Qonos"): === All 118 tests passed === - Steven -- ___ Steven Winikoff | Montreal, QC, Canada | "It's amazing how much 'mature wisdom' s...@smwonline.ca

Re: new release?

>But here's the thing: when configure doesn't find lex or flex, it >sets the value of the program to ":". wth? Wouldn't "false" be >a far more effective substitute? If there's a way to tell configure >to change that behavior, we should consider it. This behavior is part of autoconf. From

Re: new release?

ralph wrote: > Hi Paul, > > > At first I was missing "yacc". Installing either bison or byacc gets > > me to this error. > > Has configure been re-run since the installation? Yes -- rerunning configure, rerunning autogen.sh, running make clean; make all gave the same error. On a fresh

Re: new release?

Alexander Zangerl writes: > one test fails: mhical apparently has timezone issues? > not sure, no icalendar user, but i'm in gmt +1000. Everyone is stumbling across this one. I fixed it on a branch a while ago, but until just now, forgot to pus it to master. I've pushed

Re: new release?

Hi again David, > Installing libgdbm-compat-dev for ndbm.h works, i.e. ./build_nmh > installing to /tmp and leaving the rest to configure ends > > All 99 tests passed > (19 tests were not run) Sometimes, the summary of the tests run by build_nmh do not appear on the terminal. $

Re: new release?

Hi Paul, > At first I was missing "yacc". Installing either bison or byacc gets > me to this error. Has configure been re-run since the installation? > $ make > make all-am > make[1]: Entering directory '/home/pgf/src/pdom/nmh/nmh.git' > /bin/bash ./ylwrap sbr/icalendar.l .c

Re: new release

Mageia 8 results: == All 112 tests passed (6 tests were not run) == make[1]: Leaving directory '/home/jerry/code/nmhgit/nmh' jerry -- // Jerry Heyman | Parahrasing Thomas Sowell: // Amigan Forever :-) | Stop trying to

Re: new release?

David Levine wrote: > In the meantime, if those who build from the repo could pull and > report the results of "make check", that will help reveal areas > that we need to address. Platforms such as the BSDs and Debian > are blind spots for me. NetBSD 9.99.92 amd64:

Re: new release?

I had to do a system reinstall not too long ago, so this is almost surely a local problem: At first I was missing "yacc". Installing either bison or byacc gets me to this error. I'm presumably missing something else, or have the wrong combo of tools. The output isn't exactly helpful. $

Re: new release?

Hi David, A bit of quick feedback on Debian 11... MACHINES mentions: gdbm-devel, db4-devel or libdb-devel/libdb-dev (only needed for slocal(1)) There's no db4-devel. A libdb5.3-dev exists and is installed but it doesn't satisfy configure's search. libdb-dev is installed but it

Re: new release?

On Tue, 19 Apr 2022 19:18:49 -0700, David Levine writes: >In the meantime, if those who build from the repo could pull and >report the results of "make check", that will help reveal areas >that we need to address. Platforms such as the BSDs and Debian >are blind spots for me. i've pulled master,

Re: new release?

Hi Howard, > Not a git user, so the problem could be on my end as I'm not getting a > version that matches 1.7.1 (or newer). ... > git clone -b master git://git.savannah.nongnu.org/nmh.git That looks right to me. You've asked for the ‘master’ branch where development takes place. To show

Re: new release?

Not a git user, so the problem could be on my end as I'm not getting a version that matches 1.7.1 (or newer). If I do the commands below, it compiles and tests cleanly (but again, I'm not sure I'm getting the right branch). Ubuntu 20.04 git clone -b master git://git.savannah.nongnu.org/nmh.git

Re: new release?

David Levine wrote: >In the meantime, if those who build from the repo could pull and >report the results of "make check", that will help reveal areas >that we need to address. Platforms such as the BSDs and Debian >are blind spots for me. Not exactly Debian, but I did make check on

Re: new release?

Thus said David Levine on Tue, 19 Apr 2022 19:18:49 -0700: > In the meantime, if those who build from the repo could pull and > report the results of "make check", that will help reveal areas that > we need to address. OpenBSD 6.9 amd64: $ make check cc -DHAVE_CONFIG_H -I.

Re: new release?

Ken wrote: > I'd like to clean up file descriptor handling (basically, set close-on-exec > for most everything unless it is necessary). Sounds good and low risk. In the meantime, if those who build from the repo could pull and report the results of "make check", that will help reveal areas that

Re: new release?

>Does anyone have any wishes, or enhancements they're working on? I'd like to clean up file descriptor handling (basically, set close-on-exec for most everything unless it is necessary). --Ken

new release?

Thoughts on a new release? It's been over 4 years since 1.7.1 was released, so I think it's about time. The notable changes since then are in docs/pending-release-notes, or if you prefer: https://git.savannah.nongnu.org/cgit/nmh.git/plain/docs/pending-release-notes Does anyone have any wishes

Re: New release?

I'll try to test it. Kevin On Sun, Mar 21, 2021, 7:04 PM David Levine wrote: > Ken wrote: > > > But anyway ... what do people think about doing a new release of nmh? > > It's been 3 years, so yeah, we should. > > David > >

Re: New release?

Ken wrote: > But anyway ... what do people think about doing a new release of nmh? It's been 3 years, so yeah, we should. David

New release?

Everyone, I would have thought that a global pandemic that got rid of my commute would have meant I had MORE free time, but somehow the opposite has happened. But anyway ... what do people think about doing a new release of nmh? Mostly since 1.7.1 there have been bugfixes and small feature

Re: [Nmh-workers] Maybe time for a new release?

>Norm wrote: > >> I want to output to stdout all the lines of that part that contain the >> string "family". What command go I feed into 'grep family"? > >Well, it depends whether you want to modify the message on disk or not. > >If you do want to modify the message permanently: > >$ mhfixmsg $

Re: [Nmh-workers] Maybe time for a new release?

Norm wrote: > I want to output to stdout all the lines of that part that contain the > string "family". What command go I feed into 'grep family"? Well, it depends whether you want to modify the message on disk or not. If you do want to modify the message permanently: $ mhfixmsg $

Re: [Nmh-workers] Maybe time for a new release?

>I am terribly sorry to be so dense, but none of your examples do it for >me. Suppose that I know that the current message in the current folder >has a part which is either utf-8 or a quotedPrintable and that >I want to output to stdout all the lines of that part that contain the >string

Re: [Nmh-workers] Maybe time for a new release?

David Levine writes: >Norm wrote: > >> The bulk of the non-spam mail I receive still has a utf-8 or a >> quotedPrintabl e part. I would like to apply UNIX text processing tools >> (grep, wc, sort, uniq, perl, etc) to these messages. It would be nice if the >> next release

Re: [Nmh-workers] Maybe time for a new release?

Conrad wrote: > Yes, seems so; I guess I'd just like a "best practice" section in the > mhfixmsg man page which shows (for example) a recommended command line > invocation (more-or-less covered a few emails back) and a procmail recipe. There's been a procmail recipe in the man page since March

Re: [Nmh-workers] Maybe time for a new release?

Jerrad wrote: > I use slocal with rcvstore and at various times either MIME-hooks or the > following .mh_profile entries > > add-hook: /usr/local/bin/mhfixmsg > mhfixmsg: -decodetext 8bit -reformat -replacetextplain Note that -decodetext 8bit and -reformat are defaults, so they're not

Re: [Nmh-workers] Maybe time for a new release?

Norm wrote: > The bulk of the non-spam mail I receive still has a utf-8 or a quotedPrintabl > e part. I would like to apply UNIX text processing tools (grep, wc, sort, > uniq, perl, etc) to these messages. It would be nice if the next release made > that reasonably easily possible. That's the

Re: [Nmh-workers] Maybe time for a new release?

Ralph Corderoy writes: >Hi Ken, > >> Norm wrote: >> > The bulk of the non-spam mail I receive still has a utf-8 or a >> > quotedPrintable part. I would like to apply UNIX text processing >> > tools (grep, wc, sort, uniq, perl, etc) to these messages. >> >> I ... think the

Re: [Nmh-workers] Maybe time for a new release?

>In principle I'd *like* to run mhfixmsg on email as it's delivered, but >I'm also sympathetic to the "keep the wire copy" argument, and a little >worried because of the abovementioned failures; does anyone else run it >through procmail? Are you happy with your experience of same? I've been using

Re: [Nmh-workers] Maybe time for a new release?

Hi Ken, > Norm wrote: > > The bulk of the non-spam mail I receive still has a utf-8 or a > > quotedPrintable part. I would like to apply UNIX text processing > > tools (grep, wc, sort, uniq, perl, etc) to these messages. > > I ... think the latest release makes that easy as well? Does Norm have

Re: [Nmh-workers] Maybe time for a new release?

Ken> I ... think the latest release makes that easy as well? It sounds Ken> like the only thing lacking from 1.6 in this area is documentation. Yes, seems so; I guess I'd just like a "best practice" section in the mhfixmsg man page which shows (for example) a recommended command line invocation

Re: [Nmh-workers] Maybe time for a new release?

>The bulk of the non-spam mail I receive still has a utf-8 or a quotedPrintable >part. I would like to apply UNIX text processing tools (grep, wc, sort, uniq, >perl, etc) to these messages. It would be nice if the next release made that >reasonably easily possible. I ... think the latest release

Re: [Nmh-workers] Maybe time for a new release?

David Levine writes: >Norm wrote: > >> David Levine writes: >> >> >Translate text/plain parts to UTF-8 To translate all text/plain parts in >> >the current message to UTF-8, in addition to all of the default >> >transformations: >> > >> >mhfixmsg -textcharset

Re: [Nmh-workers] Maybe time for a new release?

>How do I translate, to utf-8, all parts of a message, >which can be reasonably translated to utf-8? The first such part? David gave you a good answer, but to expand on it a bit ... Since not all Unicode codepoints are guaranteed to be represented as UTF-8 in text/html, you can't really convert

Re: [Nmh-workers] Maybe time for a new release?

>I can freshen up the branch. Did anyone ever review it? Should I merge it >as is? We should settle the api key management issue too. I looked at it, but I cannot say that I reviewed it; every time I sat down to really study it, I got lost in the whole OAUTH maze, then I got busy, it fell onto

Re: [Nmh-workers] Maybe time for a new release?

Norm wrote: > David Levine writes: > > >Translate text/plain parts to UTF-8 > >To translate all text/plain parts in the current message to UTF-8, in > >addition to all of the default transformations: > > > >mhfixmsg -textcharset utf-8 > > How do I translate, to utf-8, all parts

Re: [Nmh-workers] Maybe time for a new release?

Eric wrote: > I can freshen up the branch. Did anyone ever review it? Should I merge it > as is? We should settle the api key management issue too. I looked at it, but not even close to review. How about leaving it on the branch and we'll look it at there. I really do want to use it, just

Re: [Nmh-workers] Maybe time for a new release?

David Levine writes: >Norm wrote: > >> Maybe Contributions should have a tutorial script or two which >> illustrate good ways to do that? > >How about adding this to the man page? > >EXAMPLES >Basic usage >To run mhfixmsg on the current message in the current folder, with

Re: [Nmh-workers] Maybe time for a new release?

e, undefined thoughts on nmh > MIME processing" in the archives if you want an idea. > > But ... the Real World™ keeps getting in the way. And this (at least in > my mind) is going to be a major shakeup. Which makes me think before we > completely change the world, maybe we should cut

Re: [Nmh-workers] Maybe time for a new release?

Norm wrote: > Maybe Contributions should have a tutorial script or two which > illustrate good ways to do that? How about adding this to the man page? EXAMPLES Basic usage To run mhfixmsg on the current message in the current folder, with default transformations to fix MIME

Re: [Nmh-workers] Maybe time for a new release?

Ken Hornstein wrote: My reading of the maildir specification (such that it is) says that the filename before the colon should be unique. Although ... despite what people say, it seems like Maildir is not really designed to be a mail _store_ (someplace where you keep your mail long-term) but

Re: [Nmh-workers] Maybe time for a new release?

>we would also have to forbid sortm. i think that way lies madness, since >UID's are often 7 and 8 digit numbers, bad for human consumption. +1 >the earlier suggestion to maintain a mapping between message numbers as >seen by the MH toolset and UID's seen by IMAP, makes sense to me. though

Re: [Nmh-workers] Maybe time for a new release?

Michael Richardson wrote: Lyndon Nerenberg wrote: >> So, each message has a (U?)UID? Are the integers a subset of that? > UIDs increase monotonically within a folder. Sequence numbers are just > the index number into the dynamic array that represents

Re: [Nmh-workers] Maybe time for a new release?

So, if we forbid "pack", we can have UIDs rather than sequence numbers? No, if you change the UIDs you just change the UIDVALIDITY of the folder. RFC3501 explains this quite clearly. Section 2.3.1.1 describes UID and UIDVALIDITY. Section 2.3.1.2 describes message sequence numbers.

Re: [Nmh-workers] Maybe time for a new release?

Ken Hornstein writes: > >Let me explain my larger view. I know lots of people still want to be >able to use Unix text processing utilities on a MH store. But I hate >to be the the one who has to explain this ... that hasn't been a realistic >goal since the advent of MIME. The

Re: [Nmh-workers] Maybe time for a new release?

Lyndon Nerenberg wrote: >> So, each message has a (U?)UID? Are the integers a subset of that? > UIDs increase monotonically within a folder. Sequence numbers are just > the index number into the dynamic array that represents the current set > of messages

Re: [Nmh-workers] Maybe time for a new release?

So, each message has a (U?)UID? Are the integers a subset of that? UIDs increase monotonically within a folder. Sequence numbers are just the index number into the dynamic array that represents the current set of messages visible withing a folder. UIDs never change (for all practical

Re: [Nmh-workers] New release, v2?

On 9 March 2016 at 9:17, Ken Hornstein wrote: > So, in short: cut a 1.7, yes or no? Anything people would like in there? > My list is: > > - Incorporate XOAUTH support > - Fix character conversion on message bodies (right now it aborts if it > cannot convert characters to

Re: [Nmh-workers] Maybe time for a new release?

On Tuesday, March 8, 2016 9:19:57 PM PST Ken Hornstein wrote: > ... I hate > to be the the one who has to explain this ... that hasn't been a realistic > goal since the advent of MIME. The model that "email is text" just > isn't valid anymore. i know. which is why i don't see much value in the

[Nmh-workers] New release, v2?

Everyone, I'd like to focus in this email JUST on the idea of a new release. I'll send another email regarding future directions so we can keep these discussion separate. So, in short: cut a 1.7, yes or no? Anything people would like in there? My list is: - Incorporate XOAUTH support - Fix

Re: [Nmh-workers] Maybe time for a new release?

Lyndon Nerenberg wrote: >> message numbers are, indeed, "the problem." when i asked mark crispen >> why IMAP was so hostile to the message numbering concepts of MH, he >> muttered something about MM. > But he did buy into, and accept, the UID concept. We had

Re: [Nmh-workers] Maybe time for a new release?

Ken Hornstein wrote: > them) to Maildir filenames. That seems solvable somehow. But the main > gain of Maildir seems to be lack of locking requirements ... am I > missing something? Is it more about interoperability with other > software? It's mostly about

Re: [Nmh-workers] Maybe time for a new release?

+5 for a new release. Ken Hornstein <k...@pobox.com> wrote: >> No, that's not true. We could decode on inc(1) to UTF-8. Every other >> MUA (effectively) does that these days. > Sigh. That doesn't help with image/jpeg, video/mpeg, application/pdf > ... a

Re: [Nmh-workers] Maybe time for a new release?

> On Mar 8, 2016, at 7:30 PM, Paul Vixie wrote: > > message numbers are, indeed, "the problem." when i asked mark crispen why > IMAP was so hostile to the message numbering concepts of MH, he muttered > something about MM. But he did buy into, and accept, the UID concept.

Re: [Nmh-workers] Maybe time for a new release?

Ken Hornstein wrote: > ... Is the real goal to search a Maildir store, or an IMAP store? The latter is something I've been thinking about on and off for a while noe. That should be relatively straigtforward to implement. i'd like something close to the full command line power of MH, when

Re: [Nmh-workers] Maybe time for a new release?

>> ... I hate >> to be the the one who has to explain this ... that hasn't been a realistic >> goal since the advent of MIME. The model that "email is text" just >> isn't valid anymore. > >i know. which is why i don't see much value in the mhdir layout. if >we're not going to go after it with

Re: [Nmh-workers] Maybe time for a new release?

If the goal is to have grep-able messages easily, two things come to mind: 1) my previous MIME-hooks scripts, which save the original message as #.msg, and then use mhmimefix to massage the message into something more human friendly. These can easily be extended. Or, you could just add your own

Re: [Nmh-workers] Maybe time for a new release?

>> And converting to UTF-8 is only a win _if_ your local character set is >> UTF-8. > >It's time to ditch locales. Make the native format utf8, and convert >back if you insist. Really, you know this is true. It's not me you have to convince, it's everyone else. --Ken

Re: [Nmh-workers] Maybe time for a new release?

> On Mar 8, 2016, at 6:45 PM, Ken Hornstein wrote: > > It > doesn't even really help that much with text/html. But when MUAs follow the guidelines, there will be an equivalent text/plain to do with that text/html, so the match will happen. If not, that's not nmh's problem.

Re: [Nmh-workers] Maybe time for a new release?

>No, that's not true. We could decode on inc(1) to UTF-8. Every other MUA >(effectively) does that these days. Sigh. That doesn't help with image/jpeg, video/mpeg, application/pdf ... all of those things which are not text. That's really my point. It doesn't even really help that much with

Re: [Nmh-workers] Maybe time for a new release?

> On Mar 8, 2016, at 6:19 PM, Ken Hornstein wrote: > > Let me explain my larger view. I know lots of people still want to be > able to use Unix text processing utilities on a MH store. But I hate > to be the the one who has to explain this ... that hasn't been a realistic >

Re: [Nmh-workers] Maybe time for a new release?

>in the past, a simple line oriented UNIX utility such as "grep -r" could >be used on the mhdir, with good results. with MIME that's no longer >true, either because of quoted-printable, base64, or nested objects. > >one solution proposed for this was to add some new helper tools similar >to

Re: [Nmh-workers] Maybe time for a new release?

where did we end on reformatting the mhdir to accommodate MIME? in the past, a simple line oriented UNIX utility such as "grep -r" could be used on the mhdir, with good results. with MIME that's no longer true, either because of quoted-printable, base64, or nested objects. one solution

Re: [Nmh-workers] Maybe time for a new release?

g else you want fixed before a new release? I am > thinking this would have enough to be called 1.7. Ken, I think that's a great way to politely move forward, AND make some headway toward sensibly keeping pace with the MIME environment. I don't have any "must have now" items on my

[Nmh-workers] Maybe time for a new release?

nge the world, maybe we should cut a new release. The last release was in June of 2014, and while I haven't been doing much in that time David Levine has been quietly adding new features and stomping on bugs. So maybe it makes sense to draw a line in the sand now and say, "Hey, this is the l

[Nmh-workers] New release candidate for nmh-1.4 - RC2

Greetings all, I am pleased to announce the availability of the second release candidate of nmh 1.4 (RC2). You can download it via links off of the nmh web page, which is at http://www.nongnu.org/nmh/ This release candidate fixes a problem with the new Maildir support code; it would prevent the

Re: [Nmh-workers] working towards a new release

Josh Bressers wrote: On 23 April 2008, Peter Maydell wrote: Unless anybody objects or has a better idea (or would like to do it themselves), I propose to do this (ie cvs tag -R -b release-1_3-branch), probably at the weekend, and then see if I can produce a 1.3RC1 tarball. Yes, please do. I

Re: [Nmh-workers] working towards a new release

Peter Maydell wrote: The branch name for 1.3 is nmh-1_3-branch, and the actual release is tagged as nmh-1_3_RC1. ...except I accidentally checked the DATE/VERSION/ChangeLog changes in on the trunk, and tagged the trunk. Whoops. I've propagated the changes over to the branch so that if/when we

[Nmh-workers] Ready to roll a new release?

I haven't paid much attention to stuff over the holidays. I did notice that Josh made a bunch of cosmetic changes (that I'm not sure that I agree with but hey, that's the way it goes). Are the NetBSD issues resolved at this point so that it's worth rolling a new release? Oh, and Happy New Year

Re: [Nmh-workers] Ready to roll a new release?

I haven't paid much attention to stuff over the holidays. I did notice that Josh made a bunch of cosmetic changes (that I'm not sure that I agree with but hey, that's the way it goes). I'm always up for feedback and discussion. I have the current goal of cleaning up the current codebase,

Re: [Nmh-workers] Ready to roll a new release?

Hi, I see a last issue. The problem happens in OpenBSD and NetBSD if the GNU version of the m4 macro language processor is not available. After applying the patch: ... The patch isn't the issue here. If I make a new release from the CVS, will it build and work correctly on *BSD

Re: [Nmh-workers] Ready to roll a new release?

I haven't paid much attention to stuff over the holidays. I did notice that Josh made a bunch of cosmetic changes (that I'm not sure that I agree with but hey, that's the way it goes). I'm always up for feedback and discussion. I have the current goal of cleaning up the current

Re: [Nmh-workers] Ready to roll a new release?

In message [EMAIL PROTECTED], Jon Steinhart writes: The patch isn't the issue here. If I make a new release from the CVS, will it build and work correctly on *BSD? The release won't include the patch as the code will already be patched. I would not expect issues here either. Just want

Re: [Nmh-workers] Ready to roll a new release?

. As a workaround I patched the nmh source code on a machine that has both autoconf and GNU m4 installed (in some way, it is the same steps nmh developers will do to make a new release from the CVS repository, though). But the patched tarball has problems building on machines that do not have GNU m4