[Pkg-openldap-devel] DEBIAN / UBUNTU OPENLDAP WILL NOT BUILD FROM SOURCE

[GI Joe]

:)

Noted your above and will let you know how it comes out or if I find
anything else.



On Sun, May 22, 2016 at 10:11 PM, Ryan Tandy <ryan at nardis.ca> wrote:

> On Sun, May 22, 2016 at 09:14:16PM -0500, GI Joe wrote:
>
>> ---->>>[OK. Why? Is this to work around the contrib modules (specifically
>> smbk5pwd) being set up to build with gnutls, while you're building with
>> openssl?]
>>
>> Just testing...  as I was saying... it appears that the problems originate
>> around all of that gssapi/samba stuff inserted circa 2009.   IMHO, It
>> should still be able to compile, test, install properly no matter what
>> libraries are finally linked.  (Try Redhat/Centos)
>>
>
> It does, for the components that are integrated in the autoconf build
> system, but the contrib modules are driven just by simple Makefiles, so do
> need some tweaking to ensure the proper flags are set.
>
> ---->>>[(I was expecting a 'dch --local', or some other edit to
>> debian/changelog, at this point, to distinguish your package from the
>> archive version...)]
>>
>> Not yet.  Don't need to since I'm doing this as prep work before rolling
>> out a 'final edition'.  Gotta be able to install and run it, first.  THEN
>> build debs.
>>
>
> OK.
>
> ---->>>[dh binary --with autoreconf
>> --builddirectory=/.../openldap-2.4.42+dfsg/debian/build
>> --parallel]
>>
>> Same thing.  dh executes to install target on "binary."  Builddirectory is
>> resolved in debian/rules as the same thing at line 34...
>>      builddir        := $(CURDIR)/debian/build
>>
>
> Not the same, trivially demonstrated:
>
> dh binary
>
> executes ./configure in the current directory, creating ./config.log.
>
> dh binary --builddirectory=$(pwd)/debian/build
>
> cd's into debian/build and executes ../../configure, creating
> debian/build/config.log.
>
> And that does matter, as evidenced by your earlier quotes of things
> failing to find debian/build/libtool.
>
> Autoreconf usually unnecessary too when working with a virgin source tree
>> or after a clean.
>>
>
> Yes, if we were building unmodified upstream sources: but in this case,
> you're missing out on changes made to configure.in by any Debian patches,
> of which there are several. Notably, some of the patches change or add
> other functionality _and_ change the build system to make it all work; so
> if you still have those packages included but you're not doing autoreconf,
> then yes, it's quite likely to break.
>
> ---->>>[ Missing '--with autoreconf' might explain why you find yourself
>> having to edit configure.in, while missing --builddirectory would explain
>> the error about missing libtool I remarked on earlier. ]
>>
>> Not.  The vars were undefined in [context].  (Yes, I realize that's kinda
>> vague... but, I went thru that hours ago)   See below.
>> ....
>>
>> fakeroot dpkg-buildpackage comes after I know this thing is going to
>> install and execute and pass a couple hundred tests.
>>
>
> For faster iterations during development:
>
> export DEB_BUILD_OPTIONS=nocheck
>
> ---->>> 'dpkg-buildpackage -us -uc -b' does succeed for me, though, with no
>> changes at all to the package. So maybe try using that instead?]
>>
>> Try running an ldapsearch -ZZ resulting in TLS 1.2 from Debian/GnuTLS to
>> about 2000 other openldap servers running on Redhat or CentOS and you'll
>> understand pretty quick.  Try adding a few more overlays and backends,
>> too.
>>
>
> I don't understand how this is related to the dpkg-buildpackage
> suggestion, sorry.
>
> I said "with no changes to the package" because that's how I'm testing it.
> I'd make sure you're calling the right commands to build the source
> unmodified first, then change GnuTLS to OpenSSL. I wouldn't expect further
> changes to be necessary.
>
> (BELOW:  After my changes)
>>
>> build/top.mk:VERSION_OPTION = @VERSION_OPTION@
>>      <<<<-------------------------------
>>
>
> Looks like the VERSION_OPTION stuff is related to
> debian/patches/libldap-symbol-versions, which touches... configure.in. So
> yes, I'd expect to run into breakage with that patch applied but not
> running autoreconf.
>
> And your GSSAPI_LIBS problem probably has two parts... the first is also
> autoreconf-related (since the gssapi patch also modifies the build system),
> and the second is fixed by running dpkg-buildpackage instead of
> debian/rules directly, which _shouldn't_ be necessary, but apparently is
> with the current xenial package. Next time I touch the Ubuntu package I'll
> look into that and try to fix it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20160522/8b036ccf/attachment.html>