[Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls

[Ryan Tandy]

On Fri, Apr 08, 2016 at 08:41:01PM +0300, Timo Aaltonen wrote:
>It is done! Or at least available for review:
>
>http://anonscm.debian.org/cgit/users/tjaalton/openldap.git/commit/?h=nss2

Cool!

>389-ds-base builds fine against it, but I haven't tested multimaster or
>"traditional" freeipa replication with it yet.
>
>I'd like to get this in Ubuntu 16.04 as a backup plan if the remaining
>dependencies for freeipa 4.3.1 can't make it in time, so if you have
>time to review the packaging within the next few days (!) that would be
>awesome.

The following comments are just from looking at the commit, I haven't 
built or tested it yet.

Are you planning to do this in unstable as well, or just in xenial (as 
it sounds like it might be a temporary measure)? Luca and I talked about 
binNEW a while back, and flagged the out-of-date debian/copyright and 
remaining lintian errors as possible concerns that might slow that down.

Sorry about git master still being entangled with my unfinished 2.4.44 
update. Pushing that incomplete was a bad idea and I have been 
regretting it. I am trying to dedicate some time to it this weekend...

Adding libldap-common probably resolves #330695. I don't remember 
whether there was anything else to be done for that one.

The dh_auto_configure invocation you have looks like it breaks stage1 
builds (unconditional --enable-slapd).

I notice the ITS#7373 patch hasn't been applied upstream yet. If we're 
going to apply the NSS patches to both source trees, maybe you could 
ping them for a review?

What happens if both copies of libldap somehow end up linked into the 
same process? I don't know freeipa well enough to imagine a specific 
scenario, but it probably involves PAM somehow... Looks like curl 
handles this via renaming the symbol versions, we could probably do the 
same, if needed.

I had anticipated a second out-of-tree build with the same source, so 
now I'm curious: what required copying the source tree? It looks like 
nss-build.patch is just changing the filename of the shared library, not 
the SONAME or anything, right? (Should it? Or are they actually 
ABI-compatible? From an earlier comment of yours, it sounded like they 
might not be.)

What does the NSS build do with the TLS_CACERT setting we put in the 
default ldap.conf? I notice #726116 is still open.

Best of luck getting freeipa working, by one approach or the other...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20160408/82cbe3e8/attachment.sig>