On 17/03/14 13:31, Nathan Scott wrote:
Hi Ken,
----- Original Message -----
Makepkgs used to work just fine on my sgi ia64 platform running
SUSE Linux Enterprise Server 11.
But at some point over the last 12 months (I am guessing) it has all
gone sour ... and now Makepgs dies with this in the tail of the Logs/pcp
file ...
RPM build errors:
Could not open %files file
/home/kenj/src/pcp/pcp-3.9.1/libs_files.rpm: No such file or directory
make[1]: *** [pack_pcp] Error 1
Can anyone suggest what's wrong here, or what on earth I can provide in
the way of additional information that might help shed light on the failure?
It will be some unexpected interaction between pcp.spec.in and the makefiles
(and/or the configure paths).
In particular, if the %install section of pcp.spec.in initially produces an
empty set of files for "libs_files" - see lines 398 and 401 - then it will
fail in the way you're observing (I think) due to the awk at line 461 never
creating libs_files.rpm ... could be a /usr/lib32 vs /usr/lib vs /usr/lib64
issue?
OK thanks.
In pcp.spec.in there is this ...
%ifarch ia64 x86_64 ppc64 s390x
sed -i -e 's/usr\/lib\//usr\/lib64\//' libs_files
sed -i -e 's/usr\/lib\//usr\/lib64\//' devel_files
%endif
And indeed libs_files contains /usr/lib64 paths ... but on this platform
there is NO /usr/lib64 directory.
So is ia64 in the list above triggered by a real use case (in which case
we'll need some conditional code) or a guess at the right thing to do
for ia64?
I replaced the %ifarch block above with
%ifarch x86_64 ppc64 s390x
sed -i -e 's/usr\/lib\//usr\/lib64\//' libs_files
sed -i -e 's/usr\/lib\//usr\/lib64\//' devel_files
%endif
%ifarch ia64
%if "%{_vendor}" != "suse"
sed -i -e 's/usr\/lib\//usr\/lib64\//' libs_files
sed -i -e 's/usr\/lib\//usr\/lib64\//' devel_files
%endif
%endif
and fixed the python-ctypes Requires conditional that was broken for
every vendor except RedHat, and bingo!
Host PCP CPU Operating System
----------- -------- ------ ------------------
grundy 3.9.1 ia64 SUSE SLES11 SP1
and qa check -g python passes mostly (seems like we need curses.py which
is not installed on this machine)
and qa check -g sanity almost passes (2 failures, sigh)
|