From owner-freebsd-ports@FreeBSD.ORG Wed Dec 24 15:09:33 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4A26ACA; Wed, 24 Dec 2014 15:09:33 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7FF9264179; Wed, 24 Dec 2014 15:09:33 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sBOFAK3p045210; Wed, 24 Dec 2014 07:10:22 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Dmitry Morozovsky In-Reply-To: References: <20141222094630.GF52267@xtaz.uk> <1419342257.1161578.206107753.2999EC08@webmail.messagingengine.com>, <20141223135111.GA45509@xtaz.uk> , From: "Chris H" Subject: Re: gnupg & pinentry Date: Wed, 24 Dec 2014 07:10:23 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <905f9b0e84ac19dff7be71a9f040fc40@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: freebsd-ports@freebsd.org, Matt Smith X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 15:09:33 -0000 On Wed, 24 Dec 2014 12:23:38 +0300 (MSK) Dmitry Morozovsky wrote > On Tue, 23 Dec 2014, Chris H wrote: > > > > >It looks as though it would be feasible to write an extremely > > > >lightweight pinentry-compatible program to depend on so we can kill the > > > >dependency bloat and have a simple shell-based password entry option. > > > > > > > >Anyone up for a weekend challenge? :-) > > > > > > There has been another thread on this mailing list discussing making the > > > port honour the WITHOUT_X11 and OPTIONS_UNSET+=X11 options from > > > make.conf which would make it only depend on security/pinentry-curses > > > instead of security/pinentry. This seems like a good solution to me. It > > > would mean if one of those options is set it will only drag in a single > > > dependancy rather than all the X11 libraries and GTK. > > A quick look @ the security/pinentry Makefile, indicates that the > > request for this type of modification is trivial. It simply requires > > reversing the (PORT_)OPTIONS logic -- this port could completed in > > under 5 minutes. So unless instructed otherwise, I'll go ahead with > > this. > > One last question; pinentry-console, or pinentry-nox? > > already defined: pinentry-curses ;) Right you are, Dmitry. :) > > (see side thread) > > Patch I snet previoursy is syntax incorrect, the following seems to be more > useful: > > Index: Makefile > =================================================================== > --- Makefile (revision 375271) > +++ Makefile (working copy) > @@ -22,7 +22,11 @@ > libksba.so:${PORTSDIR}/security/libksba \ > libnpth.so:${PORTSDIR}/devel/npth > BUILD_DEPENDS= libgpg-error>=1.11:${PORTSDIR}/security/libgpg-error > +.if defined(WITHOUT_X11) || !empty(OPTIONS_UNSET:MX11) > +RUN_DEPENDS= pinentry>0:${PORTSDIR}/security/pinentry-curses > +.else > RUN_DEPENDS= pinentry>0:${PORTSDIR}/security/pinentry > +.endif > > GNU_CONFIGURE= YES > USES= gmake iconv tar:bzip2 Yes, I had a closer look at the code last night, and the only possible addition I could find. Was possibly adding: --disable-fallback-curses to the -ncurses slave port. But in the end, what would be gained? I think your patch above does it all. Thanks for your time, and consideration, Dmitry, and have a Merry Christmas! --Chris > > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------