Red Hat Bugzilla – Bug 438897
Review Request: framewave - Image and signal processing routines
Last modified: 2009-03-10 15:42:19 EDT
Spec URL: http://www.cora.nwra.com/~orion/fedora/framewave.spec
SRPM URL: http://www.cora.nwra.com/~orion/fedora/framewave-1.0.1-1.fc8.src.rpm
Derived from the AMD Performance Library, Framewave is a free and open-source
collection of popular image and signal processing routines designed to
accelerate application development, debugging, multi-threading and optimiza-
tion on x86-class processor platforms.
Framewave revolutionizes the way silicon manufacturers deliver performance
and optimization tools to software developers. Sponsored by AMD, the open-
source Framewave project offers developers unparalleled, code-level access to
a vast array of arithmetic, signal- and image-processing functions and
Could you comment on the compiler flags? This doesn't make use of the usual set
of compiler flags, although -g is there so at least the debuginfo package is OK.
Unfortunately I know nothing about scons so I don't know how to get the right
flags in there, and this is odd numerical software so maybe there's a reason
that they're not used.
Otherwise, rpmlint just complains about some unused-direct-shlib-dependency
bits, but the package as a whole seems OK.
Well, the package is trying to carefully build different code for different
processors that will be selected at run time (gets compiled multiple times
with/without -msse3 -msse2 for example). Generally with scons it looks like you
should be able to specify CCFLAGS="" on the scons line, but this package appears
to override that. I'll poke upstream, but I'm not sure what their response
would be. We could patch BuildTools/buildscripts/fwflags_gcc.py to add our
flags, but then it wouldn't change dynamically.
In the meantime, bumped to the latest version:
* Tue Apr 29 2008 Orion Poplawski <firstname.lastname@example.org> - 1.1-0.20080417.1
- 1.1 17APR08 devbuild
- Add BR boost-devel
* Thu May 8 2008 Orion Poplawski <email@example.com> - 1.1-0.20080505.1
- 1.1 05MAY08 beta
- Add RPM_OPT_FLAGS to build
- Run UnitTest in %%check
rpmlint still has:
framewave.i386: W: unused-direct-shlib-dependency /usr/lib/libfwBase.so.1.1.0
No idea where the above comes from. fwBase is linked:
g++ -o build/tmp/fwBase_release_shared_32/libfwBase.so -m32 -lboost_thread-mt
framewave.i386: W: unused-direct-shlib-dependency /usr/lib/libfwImage.so.1.1.0
framewave.i386: W: unused-direct-shlib-dependency /usr/lib/libfwVideo.so.1.1.0
framewave.i386: W: unused-direct-shlib-dependency /usr/lib/libfwJPEG.so.1.1.0
framewave.i386: W: unused-direct-shlib-dependency
I think it's going to be pretty hard to fix these, as currently there is only a
single set of loadflags for all libraries. I'll poke upstream about it.
This one failed to build because the test suite needs csh. (?!)
I added that, and things then fail later:
ls: cannot access
No such file or directory
g++ -m64 -g -DLIN -DLIN64 -fPIC -c -o
In file included from ../BaseObjects/Object.h:11,
../BaseObjects/UnitTest.h:84:20: error: fwBase.h: No such file or directory
ut_iCompare.cpp:11:21: error: fwImage.h: No such file or directory
and the failures seem to cascade from there.
* Wed Aug 6 2008 Orion Poplawski <firstname.lastname@example.org> - 1.2-1
- Update to 1.2 release
- Fixup unit test run
This does indeed build now, but I note that several of the tests seem to fail for me (x86_64, rawhide in mock). Too many to include here, so I did a scratch build. Just search for "failed" at http://koji.fedoraproject.org/koji/getfile?taskID=768334&name=build.log
Unit Test failures reported upstream:
I take it we're not approving the package until either the unit tests pass, or we have a convincing explanation of why it's OK for them to be failing.
Marking as NEEDINFO until such fix (or explanation) is forthcoming...
Here's the latest build. There are still a handful of unit test failures, though not as many as before I believe. I'm not sure this is enough to block a review though, I don't think so. I'll let the hypothetical possible future reviewer decide.
* Mon Nov 3 2008 Orion Poplawski <email@example.com> - 1.3-0.20081029.1
- 1.3 29OCT08 devbuild
- Build FwHeaderConvert_lin from source
- Use "thread=systemboost" build option to use system boost library
Generally I would leave it up to the maintainer. After all, you have to deal with bugs reported against your package if those test failures actually cause problems in use by end-users.
It would certainly be good to document the failures in the spec somehow, either by listing them out or perhaps by filing a ticket here (once the package is imported, of course) or with upstream and adding a reference to it.
I did look at the failing tests. Most (12 of 17) seem to be FP overflow issues:
Buffer mismatch at index: 0
One is confusing to me:
Buffer mismatch at index: 0
I don't see what's differing there.
Three do not provide any failure messages. The remaining one:
Buffer mismatch at index: 0
TestCase 1 (Test 1) failed!
doesn't mean anything to me.
Do these match the failures you're seeing? Does upstream have any comment on them?
Matches what I'm seeing. Errors have been reported (see comment #7), but no response yet.
It's still up to you. If you want to push this package with the test suite issues intact, I'm OK with that; just document the fact in the spec and include a link to the upstream ticket.
So it's been many months now; is there any possibility of progress, or should this just be closed?
Let's just close this.