Bug 438897 - Review Request: framewave - Image and signal processing routines
Summary: Review Request: framewave - Image and signal processing routines
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: FE-DEADREVIEW
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:
Environment:
Last Closed: 2009-03-10 19:34:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Orion Poplawski 2008-03-25 20:47:28 UTC
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
Description:
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
routines.

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/fwflags_gcc.py to add our
flags, but then it wouldn't change dynamically.

In the meantime, bumped to the latest version:

http://www.cora.nwra.com/~orion/fedora/framewave.spec
http://www.cora.nwra.com/~orion/fedora/framewave-1.1-0.20080417.1.fc9.src.rpm

* Tue Apr 29 2008 Orion Poplawski <orion.com> - 1.1-0.20080417.1
- 1.1 17APR08 devbuild
- Add BR boost-devel

Comment 3 Orion Poplawski 2008-05-12 16:18:14 UTC
http://www.cora.nwra.com/~orion/fedora/framewave.spec
http://www.cora.nwra.com/~orion/fedora/framewave-1.1-0.20080505.1.fc9.src.rpm

* Thu May 8 2008 Orion Poplawski <orion.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
/lib/libm.so.6

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
build/tmp/fwBase_release_shared_32/obj/fwBase.obj
build/tmp/fwBase_release_shared_32/obj/ThreadPool.obj
build/tmp/fwBase_release_shared_32/obj/system.obj
build/tmp/fwBase_release_shared_32/common/obj/Constants.obj

framewave.i386: W: unused-direct-shlib-dependency /usr/lib/libfwImage.so.1.1.0
/usr/lib/libboost_thread-mt.so.3
framewave.i386: W: unused-direct-shlib-dependency /usr/lib/libfwVideo.so.1.1.0
/usr/lib/libboost_thread-mt.so.3
framewave.i386: W: unused-direct-shlib-dependency /usr/lib/libfwJPEG.so.1.1.0
/usr/lib/libboost_thread-mt.so.3
framewave.i386: W: unused-direct-shlib-dependency
/usr/lib/libfwSignal.so.1.1.0/usr/lib/libboost_thread-mt.so.3

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:

make
TMPDIR=/builddir/build/BUILD/FRAMEWAVE_1.1_SRC_05MAY08_BETA/UnitTest/tmp/release_64//ThresholdAndCompare
OUTDIR=/builddir/build/BUILD/FRAMEWAVE_1.1_SRC_05MAY08_BETA/UnitTest/bin/release_64/
BITNESS=64 CONFIG_TYPE=release
FW_INC_PATH=/builddir/build/BUILD/FRAMEWAVE_1.1_SRC_05MAY08_BETA/UnitTest/FWBuildBits
FW_BIN_PATH=/builddir/build/BUILD/FRAMEWAVE_1.1_SRC_05MAY08_BETA/Framewave/build/bin//release_shared_64
UNIT_TEST_FRAMEWORK_LIB_PATH=/builddir/build/BUILD/FRAMEWAVE_1.1_SRC_05MAY08_BETA/UnitTest/bin/release_64/
SRC_DIR=/builddir/build/BUILD/FRAMEWAVE_1.1_SRC_05MAY08_BETA/UnitTest/UnitTestCollection/ThresholdAndCompare
ls: cannot access
/builddir/build/BUILD/FRAMEWAVE_1.1_SRC_05MAY08_BETA/UnitTest/FWBuildBits/*.h:
No such file or directory
g++ -m64 -g -DLIN -DLIN64 -fPIC -c -o
/builddir/build/BUILD/FRAMEWAVE_1.1_SRC_05MAY08_BETA/UnitTest/tmp/release_64//ThresholdAndCompare/ut_iCompare.o
-I../../UnitTestFramework/UnitTestFramework/ -I../BaseObjects/
-I/builddir/build/BUILD/FRAMEWAVE_1.1_SRC_05MAY08_BETA/UnitTest/FWBuildBits
ut_iCompare.cpp
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 <orion.com> - 1.2-1
- Update to 1.2 release
- Fixup unit test run

http://www.cora.nwra.com/~orion/fedora/framewave.spec
http://www.cora.nwra.com/~orion/fedora/framewave-1.2-1.fc8.src.rpm

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 http://koji.fedoraproject.org/koji/getfile?taskID=768334&name=build.log

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

http://sourceforge.net/tracker/index.php?func=detail&aid=2046616&group_id=212624&atid=1022481

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 <orion.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

http://www.cora.nwra.com/~orion/fedora/framewave.spec
http://www.cora.nwra.com/~orion/fedora/framewave-1.3-0.20081029.1.fc9.src.rpm

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.