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

[GI Joe]

Something of note:  On your last comment about VERSION_OPTION.

VERSION_OPTION is defined in top.mk.  However, in the libraries tree
straight from umich.edu...  they don't include the Debian build top.mk.

Hence, I think that's the main issue with the {VARS} in the Debian
tradition.

On Sun, May 22, 2016 at 10:19 PM, GI Joe <medic333333 at gmail.com> wrote:

> :)
>
> 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/5fd531cc/attachment-0001.html>