Bug 432194

It appears you're trying to build on a system that is a mix of f8 and rawhide
build toolchains. (been there, seen that error with other packages). Can't
remember exactly what bits need updating, but basically, unless you upgrade the
entire build toolchain to the rawhide bits or back it all off to the f8 ones,
you lose. Not a numpy bug though, closing NOTABUG.

AFAIK I have a clean f8 build toolchain
only additional repository is livna

Pretty sure you don't have f8-only. My laptop is definitely f8-only, fully
up-to-date, and numpy rebuilds just fine. And again, this is a generic debuginfo
thing that would be causing every single f8 updates build to fail in koji, which
isn't the case. Try rebuilding just about anything else, it'll probably fail wit
a similar message. Its NOT a numpy rebuild bug.

Just a few minutes ago, from my f8-only laptop:
[...]
Wrote: /data/sources/fedora-cvs/numpy/F-8/numpy-1.0.3.1-2.fc8.src.rpm
Wrote: /data/sources/fedora-cvs/numpy/F-8/x86_64/numpy-1.0.3.1-2.fc8.x86_64.rpm
Wrote:
/data/sources/fedora-cvs/numpy/F-8/x86_64/numpy-debuginfo-1.0.3.1-2.fc8.x86_64.rpm
Executing(%clean): /bin/sh -e /data/buildroot/tmp/rpm-tmp.52467
+ umask 022
+ cd /data/sources/fedora-cvs/numpy/F-8
+ cd numpy-1.0.3.1
+ rm -rf /data/buildroot/tmp/numpy-1.0.3.1-2.fc8-root-jarod
+ exit 0

You know.. to be really sure.. you should be building against f8 build
environment under mock.  If it builds under mock, and its not building with
rpmbuild, your setup has some sort of customization that you aren't aware of.

Which is why I'm pretty sure things are working...since it builds under mock for me.

In fact generally, you should reach for mock for local rebuilds, to ensure a
consistent build environment.

-jef

Yeah, sorry, I meant to suggest mock as well, since that's what stuff builds in
on the build systems.

I can't remember what the pieces are that cause this type of build failure, but
its definitely something like binutils or elfutils or rpm or gcc from devel,
coupled with one or more of the others from f8... So if anything, there's
probably a Requires: missing from some piece of the build toolchain that would
have prevented this, but definitely not numpy's problem.

Finally I succeeded to make mock work.
Now numpy builds clean and I can diff the output.
IMO it seems building numpy breaks if g77,
which is from compat-gcc-34-g77-3.4.6-8,
which is part of fedora 8 is installed.

So now the question is:
Is this an excepted behavior,
or should there be a config parameter added to
configure of numpy.

But thank you anyway, for pointing me to mock.

Hrm. It does seem perhaps we could stand to add a config param to numpy to make
sure it doesn't use the gcc 34 g77... Okay, I'll reopen this and change the summary.

Can you try this on the current version of numpy?  I just built 1.1.0 without
compat-gcc-34-g77 installed, successfully, then installed it, and built again,
also successfully.  I'm running F-9, but the versions should be the same.

Just tried again with 1.1.0 with F-8, but still the same behavior:
OK, if compat-gcc-34-g77 is not installed.
But having it installed still gives:
[...]
extracting debug info 
from /var/tmp/numpy-1.1.0-1.fc8-root-root/usr/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so
*** ERROR: No build ID note found 
in /var/tmp/numpy-1.1.0-1.fc8-root-root/usr/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so
error: Bad exit status from /var/tmp/rpm-tmp.78894 (%install)


RPM build errors:
    InstallSourcePackage: Header V3 DSA signature: NOKEY, key ID 30c9ecf8

For me it would be OK to have OK-builds in the mock environment only.
So setting this bug on "wontfix" is also OK for me. YMMV

Given the date, I think I'll reluctantly take your suggestion.