checking for adminutil with pkg-config... checking for pkg-config... (cached) /usr/bin/pkg-config
configure: error: ADMINUTIL not found, specify with --with-adminutil.
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.CpiAes (%build)

Missing a dependency?

Package 389-adminutil was built for rawhide - why can't the 389-dsgw build find it?  Does 389-adminutil need to be explicitly added to the buildroots?

if you need to build against 389-adminutil you need to add a BuildRequires for it.

(In reply to Dennis Gilmore from comment #3)
> if you need to build against 389-adminutil you need to add a BuildRequires
> for it.

$ git remote -v
origin	ssh://pkgs.fedoraproject.org/389-dsgw (fetch)
origin	ssh://pkgs.fedoraproject.org/389-dsgw (push)
$ git branch
* master
$ grep adminutil 389-dsgw.spec
BuildRequires:    389-adminutil-devel
$ git status
nothing added to commit but untracked files present (use "git add" to track)


So, why can't it find 389-adminutil-devel?

I ran the configure script through sh -x in a mock chroot. Here's what it spits out:

+ printf '%s\n' 'configure:19671: checking for adminutil with pkg-config'
+ printf %s 'checking for adminutil with pkg-config... '
checking for adminutil with pkg-config... + set dummy pkg-config
+ ac_word=pkg-config
+ printf '%s\n' 'configure:19675: checking for pkg-config'
+ printf %s 'checking for pkg-config... '
checking for pkg-config... + : false
+ :
+ printf %s '(cached) '
(cached) + PKG_CONFIG=/usr/bin/pkg-config
+ test -n /usr/bin/pkg-config
+ printf '%s\n' 'configure:19705: result: /usr/bin/pkg-config'
+ printf '%s\n' /usr/bin/pkg-config
/usr/bin/pkg-config
+ test -n /usr/bin/pkg-config
+ /usr/bin/pkg-config --exists 389-adminutil
++ /usr/bin/pkg-config --cflags-only-I 389-adminutil
+ adminutil_inc='-I/usr/include/admsslutil -I/usr/include/adminutil -I/usr/include/nss3 -I/usr/include/nspr4 '
++ /usr/bin/pkg-config --libs-only-L 389-adminutil
+ adminutil_lib=
++ /usr/bin/pkg-config --libs-only-L 389-adminutil
++ sed -e s/-L//
++ sed -e 's/ .*$//'
+ adminutil_libdir=
+ test -z '-I/usr/include/admsslutil -I/usr/include/adminutil -I/usr/include/nss3 -I/usr/include/nspr4 ' -o -z ''
+ as_fn_error 0 'ADMINUTIL not found, specify with --with-adminutil.' 19729 5

Note that this check is m4/adminutil.m4 in the source tree. The bit that fails is this final check:

if test -z "$adminutil_inc" -o -z "$adminutil_lib"; then
  AC_MSG_ERROR([ADMINUTIL not found, specify with --with-adminutil.])
fi

that's this line from the sh -x output:

test -z '-I/usr/include/admsslutil -I/usr/include/adminutil -I/usr/include/nss3 -I/usr/include/nspr4 ' -o -z ''

it seems like the root of the problem is the failure to get anything at all for $adminutil_lib - the check seems to expect "$PKG_CONFIG --libs-only-L 389-adminutil" to be _something_, that's what it sets as $adminutil_lib , but that command is giving an empty result. The libs line in 389-adminutil.pc looks like this:

Libs: -ladmsslutil -ladminutil

indeed, there are no -L (as opposed to -l) parameters. So pkg-config is doing the wrong thing, but there's clearly some wrong assumption in adminutil.m4 somewhere, it seems.

Hmm. A 389-admin 1.1.31 build (so using that same adminutil.m4) did succeed against 389-adminutil-1.1.15-3.fc19 , that's the last successful build of something that's now affected by this FTBFS (389-admin fails exactly the same way, see 991927). 389-adminutil 1.1.15's pkgconfig file seems the same as 1.1.17's:

Libs: -ladmsslutil -ladminutil

so that build - http://koji.fedoraproject.org/koji/buildinfo?buildID=380798 - somehow succeeded with the pkgconfig and m4 that now appear to be failing. There must be some other factor involved here which somehow causes the test -z call to fail.

Still, it looks like the logic of that if/test bit is that it'll only 'pass' if both adminutil_inc and adminutil_lib are 'populated'. I don't know how the build mentioned in c#7 could possibly have succeeded in that case, but that seems clearly to be the problem here. I'm not sure if that test is even valid.

So I did an F19 test build in mock the same way. It passes the adminutil check. Note the subtle difference in the 'test' line:

+ test -z '-I/usr/include/admsslutil -I/usr/include/adminutil -I/usr/include/nspr4 -I/usr/include/nss3  ' -o -z ' '

seems like it gets an extra space character from...somewhere?...in the pkg-config output it takes as $adminutil_inc and $adminutil_lib : they both have one more trailing space than they do in the F20 version of the command. So adminutil_lib is ' ', not '', and that's enough to make the test pass. Indeed, just flipping a 'test -z' command between ' ' and '' shows the difference.

F19 buildroot has pkgconfig-0.27.1-1.fc19.x86_64 , F20 has pkgconfig-0.28-3.fc20.x86_64 . Could be the difference.

Anyway, it seems like the test really 'ought to have' failed on F19 too, it's just blind luck that the trailing space character made it pass. But the F19 build did then succeed. Ergo, it's actually fine for $adminutil_lib to be empty. Ergo, the test itself is bad, and should be changed.

(and also, when you're *writing* a check like that, it helps ever so much if you include *different* error messages for each possible failure case, and make each one as detailed and accurate as possible...the .m4 file simply reporting "ADMINUTIL not found" is not particularly helpful).

(In reply to Adam Williamson from comment #6)
> 
> Libs: -ladmsslutil -ladminutil
> 
> indeed, there are no -L (as opposed to -l) parameters. So pkg-config is
> doing the wrong thing, but there's clearly some wrong assumption in
> adminutil.m4 somewhere, it seems.

If the libraries are in in standard path, then the pkg-config is right. It's perfectly acceptable to output empty string in this case.

Petr: sorry, the first "wrong" was a think-o, it's meant to say "right".

Upstream ticket:
https://fedorahosted.org/389/ticket/47465

389-dsgw-1.1.11-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/389-dsgw-1.1.11-1.fc19

Fixed in rawhide

389-dsgw-1.1.11-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.