Bug 2241361

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.