Bug 438897 - Review Request: framewave - Image and signal processing routines
Review Request: framewave - Image and signal processing routines
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-25 16:47 EDT by Orion Poplawski
Modified: 2009-03-10 15:42 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-10 15:34:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2008-03-25 16:47:28 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
Comment 1 Jason Tibbitts 2008-04-05 00:34:37 EDT
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.
Comment 2 Orion Poplawski 2008-04-29 18:40:02 EDT
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 <orion@cora.nwra.com> - 1.1-0.20080417.1
- 1.1 17APR08 devbuild
- Add BR boost-devel
Comment 3 Orion Poplawski 2008-05-12 12:18:14 EDT

* Thu May 8 2008 Orion Poplawski <orion@cora.nwra.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
-Wl,-soname,libfwBase.so.1 -shared

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.

Comment 4 Jason Tibbitts 2008-06-27 14:54:31 EDT
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
-I../../UnitTestFramework/UnitTestFramework/ -I../BaseObjects/
In file included from ../BaseObjects/Object.h:11,
                 from ThresholdAndCompareObjects.h:10,
                 from ut_iCompare.cpp:10:
../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.
Comment 5 Orion Poplawski 2008-08-06 15:42:22 EDT
* Wed Aug 6 2008 Orion Poplawski <orion@cora.nwra.com> - 1.2-1
- Update to 1.2 release
- Fixup unit test run

Comment 6 Jason Tibbitts 2008-08-09 19:51:08 EDT
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
Comment 7 Orion Poplawski 2008-08-11 11:58:53 EDT
Unit Test failures reported upstream:

Comment 8 David Woodhouse 2008-11-02 07:15:56 EST
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...
Comment 9 Orion Poplawski 2008-11-03 18:42:31 EST
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 <orion@cora.nwra.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

Comment 10 Jason Tibbitts 2008-11-03 19:44:53 EST
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.
Comment 11 Jason Tibbitts 2008-11-06 10:57:11 EST
I did look at the failing tests.  Most (12 of 17) seem to be FP overflow issues:
  Buffer mismatch at index: 0
  Actual: {inf,-inf}
  Expected: {6.80565e+37,-1.36113e+38}

One is confusing to me:
  Buffer mismatch at index: 0
  Actual: 2.82843
  Expected: 2.82843
I don't see what's differing there.

Three do not provide any failure messages.  The remaining one:

        Catalog: RotateCenterTestCatalog
                Function: fwiRotateCenter_8u_C1R
Buffer mismatch at index: 0
Actual: 3
Expected: 4
                        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?
Comment 12 Orion Poplawski 2008-11-06 12:57:09 EST
Matches what I'm seeing.  Errors have been reported (see comment #7), but no response yet.
Comment 13 Jason Tibbitts 2008-11-20 14:52:32 EST
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.
Comment 14 Jason Tibbitts 2009-03-09 20:10:03 EDT
So it's been many months now; is there any possibility of progress, or should this just be closed?
Comment 15 Orion Poplawski 2009-03-10 15:34:55 EDT
Let's just close this.

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