From: Ken Brown <kbrown@cornell.edu>
To: cygwin-apps@cygwin.com
Subject: Re: [HHITP] mailutils 3.2
Date: Mon, 27 Mar 2017 20:55:00 -0000 [thread overview]
Message-ID: <f9e8820e-ae0e-a515-e4ad-822d19dc6564@cornell.edu> (raw)
In-Reply-To: <742a380c-dbba-470c-ee18-a31b34bcc5c3@cygwin.com>
On 3/27/2017 3:32 PM, Yaakov Selkowitz wrote:
> On 2017-03-24 14:54, Ken Brown wrote:
>> This is a half-hearted ITP for GNU mailutils
>> (https://www.gnu.org/software/mailutils/mailutils.html). I'd like some
>> feedback before I proceed.
>>
>> My only interest in mailutils is that it provides a utility
>> movemail.exe, which is used by emacs.[*] But I looked into providing a
>> complete build of mailutils and various subpackages along the lines of
>> Debian[**], and it turned out to be straightforward. My cygport file
>> and patches are attached. I ran the testsuite, and there were 42
>> failures and 3 skips out of 978 tests. The failures ought to be looked
>> at, but I don't this is too bad.
>
> FWIW, even on Debian, the tests succeed until comsatd tests 2-7 all
> fail, at which point make check terminates. So if those are your first
> failures, it may just be the testsuite.
No, the comsatd tests all pass. The failures I'm seeing are in imap4d,
maidag, and sieve. And for some reason that I haven't figured out, the
pop3d tests aren't run. The tests use dejagnu, and they report that
runtest can't be found. But there are other tests that use dejagnu and
do find runtest, so I'm puzzled.
> Not a full review, but noticed a few things:
>
>> libmailutils5_CONTENTS="
>> --exclude=usr/bin/
>> usr/bin/cyg*-5.dll
>> usr/lib/mailutils/*.dll"
>
> What happens when a future version ships libmailutils6? As is, the
> modules will collide. Are the modules used by the libraries directly,
> or are they for the daemons?
The modules provide extensions to the Sieve mail-filtering language and
are used only by the latter. They are apparently loaded on demand by
"require" statements in Sieve scripts. Should I put them in a separate
subpackage (say, libmailutils-sieve-extensions)?
>> mailutils_mh_CONTENTS="
>> usr/bin/mu-mh
>> usr/share/mailutils/mh"
>
> A /usr/bin/mu-mh directory would violate the FHS (4.4.2: "There must be
> no subdirectories in /usr/bin."). Depending on how these are used, one
> of /usr/{lib,libexec}/mu-mh would make more sense.
According to the Mailutils manual, "The primary aim of this
implementation is to provide an interface between Mailutils and Emacs
using mh-e module." I've looked at Emacs's mh-e.el, and it expects to
find the programs in /usr/local/bin/mu-mh or /usr/bin/mu-mh. So I think
we're stuck with this. FWIW, Debian packages mailutils-mh the same way.
Thanks for looking at this.
Ken
next prev parent reply other threads:[~2017-03-27 20:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 19:55 Ken Brown
2017-03-27 19:32 ` Yaakov Selkowitz
2017-03-27 20:55 ` Ken Brown [this message]
2017-03-31 14:34 ` Ken Brown
2017-03-28 12:40 ` Andrew Schulman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f9e8820e-ae0e-a515-e4ad-822d19dc6564@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).