Bug 991928 - 389-dsgw: FTBFS in rawhide
Summary: 389-dsgw: FTBFS in rawhide
Alias: None
Product: Fedora
Classification: Fedora
Component: 389-dsgw
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F20FTBFS
TreeView+ depends on / blocked
Reported: 2013-08-05 02:57 UTC by Dennis Gilmore
Modified: 2013-09-30 00:48 UTC (History)
6 users (show)

Fixed In Version: 389-dsgw-1.1.11-1.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-08-20 20:53:01 UTC
Type: ---

Attachments (Terms of Use)

Description Dennis Gilmore 2013-08-05 02:57:55 UTC
Your package 389-dsgw failed to build from source in current rawhide.


Build logs:
root.log: http://kojipkgs.fedoraproject.org/work/tasks/4285/5694285/root.log
build.log: http://kojipkgs.fedoraproject.org/work/tasks/4285/5694285/build.log
state.log: http://kojipkgs.fedoraproject.org/work/tasks/4285/5694285/state.log
NOTE: build logs are cleaned up after 1 week

For details on mass rebuild see https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

Comment 1 Petr Pisar 2013-08-06 11:01:48 UTC
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?

Comment 2 Rich Megginson 2013-08-06 14:41:35 UTC
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?

Comment 3 Dennis Gilmore 2013-08-06 20:15:20 UTC
if you need to build against 389-adminutil you need to add a BuildRequires for it.

Comment 4 Rich Megginson 2013-08-06 20:30:54 UTC
(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?

Comment 5 Adam Williamson 2013-08-06 21:34:30 UTC
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
+ 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

Comment 6 Adam Williamson 2013-08-06 21:40:53 UTC
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.])

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.

Comment 7 Adam Williamson 2013-08-06 21:48:49 UTC
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.

Comment 8 Adam Williamson 2013-08-06 22:12:28 UTC
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.

Comment 9 Adam Williamson 2013-08-06 22:31:36 UTC
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.

Comment 10 Adam Williamson 2013-08-06 22:34:10 UTC
F19 buildroot has pkgconfig-0.27.1-1.fc19.x86_64 , F20 has pkgconfig-0.28-3.fc20.x86_64 . Could be the difference.

Comment 11 Adam Williamson 2013-08-06 22:35:34 UTC
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.

Comment 12 Adam Williamson 2013-08-06 22:37:36 UTC
(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).

Comment 13 Petr Pisar 2013-08-07 08:05:29 UTC
(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.

Comment 14 Adam Williamson 2013-08-07 15:59:51 UTC
Petr: sorry, the first "wrong" was a think-o, it's meant to say "right".

Comment 15 Rich Megginson 2013-08-07 20:59:05 UTC
Upstream ticket:

Comment 16 Fedora Update System 2013-08-20 20:48:05 UTC
389-dsgw-1.1.11-1.fc19 has been submitted as an update for Fedora 19.

Comment 17 Rich Megginson 2013-08-20 20:53:01 UTC
Fixed in rawhide

Comment 18 Fedora Update System 2013-09-30 00:48:33 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.