Re: new release?
David Levine wrote: >Jay wrote: [...] >> Both releases >> saw a spew of "Broken pipe" errors after test-mhparam, not sure if >> that's expected or not. > >That's not expected. The test immediately after that test-mhparam >is test/oauth/test-send. I tried running it under "sh -x" but >that 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?
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?
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?
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?
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?
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?
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?
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?
>> 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?
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?
Andy wrote: > sbr/fmt_rfc2047.c:391:12: error: use of undeclared identifier 'initialdstlen' > return initialdstlen - dstlen; >^ Thanks. That happens when building without iconv. I'll fix. David
Re: new release?
ken wrote: > >But here's the thing: when configure doesn't find lex or flex, it > >sets the value of the program to ":". wth? Wouldn't "false" be > >a far more effective substitute? If there's a way to tell configure > >to change that behavior, we should consider it. > > This behavior 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
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?
>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?
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?
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?
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?
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
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?
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?
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?
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?
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?
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?
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)
