Thus said David Levine on Sun, 07 Apr 2024 12:09:05 -0400:
> Just to note that we would need a test suite addition that shows what
> the change fixes.
Yes, that's on the todo list. I'm not very familiar with the test
harness but it should definitely be done if we're going to include it.
Thus said "Andy Bradford" on 04 Apr 2024 16:45:29 -0600:
> Any interest in renewing a discussion about this?
Also, I have found at least one contact mechanism that I'm pursuing
but I'm not very hopeful that it will result in any kind of
resolution---there is a &
Thus said "Andy Bradford" on 04 Apr 2024 16:45:29 -0600:
> A day later I also provided a patch against master:
>
> https://lists.nongnu.org/archive/html/nmh-workers/2022-11/msg7.html
And that link is actually not the latest---I found some bugs along the
way
Hello,
Back in August of 2022, I identified a "problem" with inc not handling
long lines (to the tune of megabytes of characters all on a single line
which is clearly contrary to all standards and RFCs):
https://lists.nongnu.org/archive/html/nmh-workers/2019-09/msg7.html
I have tried
Thus said "Andy Bradford" on 20 Jan 2024 08:48:36 -0700:
> I think it would be nice if it's aligned properly like other nmh
> commands try to accomplish.
Time to backpedal my comment a bit as it's not about proper alignment
per se; I was distracted by the folders outp
Thus said Ralph Corderoy on Sat, 20 Jan 2024 16:00:46 +:
> folders +OpenSourceML | awk '{l=length($1)}l>m{m=l;p=$0}END{print p}'
I see, I have one folder name that is fairly long and as a result, this
double-space shifted things just enough to make it wider than 80:
Thus said Ken Hornstein on Fri, 19 Jan 2024 22:33:54 -0500:
> Yeah, that is exactly why it happens. Honestly it doesn't personally
> bother me, but what do others think?
While I've never noticed it in the context of "folder -pack" (because I
don't use it) I think it would be nice if it's
Thus said Ken Hornstein on Fri, 19 Jan 2024 16:45:18 -0500:
> Like many threads involving ancient greybeards, it kind of devolved
> into a discussion about the "true" vi and how vim wasn't vi enough
It wouldn't be a good devolution if it didn't involve vi vs emacs or
another editor!
>
Thus said Robert Elz on Fri, 19 Jan 2024 15:10:26 +0700:
> Yes, I have had the "editor" line in my profile since MH days, (I have
> been a user since almost forever) so what nmh did as default I never
> knew, which is why I avoided saying that...
>From looking at the past sources it used to
Thus said "Andy Bradford" on 18 Jan 2024 23:05:09 -0700:
> Thus said Robert Elz on Fri, 19 Jan 2024 12:30:08 +0700:
>
> > That's "prompter" - has always been mh's default.
Ahh, I didn't read the fine print... you said "mh's default", but I
misu
Thus said Robert Elz on Fri, 19 Jan 2024 12:30:08 +0700:
> That's "prompter" - has always been mh's default.
Not always:
https://git.savannah.nongnu.org/cgit/nmh.git/log/sbr/geteditor.c?h=1.8-release
Looks like it was changed in 1.8 (if I read that correctly).
I wasn't aware of "prompter"
Thus said Robert Elz on Fri, 19 Jan 2024 12:30:08 +0700:
> That's "prompter" - has always been mh's default.
Well, I'm confused. If it was always the default, why am I only now
seeing it after upgrading to 1.8? I haven't changed anything in my
.mh_profile in years:
$ ls -l
Hello,
After upgrading to 1.8 running commands like comp, repl, etc, no longer
bring up my editor (vi) with the data already filled in. For example, to
type this email I typed comp, and then it entered some kind of
interactive dialog asking me for the To header, the Subject, and
Thus said Ralph Corderoy on Thu, 18 Jan 2024 15:22:28 +:
> The suggestion was to duplicate the setting by adding "send:
> -draftfolder drafts". I think this breaks mhmail(1).
Except, according to the man page for mhmail:
PROFILE COMPONENTS
mhmail does not consult the user's
Thus said aalin...@riseup.net on Mon, 15 Jan 2024 08:57:51 -0500:
> Now when I look at it instead of base64 it says 8bit. Am I confused or
> is that what mhfixmsg did, changed the message from base64 to 8bit?
According to the manpage for mhfixmsg, it's supposed to make a backup
copy of the
Thus said Ken Hornstein on Sun, 31 Dec 2023 15:00:38 -0500:
> >Can we just use "localname" from mts.conf?
>
> We COULD, it would just be wrong for some people.
I definitely don't want nmh generating Message-ID unless I ask it to do
so as my MTA is already correctly configured.
The MTA that
Thus said Ken Hornstein on Sun, 31 Dec 2023 11:56:38 -0500:
> I am personally skeptical that people actually configure this.
I also find it hard to beleive that someone wants the MUA to have a
specific Message-ID for their email, but there is at least one software
that I'm aware of that
Thus said David Levine on Sun, 17 Sep 2023 21:51:04 -0400:
> How about this?
>
> mhbuild now folds header field bodies to avoid lines with more
> then 78 bytes.
>
> This is required by RFC 5322 2.1.1. Line Length Limits.
>
Minor correction; replace "then" with "than".
Also, RFC
Thus said Ken Hornstein on Wed, 22 Feb 2023 20:59:31 -0500:
> I had an inkling popular MTAs would DTRT.
Well, qmail's hardly "popular" these days, but Professor Bernstein had a
penchant to make string handling robust to avoid exploits, so he got NUL
handling as a benefit.
I run minority MTA
Thus said Ken Hornstein on Tue, 21 Feb 2023 21:29:16 -0500:
> So you're told "I am sending this many bytes exactly", and you don't
> have to deal with "lines", so the implementations I've seen tend to
> call read() (or the equivalent) until they get the correct number of
> bytes, and
Thus said Ken Hornstein on Tue, 21 Feb 2023 07:17:19 -0500:
> I'm sitting down to write or modify nmh code. Right now we have a lot
> of code that assumes NUL-terminated C strings are safe to represent
> email everywhere. My question is: is that a valid assumption?
I don't think nmh should
Thus said Ken Hornstein on Mon, 20 Feb 2023 21:11:48 -0500:
> Facinating! I am curious: who/what sent this to you! Do you remember
> the MIME type?
0.11 % (percent) of my messages have Content-Transfer-Encoding of binary
at the beginning of the line somewhere in the message.
Here are the
Thus said Ralph Corderoy on Mon, 02 Jan 2023 13:21:16 +:
> > > Has anyone had a chance to review my proposed changes to inc to be
> > > able to handle long lines from POP sources?
>
> Is the latest in Git?
I doubt it. I sent an updated patch but never heard about it making into
Git. It
Thus said David Levine on Sat, 31 Dec 2022 22:00:04 +0100:
> Do you or anyone else have anything else you'd like to put in before
> starting the 1.8 release cycle?
Has anyone had a chance to review my proposed changes to inc to be able
to handle long lines from POP sources? While it's not
Thus said "Andy Bradford" on 22 Nov 2022 09:38:08 -0700:
> I'm running a similar patch on my nmh 1.7.1 installation and will
> report any problems that I find in "production".
So far I haven't found any problems and I've been running it daily. I
did
Thus said David Levine on Sun, 27 Nov 2022 19:14:09 -0800:
> Would it be much trouble for you to add tests for the test suite?
I can look into it when I get some spare time. I'm not yet very familiar
with the test code, but I did take a brief look and noticed that there
is a fake pop server
Thus said Ken Hornstein on Mon, 21 Nov 2022 21:41:34 -0500:
> netsec_read() is supposed to RETURN the number of bytes read, just
> like read() does (that's why it's return value is prototyped ssize_t).
> But it just returns OK on success.
Attached is the previous patch remade against master.
Thus said Ken Hornstein on Mon, 21 Nov 2022 21:41:34 -0500:
> netsec_read() is supposed to RETURN the number of bytes read, just
> like read() does (that's why it's return value is prototyped ssize_t).
Aha, that does make more sense. I thought it was odd that it just
returned OK, but
Thus said Ken Hornstein on Wed, 16 Nov 2022 09:19:11 -0500:
> I think the correct solution is when nmh is doing a RETR inside of
> POP we should use netsec_read() and perform the necessary CR-LF
> translations on the returned buffer. The only complicated thing I see
> is dealing with
Thus said Ken Hornstein on Wed, 16 Nov 2022 09:19:11 -0500:
> The only complicated thing I see is dealing with the case where a CR
> is at the end of one buffer and the LF is at the start of the next
> buffer; I think that is straightforward.
Precisely. Though in my current patch
Thus said Ken Hornstein on Tue, 15 Nov 2022 15:44:59 -0500:
> My reading of the RFC is that the 512 limit is _just_ for responses to
> commands. For the response to something like RETR it punts it off to
> RFC 822, which it seems like people are ignoring anyway.
This is also how I interpreted
Thus said Ralph Corderoy on Tue, 15 Nov 2022 17:27:47 +:
> It's one peer of one user. No one else suffers. (Sorry, Andy.)
> Seems a shame to complicate the code.
Well, actually, it's a system that is used to notify more than just me,
and I cannot say that I'm the only one impacted,
Thus said "Andy Bradford" on 09 Nov 2022 21:18:55 -0700:
> I've been running it for a couple of days and it seems to work as I
> haven't discovered any corrupted message or lost anything; it even
> preserves the huge lines that shouldn't be present.
Well, I've run
Thus said Ken Hornstein on Mon, 14 Nov 2022 21:27:23 -0500:
> Officially such a message violates RFC 5322 (line length limit of 998
> plus CR LF), which means it violates the POP3 RFC as well. But I
> suspect we just have to deal. Sigh.
Absolutely, it's one of the most blatant
Thus said Ralph Corderoy on Sun, 13 Nov 2022 21:29:23 +:
> Is this only seen with inc(1) reading from a particular source?
I believe the only problem that I found was inc and reading from a POP
source; sorry for not being more clear. Specifically in popsbr.c and
pop_getline(), it
Hello,
While compiling on OpenBSD I encountered some failures due the placement
of this line:
#include "sbr/globals.h"
For some reason it's nested in an #ifdef block, and I think it should
actually be outside of the block. For example:
Thus said David Levine on Thu, 10 Nov 2022 05:51:12 -0800:
> Andy, are you able to create patches against HEAD?
Attached is a new patch that applies cleanly against master (17734c9c).
I had trouble compiling on OpenBSD, but I eventually got it working
after a bit of hacking, however, I
Thus said Michael Richardson on Thu, 10 Nov 2022 13:08:02 +:
> Not sure where TRUE/FALSE is supposed to be declared, but that didn't
> compile.
Not sure where they went... they used to be defined in mh.h:
#ifndef FALSE
#define FALSE false
#endif
#ifndef TRUE
#define TRUE true
#endif
Thus said David Levine on Thu, 10 Nov 2022 05:51:12 -0800:
> Andy, are you able to create patches against HEAD?
Yes, I'll see about getting it applied to HEAD.
Thanks,
Andy
Hello again,
It's been a few years since I first reported a problem with inc's
handling of long lines (e.g. those that are clearly longer than RFC
mandated lengths). Oddly enough, I have only ever seen it coming from
one particular sender (and the problem still persists to
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.
Thus said Paul Fox on Sat, 18 Dec 2021 16:20:05 -0500:
> And others that Doug didn't introduce, but which are somewhat long in
> the tooth:
> xv
> soffice
I still prefer to use xv for image display. Also, while Star Office is
long gone as a name, soffice still works as a compatible
Thus said David Levine on Tue, 17 Aug 2021 18:51:38 -0700:
> Does your profile have an -mts sendmail/pipe switch for send? send
> -help would show it.
I do have this:
postproc: /usr/local/libexec/nmh/spost
But nothing for send.
Also, I notice in analyzing the trace that the process
Thus said Bakul Shah on Tue, 17 Aug 2021 18:38:21 -0700:
> Try ktrace -di comp
Wow, how did I miss that in the man page! Now after adding -i I see that
it does in fact read mts.conf.
Now back to my original question.
How is it possible that when mts.conf is configured as:
mts: smtp
servers:
Hello,
While participating in the recent thread, "Delivering mail through nmh
via SMTP...", I decided to check my mts.conf and discovered that mts
wasn't actually configured as "sendmail/pipe" as I had thought (probably
got wiped away when I upgraded); so I started wondering why the
Thus said Ken Hornstein on Tue, 17 Aug 2021 21:01:18 -0400:
> 587 is the port that is supposed to be used by MUAs to submit mail.
> nmh is a MUA; it seems perfectly logical to me that the default that
> is used by nmh is the submission port.
Yeah, I can see your point though I still think it
Thus said "Andy Bradford" on 17 Aug 2021 18:50:01 -0600:
> Thus said David Levine on Tue, 17 Aug 2021 05:28:29 -0700:
>
> > Starting with nmh 1.7, nmh defaults to port 587 instead of 25 for
> > SMTP submission.
>
> Personally I think this was a mistake. SMT
Thus said David Levine on Tue, 17 Aug 2021 05:28:29 -0700:
> Starting with nmh 1.7, nmh defaults to port 587 instead of 25 for SMTP
> submission.
Personally I think this was a mistake. SMTP is port 25, SUBMISSION is
port 587. If something says SMTP, what comes to mind is port 25, not
587.
Ken asked:
> What version of nmh were you running before?
Oddly enough, it would seem that I was also running nmh 1.7.1 prior to
upgrading the OS.
I see that I also had a local modification that maybe I forgot to
communicate to anyone...
Index: sbr/ruserpass.c
--- sbr/ruserpass.c.orig
[Apologies that this will break threading, but I cannot yet receive
email]
Ken asked:
> Is your password in a .netrc file? Something different? Do you have a
> "credentials" entry in your .mh_profile?
I don't have a .netrc file at all:
$ ls -ld ~/.netrc
ls: /home/amb/.netrc: No such file
Hello,
I recently upgraded to OpenBSD 6.9 and consequently also got nmh 1.7.1
and now find that inc no longer sends the password to my POP3 server:
$ inc +MyIncTmp -snoop -nochangecur -user username -host localhost
Trying to connect to "localhost" ...
Connecting to 127.0.0.1:110...
<= +OK
Hello,
I recently upgraded to OpenBSD 6.9 and consequently also got nmh 1.7.1
and now find that inc no longer sends the password to my POP3 server:
$ inc +MyIncTmp -snoop -nochangecur -user username -host localhost
Trying to connect to "localhost" ...
Connecting to 127.0.0.1:110...
<= +OK
Thus said Michael Richardson on Sun, 07 Mar 2021 14:04:18 -0500:
> But that doesn't work anymore unless you control the DNS for all zones
> in question, and can set up SPF correctly. (Mostly, that actually does
> apply to me)
As a counterpoint, I have never setup SPF and generally have
Thus said Ken Hornstein on Mon, 31 Aug 2020 13:25:17 -0400:
> Right, I mean ... that's probably sufficient. But there aren't any
> universal solutions. If you want to wrap every nmh command in a global
> lock, that's also an option.
The only command I run the risk of running concurrently is
Thus said aalin...@riseup.net on Fri, 10 Jan 2020 16:15:37 -0500:
> This gets me what I want and if that's the way it's done, so be it. My
> only complaint is that I don't see the message I'm forwarding.
You can always re-edit after you have run the mime command with "edit"
if I'm not
Thus said "Martin McCormick" on Mon, 06 Jan 2020 07:03:14 -0600:
> https://www.radioid.net/verify/token=SHTUI469E1GVO35SDTGK180BAHKLOP9FPF
> R9GWQD
This URL looks like it has an embedded newline in it (maybe the
result of quoted-printable content being poorly handled by the senders
Thus said Ralph Corderoy on Sat, 23 Nov 2019 12:03:42 +:
> Andy is correct. Mailman has a `nodupes' flag for every subscription
> and it's set for Andy's subscription.
Not any longer. :-)
I didn't realize I had control over this.
Andy
--
TAI64 timestamp: 40005dd9a302
Thus said Steffen Nurpmeso on Thu, 21 Nov 2019 23:14:29 +0100:
> I have heared someone revived qmail and wants to include some patches
> for builtin TLS etc. That sounded very much interesting, especially if
> its mailing-list manager would be maintained again!
There has been some momentum
Thus said Greg Minshall on Wed, 20 Nov 2019 10:41:34 +0530:
> then, i'd like to use something like fmttest(1) to print out all the
> "Received:" lines in an e-mail message. ideally, each "Received:" line
> would come out on a separate line; less ideally, but i'm sure very
> practical, a
Thus said Ken Hornstein on Thu, 26 Sep 2019 12:36:41 -0400:
> You can read the details in the message for the complete technical
> reasons why this is happening; the other option is to do what is
> called "Munge From" and I personally think this is 100x worse (I am on
> a Yahoo mailing
Thus said Ken Hornstein on Tue, 10 Sep 2019 09:15:00 -0400:
> So how big WAS this message, actually? I'm trying to understand the
> scope of the problem.
The entire size of the message on disk (including additional trace
headers added by my MTA) is 11,374,046 while the size of the
Thus said Ken Hornstein on Mon, 09 Sep 2019 17:04:05 -0400:
> In a perfect world I think we SHOULD parse those messages (up to the
> limits of virtual memory), but right now we don't.
That's actually how I figured this problem out. I found that my POP3
daemon kept crashing and when I
Hello,
This is the first time I've ever seen such an error from inc. In looking
at the message that is causing the problem, apparently it's a MIME
message that has a base64 encoded MIME body that is all on one line that
even sed has a hard time parsing:
$ time (cat bigmessage | sed -ne
Thus said "Valdis Kl?tnieks" on Sat, 08 Jun 2019 21:26:46 -0400:
> In a world of Microsoft Office attachments, is having -search go
> through the body by default as well still a good idea? Maybe having a
> separate -searchbody would be better?
Hard to say what it *should* be. In my
Thus said aalin...@riseup.net on Sat, 25 May 2019 10:37:17 -0400:
> Scenario: you receive an email from Geico informing you your car
> insurance payment is due in 4 weeks. In mutt or Apple Mail you can
> flag that message so you're reminded of it each time you log in.
I'm not sure what
Thus said Ken Hornstein on Tue, 30 Apr 2019 13:23:37 -0400:
> Thank you for that pointer; sadly, I went through the whole process of
> getting it started, it DID pop up the right window to prompt for MFA,
> but the domain I use is configured to require administrator approval
> to use another
Thus said berg...@merctech.com on Thu, 25 Apr 2019 20:08:02 -0400:
> $WORK migrated my email to Office365 this week.
I've had a similar experience and was able to reintegrate nmh by using
Davmail to provide a POP interface to Office365---if they don't provide
one for you already. Use search
Thus said Ken Hornstein on Tue, 23 Apr 2019 19:35:11 -0400:
> >setlock /tmp/mit.lock inc +MyIncTmp ...
>
> Well, my reading of the setlock man page (assuming this is the FreeBSD
> one) is that it is not depending on a _descriptor_ to be passed down
> (I don't even know how that would work),
Thus said Paul Vixie on Tue, 23 Apr 2019 05:59:05 -0700:
> to that end, i propose that we treat any open descriptor N>2 at the
> time of an exec() to be a bug, which is to be fixed by setting
> O_CLOEXEC at time of creation.
What impact will such a decision have on tools like setlock
Thus said Ralph Corderoy on Thu, 08 Nov 2018 10:36:12 +:
> A workaround is to subscribe the list to a public archiver so Google
> can see everything from the switch-over date onwards, as long as the
> list-info page makes this clear as otherwise new posters still think
> it's
Thus said Ken Hornstein on Wed, 07 Nov 2018 15:52:32 -0500:
> >I considered poking around
> >https://www.redhat.com/mailman/listinfo/exmh-users for signs of life,
> >but those archives are subscriber only.
>
> You know, this has always driven me nuts. Why is it set like this? Can
> that be
Thus said Ken Hornstein on Thu, 24 May 2018 19:28:25 -0400:
> So, I don't think this is necessarily a nmh problem, like I said. From
> a practical standpoint, you're probably one of the few people who
> actually USES the text/plain content instead of the text/html content.
Count me as
Thus said Ralph Corderoy on Tue, 20 Mar 2018 12:56:09 -:
> For evermore, programs that only offer one means of invoking an editor
> have had to checking first $VISUAL, falling back to $EDITOR. :-)
You mean like the following chunk of code: :-)
Thus said Ken Hornstein on Sun, 18 Mar 2018 19:49:03 -0400:
> If you're a long-time MH user, I admit that I am surprised you never
> set anything in your profile; it seems like the default was prompter
> for a long time (although, like I said earlier, that depends on your
> specific site
Thus said Ken Hornstein on Sat, 17 Mar 2018 20:25:05 -0400:
> Yeah, I tried it quickly and it seems simple enough. And people who
> have editor in their profile or use EDITOR/VISUAL won't notice a
> change.
Under what conditions will this change? I have neither EDITOR/VISUAL nor
profile
Thus said Paul Vixie on Sat, 17 Mar 2018 08:55:41 -0700:
> i have not run comp without first setting VISUAL for at least two
> decades, but when i used to do this, it would print a message like
> "type your message below, and then hit control-D" and then read from
> standard input.
Thus said Paul Fox on Wed, 14 Mar 2018 14:59:57 -0400:
> The big exception that I remember was his implementation of infinite
> undo using '.', which broke a corner case of the redo command, but is
> so easy to use.
Oddly enough, that is one exception that I praise and the one difference
Thus said Paul Fox on Tue, 13 Mar 2018 09:50:24 -0400:
> well, part of me wants to take offense at that, since it's not like
> vim is completely compatible with the "real" vi. nvi is much closer,
> in that regard, and should really be the rewrite that gets to use the
> /usr/bin/vi name.
As
Thus said Ken Hornstein on Fri, 16 Feb 2018 10:44:06 -0500:
> Right, I was wondering if Dovecot was cool with other Maildir clients
> modifying its store; the answer is "yes". I was also wondering if we
> do a "refile +/path/to/dovecot/folder 42", should we put the message
> in "new" or
Thus said Ken Hornstein on Thu, 15 Feb 2018 22:35:04 -0500:
> Well, you can read the many messages on this topic from someone who
> will remain nameless, but who's name rhymes with "Maul Pixie".
In the scenario that he who shall remain nameless presented, I can
definitely see the need
Thus said Ken Hornstein on Wed, 14 Feb 2018 14:22:56 -0500:
> If we scan a Maildir folder, should we be in charge of moving stuff
> from new into cur? Maybe? Maybe not? You tell me!
Let's look at what qmail-pop3d does when a client ``scans'' the list of
messages:
$ find new -type f| wc -l
Thus said Ken Hornstein on Tue, 13 Feb 2018 10:09:07 -0500:
> But Bernstein ignored MH because he was not trying to invent a MAILBOX
> format, he was trying to invent a mailDROP ... really, I went back and
> looked. Yes, I know people now use Maildir as a mailbox, and I think
> that's weird,
Thus said Ken Hornstein on Tue, 13 Feb 2018 11:30:38 -0500:
> >We've talked a lot about the subtle change to move MH to Maildir, and
> >we never quite work out all the wrinkles, and I'd sure like to that.
>
> I hear people say this, and I have to wonder ... what's the goal here?
Again, as one
Thus said "Todd C. Miller" on Wed, 31 Jan 2018 14:11:09 -0700:
> The OpenBSD C compiler does not look in /usr/local/include or
> /usr/local/lib by default but the nmh port's Makefile does.
I should have cracked open the Makefile and I would have seen the
obvious CONFIGURE_ENV
Thus said Ralph Corderoy on Wed, 31 Jan 2018 12:40:28 +:
> > This begs a larger question ... should we just specify iconv as a
> > requirement for the next release?
>
> You're thinking those without it, e.g. Andy, could easily get iconv
> with a package install?
You're right, I did not
Thus said Ralph Corderoy on Tue, 30 Jan 2018 17:01:58 +:
> That's this early part. Does it attempt the printf? If so,
> $ICONV_ENABLED isn't 0, and iconv(1) quite reasonably disliked
> converting from `?UTF-8'.
No, it does not attempt the printf because ICONV_ENABLED=0
Thus said "Andy Bradford" on 29 Jan 2018 21:16:14 -0700:
> I'll try to figure out why it's failing and report back, ...
So, here's where I'm at; I see the script makes it to here:
if [ $iconv_elides_question_marks -eq 1 ]; then
check "$expected" "$actual&q
Thus said Ken Hornstein on Mon, 29 Jan 2018 21:12:43 -0500:
> So I went and looked again at people who tried out 1.7.1-RC2; it seems
> there were some benign warnings (which we didn't clean up, AFAIK) and
> Andy Bradford reported a failure on the test suite that we never
&
Thus said David Levine on Tue, 23 Jan 2018 07:45:29 -0500:
> I usually cheat and just run the test directly:
>
> test/ali/test-ali
Ok, I'll give that a try. Interestingly:
$ make check TESTS=test/mhshow/test-charset
make test/fakehttp test/fakepop test/fakesmtp test/getcanon
Thus said Ralph Corderoy on Tue, 23 Jan 2018 11:12:17 +:
> The vital lines of interest are in the lead up to that. Should be
> something starting with a context diff.
There was no lead up to it, that's why I didn't include it---and also
the reason why I was trying out that
Thus said Ralph Corderoy on Tue, 23 Jan 2018 11:03:46 +:
> What's the `cc' line from make's output that compile's post.c? And
> what version of a C compiler is it? Can't get the warning here with
> gcc 7.2.1 20171224 and `-std=c99 -pedantic -pedantic-errors -Wall
> -Wextra
Thus said Ken Hornstein on Mon, 22 Jan 2018 14:20:32 -0500:
> This is a patch release for 1.7, and fixes some output problems with
> the format engine, issues with rcvdist(1) passing switches to post(8),
> and a number of problems discovered with the test suite.
Speaking of the test suite, I
Thus said Ken Hornstein on Mon, 22 Jan 2018 14:20:32 -0500:
> If you encounter any problems or issues with this release candidate,
> please don't hesitate to contact nmh-workers@nongnu.org.
This may be a known issue (or not an issue at all):
uip/post.c: In function 'putadr':
uip/post.c:1239:
Thus said David Levine on Mon, 22 Jan 2018 20:43:50 -0500:
> > The comment in mhfixmsg which I quoted at the beginning of
> > this thread seems to be saying that sometimes message components
> > described as text/* are really binary files, and that the
> > 998-character
Thus said Ken Hornstein on Sat, 20 Jan 2018 13:59:20 -0500:
> Forgive me if this is a dumb question, but ... why do you care what
> the timezone is in your Date: headers?
Personally, I've always found the timezone in the Date header quite
useful to convey a sense of time. If all
Thus said Ken Hornstein on Tue, 05 Dec 2017 10:43:36 -0500:
> But it sounds like with the way things are currently set
> up, for 1.7 the configuration files will actually end up in
> /usr/local/lib/nmh/nmh, which I think most of us would agree kind of
> sucks.
You're
Thus said Ken Hornstein on Tue, 05 Dec 2017 09:15:54 -0500:
> If it's the latter, then that suggests to me that we should simply put
> nmh config files in $(sysconfdir). If packages are installing files in
> $(sysconfdir)/foo, then I'd like to see how they deal with packaging
> systems to avoid
Thus said David Levine on Sat, 02 Dec 2017 15:47:15 -0500:
> Great, thank you! I assume that includes, or would include, a clean
> "make check".
OpenBSD 6.2 has the same failure as was in OpenBSD 6.1 but that's to be
expected until OpenBSD releases include Aaron Bentley's normalization of
Thus said David Levine on Sat, 02 Dec 2017 09:53:25 -0500:
> I updated the version of OpenBSD in nmh's MACHINES file to 6.1.
Just for the sake of completeness, I downloaded nmh-1.7 to an OpenBSD
6.2 (i386) system and it compiled cleanly there as well.
Andy
--
TAI64 timestamp:
Thus said David Levine on Mon, 27 Nov 2017 19:59:52 -0500:
> Though looking at it now, we should probably move FreeBSD 9, OpenBSD,
> and Solaris 11 to the was-known-in-the-distant-past-to-compile
> category.
I've heard a rumor that BSD is dead, or at least in it's last throes...
1 - 100 of 134 matches
Mail list logo
