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

GI Joe medic333333 at gmail.com
Mon May 23 18:18:15 UTC 2016


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/41d52e0e/attachment.html>


More information about the Pkg-openldap-devel mailing list