From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111633 invoked by alias); 27 Mar 2017 20:55:41 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 111623 invoked by uid 89); 27 Mar 2017 20:55:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=puzzled, Hx-languages-length:2470, interest X-HELO: limerock01.mail.cornell.edu Received: from limerock01.mail.cornell.edu (HELO limerock01.mail.cornell.edu) (128.84.13.241) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Mar 2017 20:55:38 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id v2RKtbON026416 for ; Mon, 27 Mar 2017 16:55:37 -0400 Received: from [192.168.1.4] (mta-68-175-148-36.twcny.rr.com [68.175.148.36] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id v2RKtaYB014568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 27 Mar 2017 16:55:37 -0400 Subject: Re: [HHITP] mailutils 3.2 To: cygwin-apps@cygwin.com References: <55411890-b110-bc3d-45b8-0e652b846131@cornell.edu> <742a380c-dbba-470c-ee18-a31b34bcc5c3@cygwin.com> From: Ken Brown Message-ID: Date: Mon, 27 Mar 2017 20:55:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <742a380c-dbba-470c-ee18-a31b34bcc5c3@cygwin.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00035.txt.bz2 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