Re: new release?

[David Levine]

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'"
 can be used with elinks, after setting charset as done above.  However,
 quoting becomes a nightmare because the argument must be quoted.  And
 with that, bad effects of malicious parameter value quoting, such as shown
 in test/mhshow/test-textcharset, seems very difficult to avoid.  It might
 be easier if the parameters are put into a temporary config-file.

Or maybe a permanent wrapper?

David

Re: new release?

[David Chin]

macOS 10.15.7
nmh version: 1.7+dev
host os: x86_64-apple-darwin19.6.0
compiler   : cc
compiler flags :  -g -O2 -Wall -Wextra
linker flags   : -Qunused-arguments
-L/usr/local/Cellar/openssl@3/3.0.3/lib
preprocessor flags :  -I/usr/local/Cellar/openssl@3/3.0.3/include

cc =
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0


1 of 117 tests failed
(1 test was not run) -- valgrind test not run

Failed test was mhfixmsg

*** /Users/foo/Src/nmh/test/testdir/test-mhfixmsg58801.expected 2022-05-04
02:22:53.0 +
--- /Users/foo/Src/nmh/test/testdir/test-mhfixmsg58801.actual   2022-05-04
02:22:53.0 +
***
*** 4,12 

  --mime-boundary
  Content-Type: text/plain; charset="utf-8"
! Content-Transfer-Encoding: 8bit

! νμχ

  --mime-boundary
  Content-Transfer-Encoding: 7bit
--- 4,12 

  --mime-boundary
  Content-Type: text/plain; charset="utf-8"
! Content-Transfer-Encoding: 7bit

! nmx

  --mime-boundary
  Content-Transfer-Encoding: 7bit

./test/mhfixmsg/test-mhfixmsg: test failed, outputs are in
/Users/foo/Src/nmh/test/testdir/test-mhfixmsg58801.expected and
/Users/foo/Src/nmh/test/testdir/test-mhfixmsg58801.actual.
first named test failure: use correct encoding for new text/plain part
FAIL: test/mhfixmsg/test-mhfixmsg

It's using elinks:

ELinks 0.11.7 (built on Oct 14 2019 00:45:54)

Features:
Standard, IPv6, gzip, bzip2, Periodic Saving, Timer, Cascading Style Sheets,
Protocol (File, FTP, HTTP, URI rewrite, User protocols), SSL (OpenSSL),
MIME (Option system, Mailcap, Mimetypes files), LED indicators, Bookmarks,
Cookies, Form History, Global History, Goto URL History, Search History


Switching to lynx passes the check:

Lynx Version 2.8.9rel.1 (08 Jul 2018)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 1.1.1n, ncurses 5.7.20081102
Built on darwin19.6.0 (Mar  4 2022 02:54:49).


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).

On Tue, Apr 19, 2022 at 10:19 PM David Levine  wrote:

> 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 we need to address.  Platforms such as the BSDs and Debian
> are blind spots for me.
>
> David
>
>

-- 
Email: david.w.h.c...@gmail.com
Mobile: 734.709.9119
https://linuxfollies.blogspot.com/  https://github.com/prehensilecode

Re: new release?

[David Levine]

> 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.
>
> > and then I can feed that to Apple Calendar.  I'd do that
> > myself, but I haven't had the time.  Would that be hard to add?
>
> If a REPLY could be fed to Calendar, all we'd need to do is save it.
> Maybe provide something analogous to the Fcc: of email messages?

So we already have that, see below.  I don't know how you use
mhical.  The pair of alternatives are intended for discussion.  If
they're not suitable (assuming they even work with Apple calendar),
they might help guide us towards something that is.

The calaccept alias in docs/contrib/replaliases uses repl(1)
(simplified a little):

\repl -noformat -editor mhbuild \
  -convertargs text/calendar "-reply accept -contenttype" \
  "$@"

Fcc's are stored as usual based on any profile settings, replcomps,
or -fcc on the command line.  mhstore(1) can then be used to extract
the .ics file from the fcc.

Another approach, assuming use of repl -convertargs text/calender,
would be to wrap what mhbuild-convert-text/calendar does in
mhn.defaults with a script that stores the output from nhical.  This
profile addition would override the default in mhn.defaults:

mhbuild-convert-text/calendar: /store_mhical_output %F

where store_mhical_output contains sonething like:

mhical -infile "$@" | tee /tmp/response.ics

David

Re: new release?

[David Levine]

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 hadn't fixed the test yet.  It seems that the timezone can be
reported as either + or -.  I did just commit a fix to use
+0100 instead of +.

David

Re: new release?

[Ralph Corderoy]

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 terminal with -v?

+1

-- 
Cheers, Ralph.

Re: new release?

[Ralph Corderoy]

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 isn't
expected in test/server.c's putcrlf().  It could easily be added to the
other expected errno values, but I wonder if none of those errno values
should be there and instead one of our clients is closing the connection
rather than reading to the end of what's being sent?

-- 
Cheers, Ralph.

Re: new release?

[Ralph Corderoy]

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 'f188de902b613110d5943210f212adb680a2b44a'’
which doesn't spell out the fix for those browsing the commit log.

‘git pull --rebase’ does it, and that option can be made the default.
As well as git-pull(1), there's an explanation in
https://git-scm.com/book/en/v2/Git-Branching-Rebasing

-- 
Cheers, Ralph.

Re: new release?

[Jay Vosburgh]

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 causes it to fail.  It's not a big test, would you be able to
>cut it down to try to isolate the source of those errors?

I don't have it totally worked out, but it's coming from
"fakehttp".  I put some debug in and got a core:

serve: pid 5325 PIDFN /tmp/fakehttp.pid
serve: pid 5327 PIDFN /tmp/fakesmtp.pid
serve: pid 5343 PIDFN /tmp/fakehttp.pid
serve: pid 5345 PIDFN /tmp/fakesmtp.pid
server writev s 0 errno 32 pid 5344 PIDFN /tmp/fakehttp.pid data .
serve: pid 5356 PIDFN /tmp/fakesmtp.pid
serve: pid 5366 PIDFN /tmp/fakehttp.pid

