Unable to configure dirmngr after openldap upgrade

[Kevin Oberman]

> Date: Mon, 28 Mar 2011 16:30:03 -0700
> From: Doug Barton <dougb at FreeBSD.org>
> 
> 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.
> >>>
> >>> It seems that libldif now referenced the fetch support, and ironically
> >>> it seem be a bug but a feature :(
> >>>
> >>> I have decided to disable FETCH support from now on, since it's likely
> >>> to bring more problems.
> >>>
> >>> (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).
> >
> >> 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?
> >
> > hmm... how do I test fetching from an ldap keyserver?
> 
> I'll save you the trouble. :)  I got your latest update and tested both 
> scenarios myself, and the answer is that they both work.
> 
> 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.

No joy. I updated openldap-client to 2.4.25_1 and than tried to rebuild
dirmngr. Same error as I had before:
/usr/local/lib/libldap.so: undefined reference to `fetchGetURL'

Back to 2.2.24.

Thanks for trying to get this fixed up.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751