Bug 142991 - rpmbuild --rebuild distcache-1.4.5-6.src.rpm fails
Summary: rpmbuild --rebuild distcache-1.4.5-6.src.rpm fails
Alias: None
Product: Fedora
Classification: Fedora
Component: distcache   
(Show other bugs)
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-15 16:57 UTC by Greg Schmidt
Modified: 2008-02-03 17:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-03 17:25:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Greg Schmidt 2004-12-15 16:57:13 UTC
Description of problem:
building distcache from src.rpm fails ssl.h usability test.

Ran across this while building the dependencies for Apache 2.0.52

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
It requires these dependencies:
[root@LOCALHOST SRPMS]# rpm -q -p -R distcache-1.4.5-6.src.rpm
automake >= 1.7
autoconf >= 2.50
rpmlib(CompressedFileNames) <= 3.0.4-1

We seem to have them:
[root@LOCALHOST SRPMS]# rpm -q -a | grep
"automake\|autoconf\|libtool\|openssl-devel" | sort

Actual Results:  But the build fails:
[root@LOCALHOST SRPMS]# rpmbuild --rebuild  distcache-1.4.5-6.src.rpm
checking for strtol... yes
checking for strdup... yes
checking for SSL/TLS toolkit base... none
checking openssl/opensslv.h usability... yes
checking openssl/opensslv.h presence... yes
checking for openssl/opensslv.h... yes
checking openssl/ssl.h usability... no
checking openssl/ssl.h presence... no
checking for openssl/ssl.h... no
configure: error: No SSL/TLS headers were available
configure: error: /bin/sh './configure' failed for ssl
error: Bad exit status from /var/tmp/rpm-tmp.8427 (%build)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.8427 (%build)

Expected Results:  Successful build of distcache binary rpm.

Additional info:

Our ssl headers should have come from openssl-devel-0.9.7a-40.src.rpm
which was built this morning, right before the distcache attempt.
[root@LOCALHOST SRPMS]# ls -l /usr/include/openssl/ssl.h
-rw-r--r--    1 root     root        74482 Dec 15 09:40


Comment 1 Jinnah Dylan Hosein 2005-09-17 00:51:51 UTC
Looking at /usr/src/redhat/BUILD/distcache-1.4.5/ssl/config.log
it's choking on trying to include krb5.h from kssl.h

I stole the krb5_prefix code from the openssh.spec and stuck it in.

That seems to work nicely.

here is the patch to distcache.spec

--- distcache.spec      2004-08-31 15:16:21.000000000 -0400
+++ distcache.spec.new  2005-09-16 20:43:17.000000000 -0400
@@ -35,6 +35,16 @@
 %patch0 -p1 -b .setuid
+krb5_prefix=`krb5-config --prefix`
+if test "$krb5_prefix" != "%{_prefix}" ; then
+        CPPFLAGS="$CPPFLAGS -I${krb5_prefix}/include
-I${krb5_prefix}/include/gssapi"; export CPPFLAGS
+        CFLAGS="$CFLAGS -I${krb5_prefix}/include -I${krb5_prefix}/include/gssapi"
+        LDFLAGS="$LDFLAGS -L${krb5_prefix}/%{_lib}"; export LDFLAGS
+        krb5_prefix=
+        CPPFLAGS="-I%{_includedir}/gssapi"; export CPPFLAGS
+        CFLAGS="$CFLAGS -I%{_includedir}/gssapi"
 libtoolize --force --copy && aclocal && autoconf
 automake -aic --gnu || : automake ate my hamster
 %configure --enable-shared

Comment 2 Matthew Miller 2006-07-10 21:33:04 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 3 petrosyan 2008-02-03 17:25:03 UTC
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.

Setting status to "INSUFFICIENT_DATA", however if you still
experience this problem after updating to our latest Fedora
release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.

Thank you in advance.

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