From owner-freebsd-ports@FreeBSD.ORG Tue Mar 29 00:40:56 2011 Return-Path: Delivered-To: ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC60D106566B; Tue, 29 Mar 2011 00:40:56 +0000 (UTC) (envelope-from alexander@wittig.name) Received: from hotzenplotz.wittig.name (unknown [IPv6:2a02:180:1:1:1c:c068:de48:0]) by mx1.freebsd.org (Postfix) with ESMTP id 5131B8FC08; Tue, 29 Mar 2011 00:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wittig.name; s=mail; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=tHTOW222QMrccnn/8twjI+5NixqEUrqcDJF8iLUleQw=; b=nlS8GC9uvGwGV5TtFuGSfJLdW/N+96pbh1MpAaezvFAca87ix6Xaxb3Aaz3r3vDLhebm/9Y5ITq0Dj1lUu+asR5pDC9Zxx4bokMq7A6Ww0t0vOnIbup9pCT4/OQTMBXDK2s9EogsDugkIm30k4i9UF1haz/I2KzsrfMoKF1+hUc=; Received: from adsl-99-18-83-178.dsl.lgtpmi.sbcglobal.net ([99.18.83.178] helo=[192.168.1.64]) by hotzenplotz.wittig.name with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Q4MzH-0001gP-R1; Tue, 29 Mar 2011 02:40:51 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alexander Wittig In-Reply-To: <4D9119FB.6090604@FreeBSD.org> Date: Mon, 28 Mar 2011 20:40:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63978FF4-8727-411A-85B3-9E2E7B0C1513@wittig.name> References: <20110328194251.9F2FE1CC0C@ptavv.es.net> <4D90F43B.7050606@delphij.net> <4D90F63F.7000901@FreeBSD.org> <4D90FB97.1020208@delphij.net> <4D9119FB.6090604@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: d@delphij.net, Kevin Oberman , ports@FreeBSD.ORG, delphij@FreeBSD.ORG, umq@ueo.co.jp, Xin LI Subject: Re: Unable to configure dirmngr after openldap upgrade X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 00:40:57 -0000 Am 28.03.2011 um 19:30 schrieb Doug Barton: > On 03/28/2011 14:20, Xin LI wrote: >> On 03/28/11 13:57, Doug Barton wrote: >>> On 03/28/2011 13:48, Xin LI wrote: >>>> On 03/28/11 12:42, Kevin Oberman wrote: >>>>> Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. = I'll >>>>> take a look at CHANGES and see if I can figure out what broke the >>>>> inclusion of fetch(3) support if I get a bit of time. >>>>=20 >>>> It seems that libldif now referenced the fetch support, and = ironically >>>> it seem be a bug but a feature :( >>>>=20 >>>> I have decided to disable FETCH support from now on, since it's = likely >>>> to bring more problems. >>>>=20 >>>> (If you would prefer to fix the problem for this specific problem, = I >>>> think adding a '-lfetch' would be sufficient; but, it seems to be >>>> undesirable to depend fetch(3) unconditionally for all programs = that >>>> uses openldap). >>=20 >>> I know next to nothing about how the openldap-client stuff works, so = I'm >>> sorry if these questions are silly. :) The biggest question is, does >>> dirmngr compile after your change? The other question is that the = only >>> reason I have openldap installed at all is so that gnupg can use it = to >>> fetch keys from ldap keyservers. Will this still work when the FETCH >>> option is no longer present? >>=20 >> hmm... how do I test fetching from an ldap keyserver? >=20 > I'll save you the trouble. :) I got your latest update and tested = both scenarios myself, and the answer is that they both work. >=20 > So now the question is, should the FETCH OPTION be removed altogether? = I imagine that a lot of users will be at least as confused as I, and = word is that PRs for other ports are already showing up. Being the one who caused the FETCH OPTION to be added in the first place = (see ports/145337), I'm in favor of completely disabling it = unconditionally. As noted in this PR, linking openldap-client with = libfetch also can introduce other ugly side effects depending on your = environment. In my case, I use security/openssl from ports, but since = libfetch is built against openssl from base the result is that my = www/apache22 (with LDAP support) depended on two conflicting versions of = OpenSSL (from base through libfetch and ports/openssl directly). The effect of turning this off seems to be minor. Grepping around the = OpenLDAP source tree, the only place where the URL fetching actually is = used is to support LDIF values referenced from a URL (e.g. using = "myPicture: