Description of problem: We really should have: %check make -C %{_target_platform} check I see from the review this was disabled because of some issues at the time. If there are some, perhaps just those could be disabled. I noticed because I'm seeing a hang in a gdl test inside some eigen3 code and so went looking to see if eigen3 has a test suite. I'm trying it out in rawhide at the moment, but the tests do take a long time to compile... Also you might want to cleanup the spec and remove: - rm -rf %{buildroot} in %install - %clean - %defattr - BuildRoot as they are no longer needed for EL6+
Hmm, probably should have %{?_smp_flags} on the make check line as well.
These are the failures I'm seeing now in rawhide: test 631 Start 631: gmres_2 631: Test command: /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test/runtest.sh "gmres_2" 631: Test timeout computed to be: 1500 631: /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test/runtest.sh: line 20: 22113 Aborted ./$1 > /dev/null 2> .runtest.log 631: Test gmres_2 failed: 631: 631: Test check_sparse_square_solving(gmres_colmajor_diag) failed in /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/unsupported/test/../../test/sparse_solver.h (39) 631: x.isApprox(refX,test_precision<Scalar>()) 631: Stack: 631: - check_sparse_square_solving(gmres_colmajor_diag) 631: - test_gmres_T<std::complex<double> >() 631: - gmres 631: - Seed: 1375306889 631: 631: 2/4 Test #631: gmres_2 ..........................***Failed 0.63 sec test 632 Start 632: minres_1 632: Test command: /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test/runtest.sh "minres_1" 632: Test timeout computed to be: 1500 632: /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test/runtest.sh: line 20: 22116 Aborted ./$1 > /dev/null 2> .runtest.log 632: Test minres_1 failed: 632: 632: Test check_sparse_square_solving(minres_colmajor_diag) failed in /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/unsupported/test/../../test/sparse_solver.h (39) 632: x.isApprox(refX,test_precision<Scalar>()) 632: Stack: 632: - check_sparse_square_solving(minres_colmajor_diag) 632: - test_minres_T<double>() 632: - minres 632: - Seed: 1375306890 632: 632: 3/4 Test #632: minres_1 .........................***Failed 0.01 sec test 647 Start 647: bdcsvd_2 647: Test command: /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test/runtest.sh "bdcsvd_2" 647: Test timeout computed to be: 1500 647: /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test/runtest.sh: line 20: 22119 Aborted ./$1 > /dev/null 2> .runtest.log 647: Test bdcsvd_2 failed: 647: 647: Test ( bdcsvd(n, false) ) failed in /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/unsupported/test/svd_common.h (46) 647: test_isApprox(m, u * sigma * v.adjoint()) 647: Stack: 647: - ( bdcsvd(n, false) ) 647: - bdcsvd 647: - Seed: 1375306890 647: 647: 4/4 Test #647: bdcsvd_2 .........................***Failed 0.01 sec I'm also seeing intermittent errors with dontalign_3, and I've seen gmres_2 pass as well. So definitely some flaky code that needs to be addressed.
Related upstream bug: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=539
Yep I also see failures here and there (i.e. the metis backend test does not compile at all). I'll look further as time allows.
Thanks for your work on this. I'll look at updating the f19 and f18 branches with eigen 3.1.4 later today, and will carry over your spec enhancements there.
Another thing to look as is making eigen3 an arch specific package so that the tests always get run on all of the different architectures. Right now we're building on arm: http://koji.fedoraproject.org/koji/taskinfo?taskID=5693434 so we'll see how that goes...
Does a noarch -> arch change need special considerations concerning upgrade paths?
I'm really not sure. Definitely worth asking/testing.
I found this [1] where I read [12:27] <rdieter> and it's not entirely clear (to me anyway) how yum handles/balks at arch -> noarch -> arch upgrade paths. [...] [12:29] <skvidal> rdieter: yum handles those fine [12:29] <skvidal> arch->noarch->arch isn't a problem except for glibc and kernel so should be straight forward (worth testing nevertheless though). [1] https://fedoraproject.org/wiki/Packaging:Minutes20070403
So, after numerous attempts, I've managed to get a build to succeed (http://koji.fedoraproject.org/koji/buildinfo?buildID=447825). I'll close this bug, though I doubt that I've cornered out all flaky tests.