Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 438897 - Review Request: framewave - Image and signal processing routines
Summary: Review Request: framewave - Image and signal processing routines
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-03-25 20:47 UTC by Orion Poplawski
Modified: 2009-03-10 19:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-03-10 19:34:55 UTC

Attachments (Terms of Use)

Description Orion Poplawski 2008-03-25 20:47:28 UTC
Spec URL:
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 04:34:37 UTC
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 22:40:02 UTC
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/ 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 <> - 1.1-0.20080417.1
- 1.1 17APR08 devbuild
- Add BR boost-devel

Comment 3 Orion Poplawski 2008-05-12 16:18:14 UTC

* Thu May 8 2008 Orion Poplawski <> - 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/

No idea where the above comes from.  fwBase is linked:

g++ -o build/tmp/fwBase_release_shared_32/ -m32 -lboost_thread-mt
-Wl,-soname, -shared

framewave.i386: W: unused-direct-shlib-dependency /usr/lib/
framewave.i386: W: unused-direct-shlib-dependency /usr/lib/
framewave.i386: W: unused-direct-shlib-dependency /usr/lib/
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 18:54:31 UTC
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 19:42:22 UTC
* Wed Aug 6 2008 Orion Poplawski <> - 1.2-1
- Update to 1.2 release
- Fixup unit test run

Comment 6 Jason Tibbitts 2008-08-09 23:51:08 UTC
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

Comment 7 Orion Poplawski 2008-08-11 15:58:53 UTC
Unit Test failures reported upstream:

Comment 8 David Woodhouse 2008-11-02 12:15:56 UTC
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 23:42:31 UTC
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 <> - 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-04 00:44:53 UTC
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 15:57:11 UTC
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 17:57:09 UTC
Matches what I'm seeing.  Errors have been reported (see comment #7), but no response yet.

Comment 13 Jason Tibbitts 2008-11-20 19:52:32 UTC
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-10 00:10:03 UTC
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 19:34:55 UTC
Let's just close this.

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