Description of problem: arpack-3.9.0-1.fc39 appears to be bad. "test eigs" fails in octave, it passes with previous (3.8) version and with a locally-build library using upstream sources. I also noticed that headers in arpack-devel are inconsistent - some of them in arpack/ and some of them in arpack-ng/ . Dmitri. --
rpm -ql arpack-devel /usr/include/arpack /usr/include/arpack-ng /usr/include/arpack-ng/arpack.h /usr/include/arpack-ng/arpack.hpp /usr/include/arpack-ng/arpackSolver.hpp /usr/include/arpack-ng/debug_c.h /usr/include/arpack-ng/debug_c.hpp /usr/include/arpack-ng/stat_c.h /usr/include/arpack-ng/stat_c.hpp /usr/include/arpack/arpackdef.h /usr/include/arpack/arpackicb.h /usr/include/arpack/debug.h /usr/include/arpack/debugF90.h /usr/include/arpack/stat.h /usr/include/arpack/statF90.h /usr/lib64/libarpack.so /usr/lib64/libarpack64.so /usr/lib64/pkgconfig/arpack.pc /usr/lib64/pkgconfig/arpack64.pc /usr/lib64/pkgconfig/arpackSolver.pc /usr/lib64/pkgconfig/arpackSolver64.pc /usr/lib64/pkgconfig/parpack.pc /usr/lib64/pkgconfig/parpack64.pc
(In reply to Dmitri A. Sergatskov from comment #0) > Description of problem: > > arpack-3.9.0-1.fc39 appears to be bad. "test eigs" fails in octave, I am not familiar with octave and Fedora octave builds did pass with 3.9.0: https://koji.fedoraproject.org/koji/taskinfo?taskID=106901934 I need more details. > it passes with previous (3.8) version and with a locally-build > library using upstream sources. How did you build 3.9.0 locally? > I also noticed that headers in arpack-devel are inconsistent - some of them > in arpack/ and some of them in arpack-ng/ . That is how upstream installs them.
(In reply to Dominik 'Rathann' Mierzejewski from comment #2) > (In reply to Dmitri A. Sergatskov from comment #0) > > Description of problem: > > > > arpack-3.9.0-1.fc39 appears to be bad. "test eigs" fails in octave, > > I am not familiar with octave and Fedora octave builds did pass with 3.9.0: > https://koji.fedoraproject.org/koji/taskinfo?taskID=106901934 In particular: ... libinterp/corefcn/__eigs__.cc-tst .............................. pass 1/1 ... sparse/eigs.m .................................................. pass 206/207 REGRESSION 1 OK, this is different from the build with 3.8.0: sparse/eigs.m .................................................. pass 207/207 Is this what you are referring to? Why does octave build not fail if tests fail? What's the point of running the tests, then?
> Is this what you are referring to? Yes. > Why does octave build not fail if tests fail? > What's the point of running the tests, then? You have to ask people who build octave for Fedora. Dmitri. --
(In reply to Dmitri A. Sergatskov from comment #4) > > Is this what you are referring to? > > Yes. Ok. > > Why does octave build not fail if tests fail? > > What's the point of running the tests, then? > > You have to ask people who build octave for Fedora. I just did, in bug 2242128. Thanks for the report.
(In reply to Dominik 'Rathann' Mierzejewski from comment #2) > (In reply to Dmitri A. Sergatskov from comment #0) [...] > > it passes with previous (3.8) version and with a locally-build > > library using upstream sources. > > How did you build 3.9.0 locally? You still haven't answered that one.
I was wrong in the original report. I do not see the difference between upstream and the rpm. I do see difference between different CPUs. The bug looks 100% reproducible on amd-k6 / Fedora 39. I definitely saw it some time ago on i9-9880H / fedora 39 , but cannot reproduce it there any more. I has not been able to reproduce the problem on Ryzen 9 3950X / Centos Stream 9. The bug appears to be due to some numerical precision issue in identifying the type of the input matrix. So it may be affected by compiler chain. Perhaps the last compiler update "fixed" the problem on i9 computer. Dmitri. --
(In reply to Dmitri A. Sergatskov from comment #7) > I was wrong in the original report. I do not see the difference between > upstream and the rpm. > I do see difference between different CPUs. The bug looks 100% reproducible > on amd-k6 / Fedora 39. Do you mean https://en.wikipedia.org/wiki/AMD_K6 ? That's 32-bit and not supported by Fedora for years. How did you manage to run Fedora 39 on that CPU?
Sorry: AMD FX(tm)-8350 Eight-Core Processor Dmitri. --
arpack 3.9.1 has been released: https://github.com/opencollab/arpack-ng/releases/tag/3.9.1 It seems to fix the problem for me. This is on affected machine: $ LD_PRELOAD=~/src/arpack-ng-3.9.0/SRC/.libs/libarpack.so.2.1.0 octave -qf octave:1> test eigs ***** testif HAVE_ARPACK <*57196> x = ones (10, 10); z = complex (x, x); A = [sparse(10,10), z; z', sparse(10,10)]; d = eigs (A); assert (isreal (d)); [~, d] = eigs (A); assert (isreal (d)); !!!!! regression: https://octave.org/testfailure/?57196 eigs: error -9999 in znaupd: PASSES 206 out of 207 tests octave:2> $ LD_PRELOAD=~/src/arpack-ng-3.9.1/SRC/.libs/libarpack.so.2.1.0 octave -qf octave:1> test eigs PASSES 207 out of 207 tests octave:2> Dmitri. --
Thanks for the tip, I'll prepare an update soon.
FEDORA-2023-0b45b217ca has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-0b45b217ca
FEDORA-2023-0b45b217ca has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-0b45b217ca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-0b45b217ca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-0b45b217ca has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.