On 05/06/2013 02:57 PM, Divyesh Raithatha wrote:
Hello all, has anyone had success in building an RPM from the v2.x.x branch from http://git.freeradius.org? I am following the information from http://wiki.freeradius.org/guide/Red-Hat-FAQ On a CentOS 6.4 x64 system I was able to build an RPM from 2.2.0 source successfully but I want to get all of the recent patches from the v2.x.x branch. However, when I tried to build the RPM from v2.x.x I get the following message:
Hunk #1 FAILED at 121. 1 out of 1 hunk FAILED -- saving rejects to file src/main/radtest.in.rej error: Bad exit status from /var/tmp/rpm-tmp.uETav5 (%prep) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.uETav5 (%prep)
Here is the radtest.in.rej file contents:
--- src/main/radtest.in <http://radtest.in> 2011-09-30 10:12:07.000000000 -0400 +++ src/main/radtest.in <http://radtest.in> 2012-01-05 15:51:56.877585514 -0500 @@ -121,7 +121,7 @@ echo "EAP-Code = Response" echo "EAP-Type-Identity = \"$1\"" fi - if [ "$6" ] + if [ ! -z "$6" ] && [[ $6 =~ ^[0-9]+$ ]] && [ $6 -gt 0 ] then echo "Framed-Protocol = PPP" fi
Here is the contents of /var/tmp/rpm-tmp.uETav5
#!/bin/sh RPM_SOURCE_DIR="/home/test/rpmbuild/SOURCES" RPM_BUILD_DIR="/home/test/rpmbuild/BUILD" RPM_OPT_FLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic" RPM_ARCH="x86_64" RPM_OS="linux" export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS RPM_DOC_DIR="/usr/share/doc" export RPM_DOC_DIR RPM_PACKAGE_NAME="freeradius" RPM_PACKAGE_VERSION="2.2.0" RPM_PACKAGE_RELEASE="1.el6" export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE LANG=C export LANG unset CDPATH DISPLAY ||:
RPM_BUILD_ROOT="/home/test/rpmbuild/BUILDROOT/freeradius-2.2.0-1.el6.x86_64" export RPM_BUILD_ROOT PKG_CONFIG_PATH="/usr/lib64/pkgconfig:/usr/share/pkgconfig" export PKG_CONFIG_PATH set -x umask 022 cd "/home/test/rpmbuild/BUILD" LANG=C export LANG unset DISPLAY cd '/home/test/rpmbuild/BUILD' rm -rf 'freeradius-server-2.2.0' /usr/bin/bzip2 -dc '/home/test/rpmbuild/SOURCES/freeradius-server-2.2.0.tar.bz2' | /bin/tar -xf - STATUS=$? if [ $STATUS -ne 0 ]; then exit $STATUS fi cd 'freeradius-server-2.2.0' /bin/chmod -Rf a+rX,u+w,g-w,o-w . echo "Patch #1 (freeradius-cert-config.patch):" /bin/cat /home/test/rpmbuild/SOURCES/freeradius-cert-config.patch | /usr/bin/patch -p1 -b --suffix .cert-config --fuzz=0 echo "Patch #2 (freeradius-radtest.patch):" /bin/cat /home/test/rpmbuild/SOURCES/freeradius-radtest.patch | /usr/bin/patch -p1 -b --suffix .radtest --fuzz=0 #%patch3 -p1 -b .man #%patch4 -p1 -b .unix-passwd-expire echo "Patch #5 (freeradius-radeapclient-ipv6.patch):" /bin/cat /home/test/rpmbuild/SOURCES/freeradius-radeapclient-ipv6.patch | /usr/bin/patch -p1 -b --suffix .radeapclient-ipv6 --fuzz=0 #%patch6 -p1 #%patch7 -p1 -b perl echo "Patch #8 (freeradius-dhcp_sqlippool.patch):" /bin/cat /home/test/rpmbuild/SOURCES/freeradius-dhcp_sqlippool.patch | /usr/bin/patch -p1 --fuzz=0 # Some source files mistakenly have execute permissions set find $RPM_BUILD_DIR/freeradius-server-2.2.0 \( -name '*.c' -o -name '*.h' \) -a -perm /0111 -exec chmod a-x {} + exit 0
Any Ideas?
The patch set is targeted at a *specific* freeradius version. You're trying to apply patches from one version against another version. Sometimes that works, sometimes it doesn't. A patch may not succeed for several reasons, the code may have shifted position in the file (fuzz > 0), RPM disallows this because it's evidence of not keeping the spec file current against the version being built. You can override this with %global _default_patch_fuzz 2 at the top of the spec file (2 in this case is an old default before it was changed to 0). Overriding the patch fuzz factor is not recommended, instead it's recommended you fix the patch to make it 100% correct for the current version. Another reason a patch might not succeed is because the problem was already reported upstream and upstream fixed it. If they took the patch verbatim then the error you'll see is something akin to "Previously applied patch or reverse patch". If upstream fixed the issue in some other way the patch simply won't apply. Figuring exactly which lines of code changed and why is the work of a package maintainer. In this case you're assuming that role and you'll have to do that work. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/