[Pkg-openldap-devel] DEBIAN / UBUNTU OPENLDAP WILL NOT BUILD FROM SOURCE
GI Joe
medic333333 at gmail.com
Tue May 24 00:00:41 UTC 2016
FYI.... as I originally stated in the OP... OpenLDAP is broke. Not going
into all the gory details at this time... there's too many.
It basically works as long as you don't use TLS for anything anywhere. Or,
use it as a tinker toy.
LDAP is a core system. TESTING must be performed for a release.
Keep that in mind as Vladimir Putin and Canonical work out the details of
the Debian build with the KGB.
;)
On Mon, May 23, 2016 at 1:18 PM, GI Joe <medic333333 at gmail.com> wrote:
> OF NOTE... Note the sequencing in "dh" shown in its sourcecode excerpt
> below...
>
>
> ----------------------------------------------------------------------------
>
>> ---->>>[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.
>
> --------------------------------------------------------------------------------
>
> FROM DH SOURCE CODE:
>
> }];
> $sequences{'build-indep'} = [@bd];
> $sequences{'build-arch'} = [@bd];
> if (! compat(8)) {
> # From v9, sequences take standard rules targets into account.
> $sequences{build} = [@bd_minimal, rules("build-arch"),
> rules("build-indep")];
> $sequences{'install-indep'} = [rules("build-indep"), @i];
> $sequences{'install-arch'} = [rules("build-arch"), @i];
> $sequences{'install'} = [rules("build"), rules("install-arch"),
> rules("install-indep")];
> $sequences{'binary-indep'} = [rules("install-indep"), @b];
> $sequences{'binary-arch'} = [rules("install-arch"), @ba, @b];
> $sequences{binary} = [rules("install"), rules("binary-arch"),
> rules("binary-indep")];
> }
> else {
> $sequences{build} = [@bd];
> $sequences{'install'} = [@{$sequences{build}}, @i];
> $sequences{'install-indep'} = [@{$sequences{'build-indep'}}, @i];
> $sequences{'install-arch'} = [@{$sequences{'build-arch'}}, @i];
> $sequences{binary} = [@{$sequences{install}}, @ba, @b];
> $sequences{'binary-indep'} = [@{$sequences{'install-indep'}}, @b];
> $sequences{'binary-arch'} = [@{$sequences{'install-arch'}}, @ba,
> @b];
> }
>
> sub rules {
> return "debian/rules ".join(" ", @_);
> }
>
>
> On Sun, May 22, 2016 at 10:23 PM, GI Joe <medic333333 at gmail.com> wrote:
>
>> 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/20160523/764d14ba/attachment.html>
More information about the Pkg-openldap-devel
mailing list