Core was generated by `/storage/src/nmh/test/fakehttp 
/storage/src/nmh/test/testdir/5088.http-req 6408'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7feb19897438 in __GI_raise (sig=sig@entry=0x6)
at ../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  0x7feb19897438 in __GI_raise (sig=sig@entry=0x6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7feb1989903a in __GI_abort () at abort.c:89
#2  0x00401a3d in putcrlf (socket=socket@entry=0x0, data=0x1f45010 ".")
at test/server.c:233
#3  0x00401116 in send_res (res=0x1f45240, conn=0x0)
at test/fakehttp.c:93
#4  main (argc=, argv=) at test/fakehttp.c:131

Frame 1 is a call to abort right after the printf (perror in the
original code) for the "server writev" message.

If I put in more debug printfs, the problem stops, so I'm
guessing it's a race somewhere.

-J

---
-Jay Vosburgh, jay.vosbu...@canonical.com

Re: new release?

[Simon Burge]

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 pull":

==
All 111 tests passed
(7 tests were not run)
==

Cheers,
Simon.

Re: new release?

[Alexander Zangerl]

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 all in line now).

what's left is a few historic compatibility bits (e.g. man pages to go
into the mh section) and some minor adjustments to
make the debian autobuilders happier (e.g. reproducible build bits).


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Erst wenn der letzte Programmierer eingesperrt und die letzte Idee
patentiert ist, werdet ihr merken, dass Anwälte nicht programmieren
können. -- Hopi mod Kulf


signature.asc
Description: Digital Signature

Re: new release?

[David Levine]

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.

> and then I can feed that to Apple Calendar.  I'd do that
> myself, but I haven't had the time.  Would that be hard to add?

If a REPLY could be fed to Calendar, all we'd need to do is save it.
Maybe provide something analogous to the Fcc: of email messages?  If
the REPLY line needs to be stripped out, that wouldn't be hard.

David

Re: new release?

[David Levine]

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 at the log file if indicates failure.

Should we output the summary to the terminal with -v?

David

Re: new release?

[David Levine]

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
> --- /home/simonb/src/mail/nmh/nmh-git/test/testdir/5969.actual  Wed Apr 20 
> 23:34:58 2022
> ***
> *** 1,5 
>   [ Message inbox:11 ]
> ! Date:Tue, 05 Mar 2002 18:20:35 +
>   To:  b...@example.edu
>   From:f...@example.edu
>   Subject: test
> --- 1,5 
>   [ Message inbox:11 ]
> ! Date:Tue, 05 Mar 2002 18:20:35 -
>   To:  b...@example.edu
>   From:f...@example.edu
>   Subject: test
>
> ./test/mhshow/test-cte-binary: 'C-T-E binary text' failed, outputs are in 
> /home/simonb/src/mail/nmh/nmh-git/test/testdir/5969.expected and 
> /home/simonb/src/mail/nmh/nmh-git/test/testdir/5969.actual.
> FAIL: test/mhshow/test-cte-binary

I'll fix that test.

David

Re: new release?

[David Levine]

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 Debian dependencies in MACHINES.

> Perhaps, if the tests would still work, it should accept regexps, filter
> ‘locale -a’ output with each in turn, as it does now, but sort the
> output in the C locale and use the first.  Then the calls could be
>
> require_locale '^en_..\.[Uu][Tt][Ff]-*8$'

I see that you committed a suitable temporary fix.  I like the regexp
approach if you want to implement that.

> Installing packages lynx and links didn't help ‘skipping html checks
> because no text browser was found’.  I realised they're needed before
> build_nmh runs.  Re-running build_nmh then allowed those browser-needing
> tests to pass.

The test suite did its job.

Thanks, Ralph.

David

Re: new release?

[David Levine]

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 timezone issues?

Right, Eric already fixed.

Thank you!

David

Re: new release?

[Ken Hornstein]

>> 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 use
"open" to open an iCal file and Calendar does the right thing.  But I
find I can't do that with a REQUEST; Calendar wants to "respond" to
it and thinks it is pending.  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) and then I can feed that to Apple Calendar.  I'd do that
myself, but I haven't had the time.  Would that be hard to add?

--Ken

Re: new release?

[David Levine]

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 immediately after that test-mhparam
is test/oauth/test-send.  I tried running it under "sh -x" but
that causes it to fail.  It's not a big test, would you be able to
cut it down to try to isolate the source of those errors?

> FAIL: test/mhical/test-mhical

Eric already fixed that one.

Thanks!

David

Re: new release?

[David Levine]

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?

[Paul Fox]

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 is part of autoconf.  From the documentation for AC_PROG_LEX:
...
 > Fixing this for the general case would be a bit of a pain; I'm not
 > sure there's a wonderful answer.  We could do something like outputting
 > a warning in configure if LEX equals ':' warning that you will need that
 > tool if you are building from a repository checkout, but that presumes
 > that people would actually read such a message :-)

Okay.  You convinced me.  :-)

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma)

Re: new release

[Steven Winikoff]

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 |  resembles being too tired."
http://smwonline.ca  |
 |  - Robert Heinlein

Re: new release?

[Ken Hornstein]

>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 the documentation for AC_PROG_LEX:

   If flex is found, set output variable LEX to ‘flex’ and LEXLIB
   to -lfl, if that library is in a standard place. Otherwise set LEX
   to ‘lex’ and LEXLIB to -ll, if found. If neither variant is
   available, set LEX to ‘:’; for packages that ship the generated
   file.yy.c alongside the source file.l, this default allows users
   without a lexer generator to still build the package even if the
   timestamp for file.l is inadvertently changed.

We're in this situation; we ship the flex output in distribution tar
files (Automake does that for us).  Where this fails is when you build
directly from a repo checkout, as the generates flex/bison output isn't
there.

Fixing this for the general case would be a bit of a pain; I'm not
sure there's a wonderful answer.  We could do something like outputting
a warning in configure if LEX equals ':' warning that you will need that
tool if you are building from a repository checkout, but that presumes
that people would actually read such a message :-)

--Ken

Re: new release?

[Paul Fox]

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 repo, the problem became more apparent, since sbr/dtimep.c
came up missing.  It comes from sbr/dtimep.l, which meant lex/flex was
missing.

I should have checked for that when I realized yacc was missing.  Oh well.

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.

Anyway, after installing flex, all is well on Ubuntu 20.

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma)

Re: new release?

[Eric Gillespie]

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 f188de902b613110d5943210f212adb680a2b44a to master
now, which should resolve this test failure.

With that on master, I can report that a plain
`./configure && make && make check` passes on FreeBSD 12.3-RELEASE-p5.
and also `--with-cyrus-sasl --with-tls --with-oauth`.

Thanks, and good luck with the release!

Re: new release?

[Ralph Corderoy]

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.

$ ./build_nmh 
Install prefix [/usr/local/nmh]: /tmp/nmh
Locking type (dot|fcntl|flock|lockf) [determined by configure]: 
MTS (smtp|sendmail/smtp|sendmail/pipe) [smtp]: 
SMTP server [localhost]: 
Cyrus SASL support (y|n) [determined by configure]: 
TLS support (y|n) [determined by configure]: 
$

They're tacked onto the end of the log file, as if the restoration of
stdout failed.

$ tail -4 build_nmh.log | sed -n l
===$
\033[0;32mAll 100 tests passed\033[m$
\033[0;32m(18 tests were not run)\033[m$
===$
$

-- 
Cheers, Ralph.

Re: new release?

[Ralph Corderoy]

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 sbr/icalendar.c -- :  
> make[1]: *** [Makefile:4673: sbr/icalendar.c] Error 1
> make[1]: Leaving directory '/home/pgf/src/pdom/nmh/nmh.git'
> make: *** [Makefile:1902: all] Error 2

Here's how make runs it for me.

/bin/sh ./ylwrap sbr/icalendar.l lex.yy.c sbr/icalendar.c -- flex  

So your .c should be lex.yy.c or similar depending what your lex(1)
produces.  The argument are

Usage: ylwrap [--help|--version] INPUT [OUTPUT DESIRED]... -- \
  PROGRAM [ARGS]...

Wrapper for lex/yacc invocations, renaming files as desired.

  INPUT is the input file
  OUTPUT is one file PROG generates
  DESIRED is the file we actually want instead of OUTPUT
  PROGRAM is program to run
  ARGS are passed to PROG

Any number of OUTPUT,DESIRED pairs may be used.

-- 
Cheers, Ralph.

Re: new release

[Jerry Heyman]

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 reason with unreasonable 
\\ //   heymanj at acm dot org | people.  This reduces your correspondence
 \X/   | and your blood pressure.

Re: new release?

[Simon Burge]

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:

===
2 of 111 tests failed
(7 tests were not run)
Please report to nmh-workers@nongnu.org
===

Details below.  First time I've run these tests, hope this is helpful.

Cheers,
Simon.


./test/inc/test-deb359167: skipped: missing valgrind
SKIP: test/inc/test-deb359167
./test/oauth/test-inc: skipped: no oauth support
SKIP: test/oauth/test-inc
./test/oauth/test-mhlogin: skipped: no oauth support
SKIP: test/oauth/test-mhlogin
./test/oauth/test-mhparam: skipped: no oauth support
SKIP: test/oauth/test-mhparam
./test/oauth/test-send: skipped: no oauth support
SKIP: test/oauth/test-send
./test/oauth/test-sendfrom: skipped: no oauth support
SKIP: test/oauth/test-sendfrom
./test/oauth/test-share: skipped: no oauth support
SKIP: test/oauth/test-share


*** /home/simonb/src/mail/nmh/nmh-git/test/testdir/test-mhical1207.expected 
2022-04-20 23:34:46.059703147 +1000
--- /home/simonb/src/mail/nmh/nmh-git/test/testdir/test1.txt2022-04-20 
23:34:46.065044863 +1000
***
*** 1,12 
  Method: REQUEST
  Organizer: Requester
  Summary: test request
! At: Mon, 05 Jan 2015 09:00 -0500
! To: Mon, 05 Jan 2015 09:30
  Attendees: Requestee1, Requestee2, Requestee3

  Organizer: Requester
  Summary: test request
! At: Mon, 05 Jan 2015 13:00 -0500
! To: Mon, 05 Jan 2015 13:45
  Attendees: Requestee2, Requestee3
--- 1,12 
  Method: REQUEST
  Organizer: Requester
  Summary: test request
! At: Tue, 06 Jan 2015 01:00 +1100
! To: Tue, 06 Jan 2015 01:30
  Attendees: Requestee1, Requestee2, Requestee3

  Organizer: Requester
  Summary: test request
! At: Tue, 06 Jan 2015 05:00 +1100
! To: Tue, 06 Jan 2015 05:45
  Attendees: Requestee2, Requestee3

./test/mhical/test-mhical: test failed, outputs are in 
/home/simonb/src/mail/nmh/nmh-git/test/testdir/test-mhical1207.expected and 
/home/simonb/src/mail/nmh/nmh-git/test/testdir/test1.txt.
first named test failure: display of multiple vevent requests in single 
vcalendar
FAIL: test/mhical/test-mhical




*** /home/simonb/src/mail/nmh/nmh-git/test/testdir/5969.expectedWed Apr 
20 23:34:58 2022
--- /home/simonb/src/mail/nmh/nmh-git/test/testdir/5969.actual  Wed Apr 20 
23:34:58 2022
***
*** 1,5 
  [ Message inbox:11 ]
! Date:Tue, 05 Mar 2002 18:20:35 +
  To:  b...@example.edu
  From:f...@example.edu
  Subject: test
--- 1,5 
  [ Message inbox:11 ]
! Date:Tue, 05 Mar 2002 18:20:35 -
  To:  b...@example.edu
  From:f...@example.edu
  Subject: test

./test/mhshow/test-cte-binary: 'C-T-E binary text' failed, outputs are in 
/home/simonb/src/mail/nmh/nmh-git/test/testdir/5969.expected and 
/home/simonb/src/mail/nmh/nmh-git/test/testdir/5969.actual.
FAIL: test/mhshow/test-cte-binary

Re: new release?

[Paul Fox]

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.

$ make
make  all-am
make[1]: Entering directory '/home/pgf/src/pdom/nmh/nmh.git'
/bin/bash ./ylwrap sbr/icalendar.l .c sbr/icalendar.c -- :  
make[1]: *** [Makefile:4673: sbr/icalendar.c] Error 1
make[1]: Leaving directory '/home/pgf/src/pdom/nmh/nmh.git'
make: *** [Makefile:1902: all] Error 2

I think the problem lies in the invocation of ylwrap, but I'm not
sure where to go from there.

paul

=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma)

Re: new release?

[Ralph Corderoy]

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 doesn't satisfy configure's search.

checking for dbm in ndbm.h... no
checking for dbm in db.h and db... no
checking for dbm in ndbm.h and db... no
checking for dbm in ndbm.h and db1... no
checking for dbm in ndbm.h and ndbm... no
checking for dbm in db1/ndbm.h and db1... no
checking for dbm in gdbm/ndbm.h and gdbm... no
checking for dbm in gdbm/ndbm.h and gdbm_compat -lgdbm... no
checking for dbm in ndbm.h and gdbm... no
checking for dbm in ndbm.h and gdbm_compat -lgdbm... no
checking for dbm in gdbm-ndbm.h and gdbm_compat... no
configure: error: could not find a working ndbm library/header combination
see nmh MACHINES file for build dependences

There's no gdbm-devel, but there is libgdbm-dev and installing that
still didn't help configure; I got the same output as above.

db.h is present, but the other test above still fails, presumably
correctly because it's changed too much.

libdb5.3-dev: /usr/include/db.h

Ah, ndbm.h is in

libgdbm-compat-dev: /usr/include/gdbm-ndbm.h
libgdbm-compat-dev: /usr/include/ndbm.h

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)

A separate ‘make check’ shows lots of tests ‘skipped: no suitable locale
available’.

$ locale -a
C
C.UTF-8
en_GB.utf8
POSIX
$
$ git grep require_locale
test/common.sh.in:require_locale ()
test/dist/test-dist:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/format/test-ap:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/mhbuild/test-attach:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/mhbuild/test-cte:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/mhbuild/test-ext-params:require_locale en_US.UTF-8 en_US.UTF8 
en_US.utf-8 en_US.utf8
test/mhbuild/test-header-encode:require_locale en_US.UTF-8 en_US.UTF8 
en_US.utf-8 en_US.utf8
test/mhbuild/test-utf8-body:require_locale en_US.UTF-8 en_US.UTF8 
en_US.utf-8 en_US.utf8
test/mhfixmsg/test-mhfixmsg:require_locale en_US.UTF-8 en_US.UTF8 
en_US.utf-8 en_US.utf8
test/mhical/test-mhical:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/mhl/test-format:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/mhl/test-rfc6532:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/mhlist/test-ext-params:require_locale en_US.UTF-8 en_US.UTF8 
en_US.utf-8 en_US.utf8
test/mhshow/test-charset:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/mhshow/test-textcharset:require_locale en_US.UTF-8 en_US.UTF8 
en_US.utf-8 en_US.utf8
test/pick/test-pick:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/post/test-rfc6531:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/repl/test-convert:require_locale en_US.UTF-8 en_US.UTF8 en_US.utf-8 
en_US.utf8
test/scan/test-scan-multibyte:require_locale en_US.UTF-8 en_US.UTF8 
en_US.utf-8 en_US.utf8
$

I see require_locale treats its argument as a grep(1) regexp but the
dots aren't escaped.

# Skip test if none of the offered locales are supported.
# As side effect, use the first locale that is found.  Note that
# some platforms allow, by way of example, en_US.UTF-8 to be used
# even though en_US.UTF8 is listed by locale -a.  But by setting
# LC_ALL here, we don't rely on that.
require_locale ()
{
  for locale in "$@"; do
if locale -a | grep -i "$locale" >/dev/null; then
LC_ALL="$locale"; export LC_ALL
return
fi
  done

  test_skip "no suitable locale available"
}

Perhaps, if the tests would still work, it should accept regexps, filter
‘locale -a’ output with each in turn, as it does now, but sort the
output in the C locale and use the first.  Then the calls could be

require_locale '^en_..\.[Uu][Tt][Ff]-*8$'

As a quick test of a non-US locale, altering require_locale() to

 require_locale ()
 {
+LC_ALL=en_GB.utf8; export LC_ALL
+return
+

got most locale-using tests to pass.  test/mhbuild/test-utf8-body still
wasn't happy because it hard-codes ‘en_US.UTF-8’.  Using LC_ALL set by
require_locale() instead had the test pass.

diff --git a/test/mhbuild/test-utf8-body b/test/mhbuild/test-utf8-body
index e3903ae6..2022e98f 100755
--- a/test/mhbuild/test-utf8-body
+++ b/test/mhbuild/test-utf8-body
@@ -174,6 +174,7 @@ Nmh-Attach: $MH_TEST_DIR/attachment.txt
 ¡Ay, caramba!
 EOF
 
+found_locale=$LC_ALL
 

Re: new release?

[Alexander Zangerl]

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, massaged it a bit with the (few remaining) debian-specific
patches, and built it.

one test fails: mhical apparently has timezone issues?
not sure, no icalendar user, but i'm in gmt +1000.

*** /home/az/src/debian/nmh/nmh-1.7.2/test/testdir/test-mhical20684.expected
2022-04-20 17:55:16.187725294 +1000
--- /home/az/src/debian/nmh/nmh-1.7.2/test/testdir/test1.txt2022-04-20 
17:55:16.188725276 +1000
***
*** 1,12 
  Method: REQUEST
  Organizer: Requester
  Summary: test request
! At: Mon, 05 Jan 2015 09:00 -0500
! To: Mon, 05 Jan 2015 09:30
  Attendees: Requestee1, Requestee2, Requestee3
  
  Organizer: Requester
  Summary: test request
! At: Mon, 05 Jan 2015 13:00 -0500
! To: Mon, 05 Jan 2015 13:45
  Attendees: Requestee2, Requestee3
--- 1,12 
  Method: REQUEST
  Organizer: Requester
  Summary: test request
! At: Tue, 06 Jan 2015 00:00 +1000
! To: Tue, 06 Jan 2015 00:30
  Attendees: Requestee1, Requestee2, Requestee3
  
  Organizer: Requester
  Summary: test request
! At: Tue, 06 Jan 2015 04:00 +1000
! To: Tue, 06 Jan 2015 04:45
  Attendees: Requestee2, Requestee3

...
first named test failure: display of multiple vevent requests in single
vcalendar
FAIL: test/mhical/test-mhical


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
PHB: "According to M$ Project, your utilization level is 1850%."
CS: "You mean I have a load average of 18.5?"  -- Charlie Stross


signature.asc
Description: Digital Signature

Re: new release?

[Ralph Corderoy]

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 branches with the current one highlighted:
git branch

To describe the commit which is checked out:
git describe --long --tags --candidates=1000

-- 
Cheers, Ralph.

Re: new release?

[Howard Bampton]

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
cd nmh/
cat VERSION
1.7+dev
 ./autogen.sh
 ./configure
  make
make check


All 117 tests passed
(1 test was not run)

Re: new release?

[Jay Vosburgh]

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 Ubuntu 16.04 and
22.04 beta.  Clean build on 22.04; 16.04 got the following compiler
warnings:

sbr/dtimep.c: In function ‘yy_get_next_buffer’:
sbr/dtimep.c:1856:44: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
  if ((int) ((yy_n_chars) + number_to_move) > 
YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
^

sbr/icalendar.c: In function ‘yy_get_next_buffer’:
sbr/icalendar.c:1456:44: warning: comparison between signed and unsigned 
integer expressions [-Wsign-compare]
  if ((int) ((yy_n_chars) + number_to_move) > 
YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
^

Test failures were the same for both releases (1 FAIL, below).
Due to various things not being installed, both cases skipped the
valgrind test, and 22.04 also skipped the oauth tests.  Both releases
saw a spew of "Broken pipe" errors after test-mhparam, not sure if
that's expected or not.

The relevant excerpt (from 16.04):

*** /storage/src/nmh/test/testdir/test-mhical15275.expected 2022-04-19 
21:46:57.924332720 -0700
--- /storage/src/nmh/test/testdir/test1.txt 2022-04-19 21:46:57.932332791 
-0700
***
*** 1,12 
  Method: REQUEST
  Organizer: Requester
  Summary: test request
! At: Mon, 05 Jan 2015 09:00 -0500
! To: Mon, 05 Jan 2015 09:30
  Attendees: Requestee1, Requestee2, Requestee3
  
  Organizer: Requester
  Summary: test request
! At: Mon, 05 Jan 2015 13:00 -0500
! To: Mon, 05 Jan 2015 13:45
  Attendees: Requestee2, Requestee3
--- 1,12 
  Method: REQUEST
  Organizer: Requester
  Summary: test request
! At: Mon, 05 Jan 2015 06:00 -0800
! To: Mon, 05 Jan 2015 06:30
  Attendees: Requestee1, Requestee2, Requestee3
  
  Organizer: Requester
  Summary: test request
! At: Mon, 05 Jan 2015 10:00 -0800
! To: Mon, 05 Jan 2015 10:45
  Attendees: Requestee2, Requestee3

./test/mhical/test-mhical: test failed, outputs are in 
/storage/src/nmh/test/testdir/test-mhical15275.expected and 
/storage/src/nmh/test/testdir/test1.txt.
first named test failure: display of multiple vevent requests in single 
vcalendar
FAIL: test/mhical/test-mhical
[...]
PASS: test/oauth/test-mhparam
server writev: Broken pipe

[previous line repeats ~5500 times]

server writev: Broken pipe
PASS: test/oauth/test-send
[...]
===
1 of 117 tests failed
(1 test was not run)
Please report to nmh-workers@nongnu.org
===
Makefile:4872: recipe for target 'check-TESTS' failed
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory '/storage/src/nmh'
Makefile:5128: recipe for target 'check-am' failed
make: *** [check-am] Error 2

-J

---
-Jay Vosburgh, jay.vosbu...@canonical.com

Re: new release?

[Andy Bradford]

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.-DNMHBINDIR='"/usr/local/bin"'  
-DNMHLIBEXECDIR='"/usr/local/libexec/nmh"'  -DNMHETCDIR='"/usr/local/etc/nmh"'  
-DNMHDOCDIR='"/usr/local/share/doc/nmh"'  -DMAILSPOOL='"/var/mail"'  
-DSENDMAILPATH='"/usr/sbin/sendmail"'   -g -O2 -Wall -Wextra -MT 
sbr/sbr_libmh_a-fmt_rfc2047.o -MD -MP -MF sbr/.deps/sbr_libmh_a-fmt_rfc2047.Tpo 
-c -o sbr/sbr_libmh_a-fmt_rfc2047.o `test -f 'sbr/fmt_rfc2047.c' || echo 
'./'`sbr/fmt_rfc2047.c
sbr/fmt_rfc2047.c:391:12: error: use of undeclared identifier 'initialdstlen'
return initialdstlen - dstlen;
   ^
sbr/fmt_rfc2047.c:399:12: error: use of undeclared identifier 'initialdstlen'
return initialdstlen - dstlen - 1;
   ^
sbr/fmt_rfc2047.c:72:66: warning: unused parameter 'dest_charset'
  [-Wunused-parameter]
decode_rfc2047 (char *str, char *dst, size_t dstlen, const char *dest_charset)
 ^
1 warning and 2 errors generated.
*** Error 1 in /tmp/nmh (Makefile:3435 'sbr/sbr_libmh_a-fmt_rfc2047.o')

Andy

Re: new release?

[David Levine]

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 we need to address.  Platforms such as the BSDs and Debian
are blind spots for me.

David

Re: new release?

[Ken Hornstein]

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

[David Levine]

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, or enhancements they're working on?

I closed a few bugs recently, but don't have the time to handle any more.
If anyone does, they're at https://savannah.nongnu.org/bugs/?group=nmh

David

Re: New release?

[Kevin Cosgrove]

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?

[David Levine]

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?

[Ken Hornstein]

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 improvements.  The
only thing I can think of is cleaning up file descriptor handling (marking
all descriptors as "close on EXEC" unless there is a need).  I am open to
other suggested improvements, as long as they are small (for this release,
I mean).

--Ken

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

[David Levine]

Norm wrote:

> Much of that was not clear to me from the man page. But that may say more
> about me than about the man page.

I don't know about that.  In any case, I added all of it to the man page this 
morning.  I expect that it will be useful to others.  Keep the questions coming.

David

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

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

[norm]

>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 $ grep family `mhpath cur`
>
>Some of us run mhfixmsg on our messages as we inc them, so we can then use
>grep, etc., directly.
>
>If you don't want to modify the message:
>
>$ mhfixmsg -outfile - | grep family
>
>-outfile can be abbreviated in usual MH fashion.

That works for me. Thank you.

>Those commands will output all the lines, in all parts, of the message. You
>asked "of that part". To just grep one or more specific parts, you could use
>mhstore, but that has nothing to do with (and precedes) mhfixmsg.
>
>> 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
>
>It doesn't matter whether you know that the message has UTF-8 content, or
>quotedPrintable or base64 encoding. mhfixmsg won't decode or change the
>character set if it doesn't have to.
>
>And it's safe to run mhfixmsg multiple times on a message.

Much of that was not clear to me from the man page. But that may say more
about me than about the man page.

Norman Shapiro

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

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

[David Levine]

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
$ grep family `mhpath cur`

Some of us run mhfixmsg on our messages as we inc them, so we can then use 
grep, etc., directly.

If you don't want to modify the message:

$ mhfixmsg -outfile - | grep family

-outfile can be abbreviated in usual MH fashion.

Those commands will output all the lines, in all parts, of the message.  You 
asked "of that part".  To just grep one or more specific parts, you could use 
mhstore, but that has nothing to do with (and precedes) mhfixmsg.

> 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

It doesn't matter whether you know that the message has UTF-8 content, or 
quotedPrintable or base64 encoding.  mhfixmsg won't decode or change the 
character set if it doesn't have to.

And it's safe to run mhfixmsg multiple times on a message.

David

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

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

[Ken Hornstein]

>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 "family".  What command go I feed into 'grep family"?

mhfixmsg rewrites a message completely.  The model is that you run it
once on a message, and it will be in a form that is Unix text-tool
friendly.

--Ken

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

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

[norm]

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 made that reasonably easily possible.
>
>That's the main motivation for mhfixmsg.  The man page describes it in detail, 
>esp. with the new EXAMPLES that I posted earlier.  If you have any questions, 
>please let us/me know.

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 "family".  What command go I feed into 'grep family"?

Norman Shapiro

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

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

[Conrad Hughes]

David> There's been a procmail recipe in the man page since March of
David> 2013, under "Integration with procmail".

.. now I feel like a true child of the web.  I have looked at that
manpage many times since mhfixmsg got mentioned recently.  I obviously
never read below the fold.  Thanks/sorry.

C.

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

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

[David Levine]

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 of 2013, under 
"Integration with procmail".

> I've tried running mhfixmsg across a selection of my email, and encountered a 
> mixture of complaints and occasional dumped cores (which I'll investigate and 
> report on — it may be that my Debian nmh-1.6-2 has bugs not present in the 
> current version).

Possible, there have been bug fixes over the years, not sure what Debian has 
ended up with.  It's so easy to download and build the latest, assuming you 
have modern autoconf, etc., so I recommend that instead of chasing down bugs in 
an older version:

$ git clone git://git.savannah.nongnu.org/nmh.git
$ cd nmh
$ docs/contrib/build_nmh -div

The -i option to build_nmh will install, in the location that it prompts you 
for.

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

Yes, I use the procmail recipe that's in the man page.  It saves a backup of 
each message in case you want.  I've never had to look at a backup.

David

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

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

[David Levine]

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 necessary 
in your profile (unless they're needed to override something else that you're 
doing).

David

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

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

[David Levine]

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 main motivation for mhfixmsg.  The man page describes it in detail, 
esp. with the new EXAMPLES that I posted earlier.  If you have any questions, 
please let us/me know.

David

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

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

[norm]

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 latest release makes that easy as well?
>
>Does Norm have a non UTF-8 locale?  That rings a bell.

running the locale command yields:

LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

Norman Shapiro

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

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

[Jerrad Pierce]

>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 auto-processing messages with mhfixmsg for over a year.
The worst I've had happen is that the message failed to get fixed on
the automatic run and I was confronted with classical HTML mail garbage
when I displayed a message before reprocessing it.

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

to achieve this. (I file everything into SPAM by default, and I have
an alias for inc that refiles things into inbox that SpamAssassin says
taste like ham ;-)

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

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

[Ralph Corderoy]

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 a non UTF-8 locale?  That rings a bell.

Cheers, Ralph.

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

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

[Conrad Hughes]

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 (more-or-less covered a few emails back) and a procmail
recipe.

I've tried running mhfixmsg across a selection of my email, and
encountered a mixture of complaints and occasional dumped cores (which
I'll investigate and report on — it may be that my Debian nmh-1.6-2 has
bugs not present in the current version).

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?

Conrad

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

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

[Ken Hornstein]

>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 makes that easy as well?  It sounds like
the only thing lacking from 1.6 in this area is documentation.

--Ken

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

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

[norm]

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 utf-8
>>
>> How do I translate, to utf-8, all parts of a message, which can be
>> reasonably translated to utf-8? The first such part?
>
>mhfixmsg doesn't currently support either of those. It's not clear to me how
>to determine "can be reasonably translated to utf-8". We've discussed this
>here recently, and Ralph raised the counterexample of an html page relying on
>a particular charset.
>
>And I'll resist making the tool even more complicated by adding interfaces to
>select which parts to touch. So it's none or all, unless there would be a
>real benefit to translate only specified parts.

Let me start this thread from scratch.

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.


Norman Shapiro

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

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

[Ken Hornstein]

>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 character sets without parsing
HTML (it's not clear to me if the HTML character encoding is windows-1252
what exactly happens with something like €, just to give an example).
So at a basic level, the safest thing to do is only deal with text/plain.
I was under the impression that most users of mhfixmsg really only want
text/plain anyway.  And while it is possible to have multiple text/plain
parts, I think email has devolved enough that really, in practice, you're
only getting one text/plain part at the beginning.  So I think the current
behavior of mhfixmsg only performing character conversion on text/plain
is perfectly reasonable.

--Ken

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

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

[Ken Hornstein]

>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 the back burner ... and here we are.

I understand, it's a bit complicated.  If you're willing to refresh it,
please do.  Maybe I'll ping you off-list to fill in some of the protocol
details.

I agree with David; leave it on the branch for now.  

--Ken

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

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

[David Levine]

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 of a message,
> which can be reasonably translated to utf-8? The first such part?

mhfixmsg doesn't currently support either of those.  It's not clear to me how 
to determine "can be reasonably translated to utf-8".  We've discussed this 
here recently, and Ralph raised the counterexample of an html page relying on a 
particular charset.

And I'll resist making the tool even more complicated by adding interfaces to 
select which parts to touch.  So it's none or all, unless there would be a real 
benefit to translate only specified parts.

David

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

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

[David Levine]

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 haven't 
been able to devote enough time to it.  Anything you can do to walk me/us 
through use would help.

Thanks.

David

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

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

[norm]

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
>default transformations to fix MIME boundaries and Content-Transfer-
>Encoding, to decode text and application/ics content parts to 8 bit,
>and to add a corresponding text/plain part where lacking:
>
>mhfixmsg -verbose
>
>View without modification
>To view the MIME structure that would result from running mhfixmsg on
>the current message, without modifying the message:
>
>mhfixmsg -outfile - | mhlist -file -
>
>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 of a message,
which can be reasonably translated to utf-8? The first such part?


Norman Shapiro

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

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

[Eric Gillespie]

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.

Thanks.

On Tue, Mar 8, 2016, 4:25 PM Ken Hornstein  wrote:

> I've been itching to do some MIME refactoring, and by "refactoring" I
> mean completely doing a new message/MIME parser from the ground up,
> based on flex/bison (at least parse headers using flex, maybe address
> parsing via bison ... we'll see) and have a completely new internal API.
> See "full MIME integration" email and "vague, 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 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 last release under the old MIME code".  Or if that
> doesn't happen, we'll do another "last release".  Or we'll just keep
> limping along with our crappy MIME code (I sure hope not).
>
> The two things I think that should be worked on for a new release is
> fixing the problem when during message display iconv() fails to convert
> a character (just substitute a '?' is fine, I think) and bringing over
> the XOAUTH2 code that Eric Gillespie did (I've been meaning to do it
> because it is a lot of work that I'd hate to lose).  The first issue,
> at least, should be easy.
>
> What do people think of this idea?  If you like this idea, is there
> anything else you want fixed before a new release?  I am thinking this
> would have enough to be called 1.7.
>
> --Ken
>
> ___
> Nmh-workers mailing list
> Nmh-workers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
>
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[David Levine]

Ken 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 the target character set).

Sounds good to me.  I'd also like to have mhfixmsg decode to binary content.  
That's trivial, but I need to verify that the rest of nmh can handle that.  Not 
sure when I'll get to it.

XOAUTH support is a blocker.

David

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

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

[David Levine]

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 boundaries and Content-Transfer-
   Encoding, to decode text and application/ics content parts to 8 bit,
   and to add a corresponding text/plain part where lacking:

  mhfixmsg -verbose

   View without modification
   To view the MIME structure that would result from running mhfixmsg on
   the current message, without modifying the message:

  mhfixmsg -outfile - | mhlist -file -

   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

David

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

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

[Paul Vixie]

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 more of a
mail drop box (someplace you put messages so someone else can come along
and grab them).  Like, the original Maildir specification did not permit
subfolders (it looks like there is something called Maildir++, which does).


Maildir just means what Maildir++ used to mean, now. here's what 
Dovecot2 made for me when i created a w/spam/sunbelt folder in Postbox, 
for example:



[family.redbarn:amd64] ls -lR Maildir/.w.spam.sunbelt
total 21
drwxrwxr-x  2 vixie  staff 6 Jan 24 04:06 cur/
-rw-rw-r--  1 vixie  staff10 Jan 24 04:06 dovecot-keywords
-rw-rw-r--  1 vixie  staff   291 Oct  8 04:43 dovecot-uidlist
-rw-rw-r--  1 vixie  staff  4636 Feb 29 03:44 dovecot.index.cache
-rw-rw-r--  1 vixie  staff  1184 Jan 24 20:19 dovecot.index.log
drwxrwxr-x  2 vixie  staff 2 May 10  2015 new/
drwxrwxr-x  2 vixie  staff 2 Mar  4 10:43 tmp/

Maildir/.w.spam.sunbelt/cur:
total 275
-rw-r--r--  1 vixie  staff4155 May 10  2015 
1431239881.M607591P59215.family.redbarn.org:2,a
-rw-r--r--  1 vixie  staff6113 May 10  2015 
1431239881.M611137P59216.family.redbarn.org:2,a
-rw-r--r--  1 vixie  staff1612 May 10  2015 
1431239881.M614599P59217.family.redbarn.org:2,a
-rw-r--r--  1 vixie  staff  237451 May 10  2015 
1431239881.M617919P59218.family.redbarn.org:2,a

Maildir/.w.spam.sunbelt/new:
total 0

Maildir/.w.spam.sunbelt/tmp:
total 0


so, i think mapping the MH message number to "basename before :" would work.

--
P Vixie

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

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

[Ken Hornstein]

>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 
>for Maildir i don't know if there are UID's.

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 more of a
mail drop box (someplace you put messages so someone else can come along
and grab them).  Like, the original Maildir specification did not permit
subfolders (it looks like there is something called Maildir++, which does).

--Ken

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

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

[Paul Vixie]

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 the current set
 >  of messages visible withing a folder. UIDs never change (for all
 >  practical purposes), whereas sequence numbers change all the time.

So, if we forbid "pack", we can have UIDs rather than sequence numbers?


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.


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 
for Maildir i don't know if there are UID's.


--
P Vixie

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

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

[Ken Hornstein]

>But the bulk of the, non-spam, EMail I receive, still has at least one part in
>UTF-8 or quotedPrintable. I know that I can use mhfixmsg to apply UNIX text
>processing tools to these parts, but I'm not very facile at that. Maybe
>Contributions should have a tutorial script or two which illustrate good ways
>to do that?

It seems to me those would be great things to put in an EXAMPLES section
of mhfixmsg(1).

--Ken

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

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

[Lyndon Nerenberg]

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.


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

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

[norm]

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 model that "email is text" just
>isn't valid anymore.

But the bulk of the, non-spam, EMail I receive, still has at least one part in
UTF-8 or quotedPrintable. I know that I can use mhfixmsg to apply UNIX text
processing tools to these parts, but I'm not very facile at that. Maybe
Contributions should have a tutorial script or two which illustrate good ways
to do that?

Norman Shapiro

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

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

[Michael Richardson]

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 visible withing a folder. UIDs never change (for all
> practical purposes), whereas sequence numbers change all the time.

So, if we forbid "pack", we can have UIDs rather than sequence numbers?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


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

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

[Lyndon Nerenberg]

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 purposes), whereas sequence numbers change all the time.


--lyndon


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

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

[Kevin Cosgrove]

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 the target character set).

Yes.

Your list looks fine.

Thanks

--
Kevin



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

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

[Paul Vixie]

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 mhdir layout. if we're not 
going to go after it with "grep -r" any more, then we should consider using 
Maildir format instead, for all of its advantages. (also i'd love to have good 
command line tools for managing maildirs, my wife's inbox has to be archived 
annually, which today i do via Thunderbird, which bites.)

you won't believe what you said next, though!

> ... So to me, trying to use Unix text processing tools on RFC-5322
> format files in 2016 is simply a fool's errand.  Yeah, it may work fine ...
> but you're guaranteed to have it not work at some point.  And we can't
> really fix that without breaking a long-standing guarantee.

that guarantee is helping precisely nobody now. whether mail is or isn't text, 
or whether mail is or isn't a file, makes no difference to anyone if the only 
way to access it is via the MH commands and/or library.

it might as well me in berkeley db at this stage. or maildir. or IMAP.

the only advantage is that the files i accumulated for 25 years in ~/Mail are 
immutable, except where they aren't like anno(1). and i guess there's some 
benefit to not having to convert them to a new format, except i already do, 
since i want to access them in IMAP, which means i have to convert them to 
Maildir.

so, while i appreciate the design level purity of just wanting a better API and 
let's not also fiddle with the on-disk format, i argue that you're preserving a 
benefit that no longer exists, because nothing other than your API is going to 
be able to access this data.

you seem uncertain of this, however:

> ... If we want to have the MH store consist of "email", then it can't
> be text.  If we want to change the concept of what an MH store is, then
> that would break a lot of third-party tools.

the only third party tools that are still working are those which understand 
on-disk MIME (as received over SMTP). of those, the only ones that will break 
will be those which do not adopt your new API.

how many tools is that? as far as i know: just the various MH-only graphical 
shells. i don't see those as a growth area in information technology. new 
graphical e-mail shells use IMAP, and the on-disk format used by MH is somewhat 
incompatible with IMAP, as those of us who spent 25 years keeping uw-imapd 
working for MH can explain in some detail. (sequences? sortm? folder --pack? 
PFA!)

> 
> So, getting around to my larger point ... my goal here is to make it
> so all of the MIME tools natively deal with MIME.  That means the
> standard internal API is MIME-aware, things like %{body} in scan(1) are
> MIME-aware (it could be the decoded version of the first text part), and
> "pick" would know how to search inside a MIME-encoded text part after
> converting everything to the native character set.  You get the idea.
> This requires a new API, parsing routines, etc etc ... that's the part
> I'd like to work on.

please don't let me dissuade you. nmh would be much cleaner with what you're 
proposing.

> ... I
> don't recall a suggestion about helper tools a la find(1) and/or xargs,
> but that could just be my memory going; I'm not sure how that would
> work. ...

imagining for a moment that something somebody wants to do can't be done with 
pick or rmm or refile even with a new, better, and universal MIME API, i think 
we need some outreach to UNIX command line tools, like an option to mhpath or 
mhstore that uses FUSE or even temporary files to offer a read only set of 
paths that "xargs egrep" would work for.

> So, I guess the TL;DR answer is:
> 
> - There were lots of ideas, but nothing concrete in terms of people
>   volunteering to write code.
> - I wasn't planning on doing anything like that as part of my work.
>   My work wouldn't stop that and might make it easier.

thank you for explaining. if you hear about an MH-similar set of commands that 
works on Maildir stores, please point it my way. less and less of my archives 
are still in MH format.

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

[Nmh-workers] New release, v2?

[Ken Hornstein]

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 character conversion on message bodies (right now it aborts if it
  cannot convert characters to the target character set).

--Ken

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

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

[Michael Richardson]

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 that
> conversation in Steveston.  After a lot of good, local, beer.

So, each message has a (U?)UID?  Are the integers a subset of that?
If we never repack a folder, do we win?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



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

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

[Michael Richardson]

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 interoperability to me.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



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

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

[Michael Richardson]

+5 for a new release.

Ken Hornstein  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
> ...  all of those things which are not text.  That's really my point.

Yeah, but today, I can't grep those, and I wind up with false positives in
the base64.  (I claim that any <10 character sequence of ascii will always
appear somewhere in your base64 encoding, rather akin to the expansion of of
pi theories..)

So, it's a win to me.

BTW: when I grep my inbox, it's usually like:
 grep kenh ,?? ,???

because I deleted something yesterday I should have kept...

>> Yes, I have argued for and against this in the past, specifically
>> against the crypto-signature-breakage.  But really, what are the odds?
>> I would rather we decode all the MIME-encoding crap, and wherever
>> possible, translate text/* to utf-8 according to the charset parameter
>> indications in the mime part.  This means grep(1) continues to work.

> I think changing the message store to not be RFC-5322-format files is
> a) unfriendly (since that's been the assumption by all of the MH/nmh
> tools and their frontends since forever), and b) will have lots of
> unintended consequences.  From where I'm sitting it's a poor tradeoff
> just to make grep(1) work (and saying that grep(1) 'continues' to work

So, my preference is to have the original message in mailbox/1, and the
broken out stuff in mailbox/1.d/p1, etc.
It should be acceptable to have just the 1.d/p1.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



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

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

[Lyndon Nerenberg]

> 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.  We had that conversation in 
Steveston.  After a lot of good, local, beer.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Paul Vixie]

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 
dealing with either a local Maildir store, or a remote IMAP store.


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.


--
P Vixie

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

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

[Ken Hornstein]

>> ... 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 "grep -r" any more, then we should
>consider using Maildir format instead, for all of its advantages.
>(also i'd love to have good command line tools for managing maildirs,
>my wife's inbox has to be archived annually, which today i do via
>Thunderbird, which bites.)

>From what I've seen of Maildir, the big disadvantage is that there isn't
a good way to map MH message numbers (I'm assuming we still have 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?

>that guarantee is helping precisely nobody now. whether mail is or
>isn't text, or whether mail is or isn't a file, makes no difference
>to anyone if the only way to access it is via the MH commands and/or
>library.
>
>it might as well me in berkeley db at this stage. or maildir. or IMAP.

Well ... I see your point. Let's put a pin in it for now.

>so, while i appreciate the design level purity of just wanting a better
>API and let's not also fiddle with the on-disk format, i argue that
>you're preserving a benefit that no longer exists, because nothing
>other than your API is going to be able to access this data.
>
>you seem uncertain of this, however:
>
>> ... If we want to have the MH store consist of "email", then it can't
>> be text.  If we want to change the concept of what an MH store is,
>> then that would break a lot of third-party tools.
>
>the only third party tools that are still working are those which
>understand on-disk MIME (as received over SMTP). of those, the only
>ones that will break will be those which do not adopt your new API.
>
>how many tools is that? as far as i know: just the various MH-only
>graphical shells. i don't see those as a growth area in information
>technology. new graphical e-mail shells use IMAP, and the on-disk
>format used by MH is somewhat incompatible with IMAP, as those of us
>who spent 25 years keeping uw-imapd working for MH can explain in some
>detail. (sequences? sortm? folder --pack? PFA!)

I see where you going, there are a few (I am using one right now).

>> So, getting around to my larger point ... my goal here is to make it
>> so all of the MIME tools natively deal with MIME.  That means the
>> standard internal API is MIME-aware, things like %{body} in scan(1)
>> are MIME-aware (it could be the decoded version of the first text
>> part), and "pick" would know how to search inside a MIME-encoded text
>> part after converting everything to the native character set.  You
>> get the idea.  This requires a new API, parsing routines, etc etc ...
>> that's the part I'd like to work on.
>
>please don't let me dissuade you. nmh would be much cleaner with what
>you're proposing.
>
>> ... I don't recall a suggestion about helper tools a la find(1)
>> and/or xargs, but that could just be my memory going; I'm not sure
>> how that would work. ...
>
>imagining for a moment that something somebody wants to do can't be
>done with pick or rmm or refile even with a new, better, and universal
>MIME API, i think we need some outreach to UNIX command line tools,
>like an option to mhpath or mhstore that uses FUSE or even temporary
>files to offer a read only set of paths that "xargs egrep" would work
>for.
>
>> So, I guess the TL;DR answer is:
>>
>> - There were lots of ideas, but nothing concrete in terms of people
>> volunteering to write code. - I wasn't planning on doing anything
>> like that as part of my work.  My work wouldn't stop that and might
>> make it easier.
>
>thank you for explaining. if you hear about an MH-similar set of
>commands that works on Maildir stores, please point it my way. less and
>less of my archives are still in MH format.

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.

--Ken

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

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

[Jerrad Pierce]

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 add-hook to convert message
character sets however you choose.

2) Use ack , and add some filters for
RFC5322 files if there isn't one already.

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

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

[Ken Hornstein]

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

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

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

[Lyndon Nerenberg]

> 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.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

> On Mar 8, 2016, at 6:45 PM, Ken Hornstein  wrote:
> 
> 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.


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

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

[Lyndon Nerenberg]

> On Mar 8, 2016, at 6:45 PM, Ken Hornstein  wrote:
> 
> Sigh.  That doesn't help with image/jpeg, video/mpeg, application/pdf ...
> all of those things which are not text.

And unless you know something very slick, nobody has ever been able to grep 
those.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>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 text/html.  And converting to
UTF-8 is only a win _if_ your local character set is UTF-8.  We have
plenty of people for whom it is not.  And I honestly do not believe that
other MUAs convert to UTF-8 upon incorporation; from what I've seen, they
store them internally in the on-the-wire format.

>Yes, I have argued for and against this in the past, specifically
>against the crypto-signature-breakage.  But really, what are the odds?
>I would rather we decode all the MIME-encoding crap, and wherever
>possible, translate text/* to utf-8 according to the charset parameter
>indications in the mime part.  This means grep(1) continues to work.

I think changing the message store to not be RFC-5322-format files is a)
unfriendly (since that's been the assumption by all of the MH/nmh tools
and their frontends since forever), and b) will have lots of unintended
consequences.  From where I'm sitting it's a poor tradeoff just to make
grep(1) work (and saying that grep(1) 'continues' to work is ... not
accurate; I do not believe you can say that it works today).  And I can
say that for me, at least, the issue of crypto-signatures breaking is
not a theoretical concern; I have a need for S/MIME support, and that's
something I was planning on working on.

If the goal is to get grep(1) working, like I said, I'm fine with some
of the schemes proposed where there is an ancillary set of files that
are Unix text format.

--Ken

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

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

[Lyndon Nerenberg]

> On Mar 8, 2016, at 4:58 PM, Paul Vixie  wrote:
> 
> another solution proposed would write defanged/decoded content into files 
> that are stored alongside the original (as received in SMTP) content. some 
> new option to "folder" or "sortm" could generate these for older mhdirs, 
> whereas inc and rcvstore would just write both forms.

upas in plan9 solved that ages ago, and it's wonderful.  but it will *never* 
port to unix.  the best we can hope for is to turn the message file into the 
closest approximation of 'grep-able' text as we can.

--lyndon


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

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

[Lyndon Nerenberg]

> 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
> goal since the advent of MIME.  The model that "email is text" just
> isn't valid anymore.

No, that's not true. We could decode on inc(1) to UTF-8. Every other MUA 
(effectively) does that these days.

Yes, I have argued for and against this in the past, specifically against the 
crypto-signature-breakage.  But really, what are the odds?  I would rather we 
decode all the MIME-encoding crap, and wherever possible, translate text/* to 
utf-8 according to the charset parameter indications in the mime part.  This 
means grep(1) continues to work.

I will deal with grep facing binary message blobs.  I can strings  | grep 
foo to get around that.  Strings can't fix QP or base64.

--lyndon


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

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

[Ken Hornstein]

>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 find(1) and/or xargs(1) which could execute line-oriented tools 
>within the context of defanged and decoded content.
>
>another solution proposed would write defanged/decoded content into 
>files that are stored alongside the original (as received in SMTP) 
>content. some new option to "folder" or "sortm" could generate these for 
>older mhdirs, whereas inc and rcvstore would just write both forms.
>
>i think i favoured both approaches :-). was there an end to the argument?

Well ... no?  I mean, I didn't view it as an argument, myself.  But let
me be clear: nothing I am planning on doing involved changing the MH
store.  Nothing I am planning on doing would PRECLUDE that, it's just
that I didn't view it as part of my scope.

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 model that "email is text" just
isn't valid anymore.

Now, I know you and most everybody _know_ this, Paul ... but you haven't
really accepted what it means.  What it means to me is that you can't
really expect to use Unix text processing tools on RFC 5322-format files;
they don't meet the definition of "text" by any stretch of the imagination,
and different parts of the file can have different encoding schemes and
character sets (and parts aren't even guaranteed to contain human-readable
text).  So to me, trying to use Unix text processing tools on RFC-5322
format files in 2016 is simply a fool's errand.  Yeah, it may work fine ...
but you're guaranteed to have it not work at some point.  And we can't
really fix that without breaking a long-standing guarantee.  I know, I
know ... it was written on stone tablets, brought down from Mountain View
by Marshall Rose at the dawn of the First Age, that "MH files are text
files!".  Those tablets were pretty much smashed by Nathaniel Borenstein
in the Second Age.  (I think now we're in the Third Age).

Slightly more seriously ... email != text, that's pretty much a given
today.  If we want to have the MH store consist of "email", then it can't
be text.  If we want to change the concept of what an MH store is, then
that would break a lot of third-party tools.

So, getting around to my larger point ... my goal here is to make it
so all of the MIME tools natively deal with MIME.  That means the
standard internal API is MIME-aware, things like %{body} in scan(1) are
MIME-aware (it could be the decoded version of the first text part), and
"pick" would know how to search inside a MIME-encoded text part after
converting everything to the native character set.  You get the idea.
This requires a new API, parsing routines, etc etc ... that's the part
I'd like to work on.

Now people have suggested doing something like storing each MIME part in
it's own file, somewhere in a directory corresponding to each message.
I'm not exactly OPPOSED to that, per se ... I think it would be a lot of
work for relatively little gain, when (for instance) if I got the "new
MIME" code working, you could search through email fine with pick(1).  I
don't recall a suggestion about helper tools a la find(1) and/or xargs,
but that could just be my memory going; I'm not sure how that would
work.  I think we need to do the "new MIME" architecture to make things
better in the long run, so I view this as orthogonal to having a Unix
text processing-friendly store.  Since I personally view the text
processing-friendly store as redundant, it's not something I want to spend
my free time on.  I think the "new MIME" interface would make doing that
easier, as the code to extract those files would be simpler.

So, I guess the TL;DR answer is:

- There were lots of ideas, but nothing concrete in terms of people
  volunteering to write code.
- I wasn't planning on doing anything like that as part of my work.
  My work wouldn't stop that and might make it easier.

--Ken

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

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

[Paul Vixie]

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 proposed for this was to add some new helper tools similar 
to find(1) and/or xargs(1) which could execute line-oriented tools 
within the context of defanged and decoded content.


another solution proposed would write defanged/decoded content into 
files that are stored alongside the original (as received in SMTP) 
content. some new option to "folder" or "sortm" could generate these for 
older mhdirs, whereas inc and rcvstore would just write both forms.


i think i favoured both approaches :-). was there an end to the argument?

vixie

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

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

[Kevin Cosgrove]

On 8 March 2016 at 19:25, Ken Hornstein  wrote:
 
> What do people think of [Ken's] idea [to gather appropriate
> changes since the last release for a "1.7" release, followed
> by a MIME refactoring project]?  If you like this idea, is
> there anything 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
list for 1.7.

Thanks for the suggestion

--
Kevin



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

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

[Ken Hornstein]

I've been itching to do some MIME refactoring, and by "refactoring" I
mean completely doing a new message/MIME parser from the ground up,
based on flex/bison (at least parse headers using flex, maybe address
parsing via bison ... we'll see) and have a completely new internal API.
See "full MIME integration" email and "vague, 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 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 last release under the old MIME code".  Or if that
doesn't happen, we'll do another "last release".  Or we'll just keep
limping along with our crappy MIME code (I sure hope not).

The two things I think that should be worked on for a new release is
fixing the problem when during message display iconv() fails to convert
a character (just substitute a '?' is fine, I think) and bringing over
the XOAUTH2 code that Eric Gillespie did (I've been meaning to do it
because it is a lot of work that I'd hate to lose).  The first issue,
at least, should be easy.

What do people think of this idea?  If you like this idea, is there
anything else you want fixed before a new release?  I am thinking this
would have enough to be called 1.7.

--Ken

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

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

[Ken Hornstein]

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 POP support in inc from working properly.

If there are any questions, comments, or bug reports about this
release please direct them to nmh development list, nmh-workers@nongnu.org.

--Ken

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

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

[Peter Maydell]

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 need to do 1.3.x only
changes/tags it will be correct. (This seems less error prone than
branching again and hoping people remember to use the right branch.)

Sorry about that.
-- PMM


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

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

[Peter Maydell]

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 have now done this. You can find nmh-1.3-RC1 in the Savannah download
area: http://download.savannah.nongnu.org/releases/nmh/
Please try it out :-)

(Although I've uploaded a GPG signature for it, since it's done using
a key I created only this evening this may not be very useful...)

The branch name for 1.3 is nmh-1_3-branch, and the actual release is
tagged as nmh-1_3_RC1.

-- PMM


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

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

[Josh Bressers]

On 23 April 2008, Peter Maydell wrote:
> Joel Reicher wrote:
> >I think the first step should be to create a 1.3 branch in CVS and then
> >do the release work on that. There are some changes I've been keeping
> >to myself because they're a bit too radical to go into the next release,
> >I think, and if we branched I'd be able to check them into the trunk.
> 
> 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.  As soon as we have a release candidate, I'll push it into
Fedora and help get some testing (we're already running a CVS snapshot, so
something with a version number will be welcome)

Thanks.

-- 
JB


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

[Nmh-workers] working towards a new release

[Peter Maydell]

Joel Reicher wrote:
>I think the first step should be to create a 1.3 branch in CVS and then
>do the release work on that. There are some changes I've been keeping
>to myself because they're a bit too radical to go into the next release,
>I think, and if we branched I'd be able to check them into the trunk.

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.

-- PMM


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

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

[Igor Sobrado]

In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
> 
> OK, I've done some testing and the results are:
> 
> Successful compile:
>  Linux/x86 Debian stable (sarge)
>  Linux/x86 Fedora FC2
>  Solaris/SPARC
>  Linux/AMD64
>  NetBSD

Fine!!!

> (I didn't actually test the binaries, just that they could be built.)

I can test the binaries on NetBSD for some days if you agree...

> Failure:
>  OpenBSD/x86: I tried the sourceforge compile farm OpenBSD box, and it
>  built OK except that it screwed up on the makefile in the man/ directory
>  by trying to build manpages before man.sed (despite the dependency rule
>  directing otherwise). It's not a simple GNU-makeism (because NetBSD works
>  fine). So I propose to ignore this as a bug in that make unless somebody
>  submits a patch and rationale.

Agreed.  I would suggest asking for some help in a OpenBSD mailing list
or newsgroup.  Perhaps it is a bug in OpenBSD's make.

> I think the problems Igor was having are because the makefile rules for
> rerunning autoconf were kicking in (perhaps a clock skew problem between
> the machine he ran autoconf on and the one he ran make on?). Anyway, GNU
> autoconf requires GNU m4 (no avoiding that) but a proper release tarball
> including a configure script should have no problems.

Agreed.  I made the fixed tarball in a machine in Spain and transferred
it to a machine in the United States.  "make" should use GMT as universal
time reference but, even in this case, both machines can have a delay
longer than the time required to transfer/unpack/build the new binary.
The machine in Asturias has certainly a delay as it is not using NTP now.

> So I think we could go ahead and roll out a point release.

It's fine for me.  I will not complain, though.  ;-)

Cheers,
Igor.


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

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

[pmaydell]

[EMAIL PROTECTED] wrote:
>Jon Steinhart wrote:
>>> But the patched tarball has problems building on machines that do not
>>> have GNU m4 installed.
>
>>OK, so it sounds like I should wait on a release until this gets resolved.
>
>Feh. I'll have a look at this. (I've also realised that I have access
>to the sourceforge compile farm, so I'll have a go at testing that we
>can compile OK on some other platforms too).

OK, I've done some testing and the results are:

Successful compile:
 Linux/x86 Debian stable (sarge)
 Linux/x86 Fedora FC2
 Solaris/SPARC
 Linux/AMD64
 NetBSD

(I didn't actually test the binaries, just that they could be built.)

Failure:
 OpenBSD/x86: I tried the sourceforge compile farm OpenBSD box, and it
 built OK except that it screwed up on the makefile in the man/ directory
 by trying to build manpages before man.sed (despite the dependency rule
 directing otherwise). It's not a simple GNU-makeism (because NetBSD works
 fine). So I propose to ignore this as a bug in that make unless somebody
 submits a patch and rationale.

I think the problems Igor was having are because the makefile rules for
rerunning autoconf were kicking in (perhaps a clock skew problem between
the machine he ran autoconf on and the one he ran make on?). Anyway, GNU
autoconf requires GNU m4 (no avoiding that) but a proper release tarball
including a configure script should have no problems.

So I think we could go ahead and roll out a point release.

-- PMM


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

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

[Joel Reicher]

> In message <[EMAIL PROTECTED]>, Joel Reic
> her writes:
> > 
> > Unless I've misunderstood the other posts in the thread, it is not
> > nmh requiring GNU m4, but autoconf for when you regenerate the configure
> > script. It is, indeed, the case that GNU autoconf requires GNU m4.
> > 
> > This would be an "issue" for any package where you wanted to regenerate
> > the configure script, but doing so is not part of a standard build.
> 
> Indeed, it seems that GNU m4 is required to regenerate the configure
> script; that is not a problem at all as the nmh source code will include
> a ready to use autoconf script.  But once applied the patch that fixes
> the issues with nmh-1.2, non-GNU m4 flavours (at least the one in BSDs)
> complain about an unmatched bracket.

But the complaint only comes from autoconf tools, does it not? Only
autoconf tools are calling m4.

> Again, I believe that it is possible I did something wrong when regenerating
> the configure script.  Why is m4 required to run "./configure"?  It can be
> my fault, perhaps I did an incomplete configure script regeneration.

m4 is not required to run ./configure, but the GNU build system produces a
Makefile that will rebuild configure if things like configure.in change.
If the configure script is correct, there is no need to apply a patch
that changes the source for it, and I'm guessing this is what you're
doing.

> What I see is that, after regenerating the configure script and making
> a new "tarball" with an updated "configure", I need GNU m4 to run the
> configure script and compile nmh.

Is it really configure which is causing a call to m4? Can you post the
output? Your previous post had errors from autoreconf, which is to be
expected, and from make, which I've explained above.

Cheers,

- Joel


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