Assigning to the active 'openblas' maintainer tv.
CC'ing the active maintainer for 'lapack', JoeQ.

Assignee: bugsquad => thierry.vignaud
CC: (none) => joequant

first rpm for mageia 8:  lapack-3.9.0-3.1.mga8

CC: (none) => mageia

this is OK in mga9

Version: Cauldron => 8
Whiteboard: MGA8TOO => (none)

Fixed in mga8:

src:
    - lapack-3.9.0-3.1.mga8
    - openblas-0.3.12-4.1.mga8

CC: (none) => thierry.vignaud
Assignee: thierry.vignaud => qa-bugs

(In reply to Nicolas Lécureuil from comment #3)
> this is OK in mga9

Not for openblas.  System lapack is disabled there just as it is in mga8.

Version: 8 => Cauldron
Whiteboard: (none) => MGA8TOO
Assignee: qa-bugs => mageia

Packages for Mageia 8 update:
liblapack3-3.9.0-3.1.mga8
libblas-static-devel-3.9.0-3.1.mga8
liblapack-devel-3.9.0-3.1.mga8
libblas3-3.9.0-3.1.mga8
blas-doc-3.9.0-3.1.mga8
libblas-devel-3.9.0-3.1.mga8
lapack-doc-3.9.0-3.1.mga8
liblapack-static-devel-3.9.0-3.1.mga8
libopenmp0-0.3.12-4.1.mga8
libthreads0-0.3.12-4.1.mga8
libserial0-0.3.12-4.1.mga8
openblas-0.3.12-4.1.mga8
libopenblas-devel-0.3.12-4.1.mga8
libopenblas-static-devel-0.3.12-4.1.mga8

from SRPMS:
lapack-3.9.0-3.1.mga8.src.rpm
openblas-0.3.12-4.1.mga8.src.rpm

Status comment: (none) => openblas using bundled lapack instead of system

yes but cauldron is with openblas-0.3.18 it already contains the fix on the bundled lapack

*     Quick return if possible
*
      IF( (N.LE.0) .OR. (M.LE.0) ) THEN
         RETURN
      END IF

Version: Cauldron => 8
Whiteboard: MGA8TOO => (none)
Assignee: mageia => qa-bugs

Sorry, the folowing package cannot be selected:

- lib64openblas-devel-0.3.12-4.1.mga8.x86_64 (because of unfulfilled lib64threads64_0(x86-64)[== 0.3.12-4.1.mga8]).
There is a mismatch in the name of lib64threads0

CC: (none) => herman.viaene

Did you use qarepo?  Sounds like the package naming isn't quite following our policies.

Status comment: openblas using bundled lapack instead of system => (none)

@ David
yes I use QARepo, but to my feeling this has nothing to do with it.
I fill in QARepo the names listed above in Comment 6. If the package would not exist with that name, QARepo throws an error saying this package cannot be found.
So then I enable this local repo in MCC, and use MCC to install. I got the error on selecting the first item in the list for installation in MCC, so there should/could be a mismatch in the packages required, versus the actual package names.

No, it is a qarepo problem (due to bad packaging) as I guessed.  Library packages on 64-bit are misnamed.

openblas-0.3.12-4.1.mga8
lib64openblas-devel-0.3.12-4.1.mga8
lib64openmp64_0-0.3.12-4.1.mga8
lib64serial640-0.3.12-4.1.mga8
lib64serial64_0-0.3.12-4.1.mga8
lib64threads64_0-0.3.12-4.1.mga8
lib64serial0-0.3.12-4.1.mga8
lib64threads0-0.3.12-4.1.mga8
lib64threads640-0.3.12-4.1.mga8
lib64openmp640-0.3.12-4.1.mga8
lib64openmp0-0.3.12-4.1.mga8
lib64openblas-static-devel-0.3.12-4.1.mga8

Sigh, lets not keep going on ...... Feeded list rom QARepo and the installation went OK.
No wiki, no previous bugs, I read from MCC :"OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version" and on this site https://www.openblas.net/:
"BLAS stands for Basic Linear Algebra Subprograms. BLAS provides standard interfaces for linear algebra, including BLAS1 (vector-vector operations), BLAS2 (matrix-vector operations), and BLAS3 (matrix-matrix operations). In general, BLAS is the computational kernel ("the bottom of the food chain") in linear algebra or scientific applications."
This all smells to specific developer's stuff, so I OK the update unless someone objects.

Whiteboard: (none) => MGA8-64-OK

(In reply to David Walser from comment #11)
> No, it is a qarepo problem (due to bad packaging) as I guessed.  Library
> packages on 64-bit are misnamed.
> 
No, it isn't a qarepo problem. Qarepo can only do what it is told to do, not necessarily what someone wants it to do. It is designed to catch missing dependencies, packages that aren't on the list provided but should be. It did just that. The list in Comment 6 was incomplete. 

QA can deal with package lists that have just "lib" and don't list "lib64" for the 64-bit libraries. We've come to expect it.  But in cases like this, where our usual conventions weren't followed, we should have been alerted to those differences.

Assuming Herman did an install straight from the package list in Comment 11 and not an update, I tested in VirtualBox for a clean update over the existing packages. There were no issues with that.

I read the descriptions in MCC, and I see where the lapack library is for implementing math functions that I either never learned or haven't used in 50 years, so no help there. urpmq showed that Hugin, a panorama creator, uses that library, which makes sense when I think about it.

So I ran Hugin and loaded a series of photos I took many years ago to use to create a panorama. Hugin asked for lens information when I loaded the photos, which I've long forgotten so I made something up. The photos loaded, and a preview was created. It looked odd, but then with made-up data it would. However, I was able to use various functions to edit the panorama, and it didn't crash, so I'd say it's OK.

Validating, on the basis of Herman's test, and mine.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

It's a QArepo problem in the sense that you wouldn't see the issue if you just used MageiaUpdate, not in the sense that there's anything wrong with QArepo.  As I said, it's a packaging problem, and I wasn't aware of it until Herman pointed it out.  We should probably open another bug to get the names fixed in Cauldron.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0586.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED