The current stable spqr-1.2.3-r1 makes a call to "doins" without "insinto" and we'd like to make that an error. If you could stabilize the new version and drop the old one, it would help out. Thanks!
I am not sure what to do, current stable version doesn't build, but we cannot stabilize new one due to test failures :/
It seems there may be a problem in cholmod Core was generated by `/dev/shm/portage/sci-libs/spqr-1.3.1/work/spqr-1.3.1_build/Demo/.libs/qrdemo'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fa6786b6610 in free () from /lib64/libc.so.6 [Current thread is 1 (Thread 0x7fa6792c1700 (LWP 4363))] (gdb) bt #0 0x00007fa6786b6610 in free () from /lib64/libc.so.6 #1 0x00007fa678a85aeb in cholmod_l_free () from /usr/lib64/libcholmod.so.0 #2 0x00007fa678a8245a in cholmod_l_free_dense () from /usr/lib64/libcholmod.so.0 #3 0x00007fa678ca29e5 in cholmod_dense_struct* SuiteSparseQR_qmult<double>(int, SuiteSparseQR_factorization<double>*, cholmod_dense_struct*, cholmod_common_struct*) () from /dev/shm/portage/sci-libs/spqr-1.3.1/work/spqr-1.3.1_build/Source/.libs/libspqr.so.0 #4 0x00005614880f60ba in main () It looks like the problem is in chomod. But generally it looks like we are shipping really old version of all the suitesparse components. spqr 1.3.1 is from 2012, the last suitesparse package has 2.0.8 (Dec. 2016). And similarly with cholmod.
Either this is finally solved or sci-libs/spqr, dev-lang/julia and sci-libs/suitesparse are removed (for the others the dep is optional). But we cannot stay forever with the stable version not building at all and the other not working :/
I will be taking care of this. ETA one week. Please undo the package mask.
was anything done to solve the situation?
There are several tickets about spqr and other suitesparse packages. I offered proxy maintenance for them and I already have ebuilds for newer suitesparse version including spqr in the sage-on-gentoo overlay. Is there a way we can make progress on this?
CCing QA team to see how can we progress here. If failing tests are not because of things breaking for real, we could RESTRICT them, but if it's the opposite, we have all versions broken in the tree now (and for many months)
Any news on this?
There's a new version 2.0.9 in the tree now. We could try to stabilize that instead if it won't break any consumers.
Unable to check for sanity: > no match for package: =sci-libs/spqr-1.3.1
(In reply to Michael Orlitzky from comment #9) > There's a new version 2.0.9 in the tree now. We could try to stabilize that > instead if it won't break any consumers. it seems it was finally stabilized
