Created attachment 874694 [details]
Build log showing exactly where the failure occurs

Dominique, would you please have a look (in your own time, no hurry).

Thanks in advance.

Hmm, but the dynamic loader relies on the shared library to be present in
/usr/lib64/hwcaps/x86-64-v3/ (IIRC).  So to work the alternatives link
would need to be present there, pointing to the actual hwcaps library
in /usr/lib64/blas/hwcaps/x86-64-v3/... (or another directory or a changed
library name).

So I don't see how the generic hwcaps mechanism can be made work for the
case of lapack.  To me it seems the library copying would need to be
done manually in lapack and only the multibuild part of the hwcaps
mechanism preserved?

That said, IMO having "alternatives" for shared libraries is a red herring...
(but yeah, I understand why we have it, but then there's nothing wrong
with Conflicts and multiple providers of liblapack.so.3)

(In reply to Richard Biener from comment #3)
> Hmm, but the dynamic loader relies on the shared library to be present in
> /usr/lib64/hwcaps/x86-64-v3/ (IIRC).  So to work the alternatives link
> would need to be present there, pointing to the actual hwcaps library
> in /usr/lib64/blas/hwcaps/x86-64-v3/... (or another directory or a changed
> library name).
> 
> So I don't see how the generic hwcaps mechanism can be made work for the
> case of lapack.  To me it seems the library copying would need to be
> done manually in lapack and only the multibuild part of the hwcaps
> mechanism preserved?

I see, thanks for the explanation.

> 
> That said, IMO having "alternatives" for shared libraries is a red herring...
> (but yeah, I understand why we have it, but then there's nothing wrong
> with Conflicts and multiple providers of liblapack.so.3)

Alternatively, is there a way to directly generate the -v3 tuned libs using a multibuild flavour specifically for this? I mean, we could give using the right flags to generate the v3 libs, move them to the appropriate location and package them as part of a package manually named to liblapack-x86_64-v3 or similar. However, I do not know what the macro does in step-by-step detail.

On top of this, I believe I found a bug in /usr/lib/build/mkbaselibs which prevents 
 liblapacke3
   -/usr/lib(64)?/liblapacke.so.3
to work correctly. This change would fix it:
      } elsif (substr($r, 0, 1) eq '-') {
        delete $files{$_} for grep {/$rr/} keys %files;
+       delete $moves{$_} for grep {/$rr/} keys %moves;
      } elsif (substr($r, 0, 1) eq '"') {

However, this is moot since baselibs is too limited anyway.

Of course, you could use _multibuild to create the entire set of libraries as v3 libs. %_libdir would have to point to /usr/lib64/hwcaps/x86-64-v3/ and you may want to append a '_v3' to the names of the blas, cblas, lapack and lapacke subdirectories where the 'real' versions of the libraries reside.
Moreover, since this is for x86_64 only, you need to make sure to prevent the build of the v3 flavor on other arches.
Of course, this will not make the spec file more readable.

(In reply to Egbert Eich from comment #5)
> On top of this, I believe I found a bug in /usr/lib/build/mkbaselibs which
> prevents 
>  liblapacke3
>    -/usr/lib(64)?/liblapacke.so.3
> to work correctly. This change would fix it:
>       } elsif (substr($r, 0, 1) eq '-') {
>         delete $files{$_} for grep {/$rr/} keys %files;
> +       delete $moves{$_} for grep {/$rr/} keys %moves;
>       } elsif (substr($r, 0, 1) eq '"') {
> 
> However, this is moot since baselibs is too limited anyway.
> 
> Of course, you could use _multibuild to create the entire set of libraries
> as v3 libs. %_libdir would have to point to /usr/lib64/hwcaps/x86-64-v3/ and
> you may want to append a '_v3' to the names of the blas, cblas, lapack and
> lapacke subdirectories where the 'real' versions of the libraries reside.
> Moreover, since this is for x86_64 only, you need to make sure to prevent
> the build of the v3 flavor on other arches.
> Of course, this will not make the spec file more readable.

Thanks Egbert, I will try to make this multibuild work. You can review it and see how it looks and we can discard it if the specfile becomes too unwieldy. Complex specfiles will turn off potential new contributors, but AVX/AVX2 enhanced lapack might be too good to miss out on... tricky balancing act.

Correct me if I am wrong, but the GCC `-march` I would use for the new flavour is just `x86-64-v3`, right? That's it, no other additional flags?

So, what do we think:
<https://build.opensuse.org/package/show/home:badshah400:lapackv3/lapack>

> ~> cat _multibuild
> <multibuild>
>   <package>static</package>
>   <package>x86-64-v3</package>
> </multibuild>


> ~> ls -1 *x86-64-v3*.rpm
> libblas3-x86-64-v3-3.12.0-97.1.x86_64.rpm
> libcblas3-x86-64-v3-3.12.0-97.1.x86_64.rpm
> liblapack3-x86-64-v3-3.12.0-97.1.x86_64.rpm
> liblapacke3-x86-64-v3-3.12.0-97.1.x86_64.rpm
> libtmglib3-x86-64-v3-3.12.0-97.1.x86_64.rpm


> ~> rpm -qvlp ./libblas3-x86-64-v3-3.12.0-97.1.x86_64.rpm 
> ----------    1 root     root                        0 May  5 02:25 /etc/alternatives/libblas.so.3-x86-64-v3_x86_64
> drwxr-xr-x    2 root     root                        0 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas
> lrwxrwxrwx    1 root     root                       17 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas/libblas.so.3 -> libblas.so.3.12.0
> -rwxr-xr-x    1 root     root                  1050584 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas/libblas.so.3.12.0
> lrwxrwxrwx    1 root     root                       37 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/libblas.so.3 -> /etc/alternatives/libblas.so.3_x86_64
> drwxr-xr-x    2 root     root                        0 May  5 02:25 /usr/share/doc/packages/libblas3-x86-64-v3
> -rw-r--r--    1 root     root                     6175 May  5 02:25 /usr/share/doc/packages/libblas3-x86-64-v3/README.md
> drwxr-xr-x    2 root     root                        0 May  5 02:25 /usr/share/licenses/libblas3-x86-64-v3
> -rw-r--r--    1 root     root                     2266 May  5 02:25 /usr/share/licenses/libblas3-x86-64-v3/LICENSE

Most of the hwcaps related definitions are in the preamble. I tried to preserve the maintainability/readability of the specfile to the extent I think is possible.

Suggestions welcome.

(In reply to Atri Bhattacharya from comment #7)
> 
> 
> > ~> rpm -qvlp ./libblas3-x86-64-v3-3.12.0-97.1.x86_64.rpm 
> > ----------    1 root     root                        0 May  5 02:25 /etc/alternatives/libblas.so.3-x86-64-v3_x86_64
> > drwxr-xr-x    2 root     root                        0 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas
> > lrwxrwxrwx    1 root     root                       17 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas/libblas.so.3 -> libblas.so.3.12.0
> > -rwxr-xr-x    1 root     root                  1050584 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas/libblas.so.3.12.0
> > lrwxrwxrwx    1 root     root                       37 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/libblas.so.3 -> /etc/alternatives/libblas.so.3_x86_64
> > drwxr-xr-x    2 root     root                        0 May  5 02:25 /usr/share/doc/packages/libblas3-x86-64-v3
> > -rw-r--r--    1 root     root                     6175 May  5 02:25 /usr/share/doc/packages/libblas3-x86-64-v3/README.md
> > drwxr-xr-x    2 root     root                        0 May  5 02:25 /usr/share/licenses/libblas3-x86-64-v3
> > -rw-r--r--    1 root     root                     2266 May  5 02:25 /usr/share/licenses/libblas3-x86-64-v3/LICENSE
> 

Bit of a bug in the link to /etc/alternatives there, which I have already fixed since:

> ~> rpm -qvlp RPM/libblas3-x86-64-v3-3.12.0-101.1.x86_64.rpm 
> ----------    1 root     root                        0 May  5 02:25 /etc/alternatives/libblas.so.3-x86-64-v3_x86_64
> drwxr-xr-x    2 root     root                        0 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas
> lrwxrwxrwx    1 root     root                       17 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas/libblas.so.3 -> libblas.so.3.12.0
> -rwxr-xr-x    1 root     root                  1050584 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas/libblas.so.3.12.0
> lrwxrwxrwx    1 root     root                       47 May  5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/libblas.so.3 -> /etc/alternatives/libblas.so.3-x86-64-v3_x86_64
> drwxr-xr-x    2 root     root                        0 May  5 02:25 /usr/share/doc/packages/libblas3-x86-64-v3
> -rw-r--r--    1 root     root                     6175 May  5 02:25 /usr/share/doc/packages/libblas3-x86-64-v3/README.md
> drwxr-xr-x    2 root     root                        0 May  5 02:25 /usr/share/licenses/libblas3-x86-64-v3
> -rw-r--r--    1 root     root                     2266 May  5 02:25 /usr/share/licenses/libblas3-x86-64-v3/LICENSE
> 


Apologies for the noise.

Actually, I believe I got baselibs.conf to work - at least the library part, haven't looked into the devel packages, yet - also a master/slave mechanism for the update alternatives may be needed.
This will work only if the fix from comment #5 is applied to /usr/lib/build/mkbaselibs. I will try to discuss this with the maintainer on Monday.

Created attachment 874823 [details]
baselibs.conf - for comment #9.

(In reply to Egbert Eich from comment #9)
> Actually, I believe I got baselibs.conf to work - at least the library part,
> haven't looked into the devel packages, yet - also a master/slave mechanism
> for the update alternatives may be needed.
> This will work only if the fix from comment #5 is applied to
> /usr/lib/build/mkbaselibs. I will try to discuss this with the maintainer on
> Monday.

Wow, that's just wow. Colour me impressed!

(In reply to Egbert Eich from comment #9)
> Actually, I believe I got baselibs.conf to work - at least the library part,
> haven't looked into the devel packages, yet

My understanding is that devel pkgs do not need to be administered the hwcaps treatment: What happens is that glibc automatically points the .so link in the devel pkg to the hwcaps dir `/usr/lib64/glibc-hwcaps/x86-64-v3/` target should both that dir and `/usr/lib64` contain the same name shared object even if the devel .so link target is to the latter. At least that is my reading of how it works with the zlib pkg anyway.

(In reply to Atri Bhattacharya from comment #12)
> (In reply to Egbert Eich from comment #9)
> > Actually, I believe I got baselibs.conf to work - at least the library part,
> > haven't looked into the devel packages, yet
> 
> My understanding is that devel pkgs do not need to be administered the
> hwcaps treatment: What happens is that glibc automatically points the .so
> link in the devel pkg to the hwcaps dir `/usr/lib64/glibc-hwcaps/x86-64-v3/`
> target should both that dir and `/usr/lib64` contain the same name shared
> object even if the devel .so link target is to the latter. At least that is
> my reading of how it works with the zlib pkg anyway.

This would mean that we still need a link from glibc-hwcaps/x86-64-v3/liblapack.so.3.12.0 to glibc-hwcaps/x86-64-v3/lapack/liblapack.so.3.12.0. Since this would have to be created from within baselibs.conf, there is the challenge how to obtain the .so version. This could be added to baselibs.conf if it was auto-generated from the main spec file.

(In reply to Atri Bhattacharya from comment #12)
> (In reply to Egbert Eich from comment #9)
> > Actually, I believe I got baselibs.conf to work - at least the library part,
> > haven't looked into the devel packages, yet
> 
> My understanding is that devel pkgs do not need to be administered the
> hwcaps treatment: What happens is that glibc automatically points the .so
> link in the devel pkg to the hwcaps dir `/usr/lib64/glibc-hwcaps/x86-64-v3/`
> target should both that dir and `/usr/lib64` contain the same name shared
> object even if the devel .so link target is to the latter. At least that is
> my reading of how it works with the zlib pkg anyway.

The link editor (/usr/bin/ld) processes the /usr/lib64/lib*.so link, hwcaps
do not come into play at all here.  The hwcaps variant is expected to have
the same ABI as the "standard" variant so it doesn't make a difference which
to use at link time.

The dynamic loader upon execution of the linked program will then pick
the hwcaps variant if the hardware matches.

Note this is where it might be important that the hwcaps and non-hwcaps
variant alternatives come from the same implementation unless the ABIs
are 100% the same.  So I think ideally the alternatives setup would
have a link group and a single config to adjust.  Not sure if it's done
this way and whether it's possible at all if the group is split between
two packages.

(In reply to Egbert Eich from comment #13)
> (In reply to Atri Bhattacharya from comment #12)
> > (In reply to Egbert Eich from comment #9)
> > > Actually, I believe I got baselibs.conf to work - at least the library part,
> > > haven't looked into the devel packages, yet
> > 
> > My understanding is that devel pkgs do not need to be administered the
> > hwcaps treatment: What happens is that glibc automatically points the .so
> > link in the devel pkg to the hwcaps dir `/usr/lib64/glibc-hwcaps/x86-64-v3/`
> > target should both that dir and `/usr/lib64` contain the same name shared
> > object even if the devel .so link target is to the latter. At least that is
> > my reading of how it works with the zlib pkg anyway.
> 
> This would mean that we still need a link from
> glibc-hwcaps/x86-64-v3/liblapack.so.3.12.0 to
> glibc-hwcaps/x86-64-v3/lapack/liblapack.so.3.12.0. Since this would have to
> be created from within baselibs.conf, there is the challenge how to obtain
> the .so version. This could be added to baselibs.conf if it was
> auto-generated from the main spec file.

Yes, we could do with lapack's baselibs.conf the same as we did with openblas's i.e. generate it dynamically from inside the specfile. I think we are slowly approaching the point where the baselibs.conf becomes difficult to read as well, though.

What do we think about doing it the multibuild way instead, something like my trial in <https://build.opensuse.org/package/show/home:badshah400:lapackv3/lapack> goes? Looks more transparent, to me anyway.

(In reply to Richard Biener from comment #14)
> 
> Note this is where it might be important that the hwcaps and non-hwcaps
> variant alternatives come from the same implementation unless the ABIs
> are 100% the same.  So I think ideally the alternatives setup would
> have a link group and a single config to adjust.  Not sure if it's done
> this way and whether it's possible at all if the group is split between
> two packages.

We should probably implement a main and slave alternatives setup anyway so that both libblas.so.* and liblapack.so.* come from the same implementation. At the moment, my understanding is that one could theoretically use blas from implementation A (say, openblas) while still using cblas and lapack from the implementation B (reference netlib library, for example). I do not know whether this kind of usage is advisable.

The current baselibs.conf still uses the apparently broken
| liblapack3
|   -/usr/lib(64)?/liblapack.so.3
directive

I've therefore created https://github.com/openSUSE/obs-build/issues/1010

(In reply to Egbert Eich from comment #17)
> The current baselibs.conf still uses the apparently broken
> | liblapack3
> |   -/usr/lib(64)?/liblapack.so.3
> directive
> 
> I've therefore created https://github.com/openSUSE/obs-build/issues/1010

Thanks, yes we need this fix in mkbaselibs.

(In reply to Atri Bhattacharya from comment #18)
> (In reply to Egbert Eich from comment #17)
> > The current baselibs.conf still uses the apparently broken
> > | liblapack3
> > |   -/usr/lib(64)?/liblapack.so.3
> > directive
> > 
> > I've therefore created https://github.com/openSUSE/obs-build/issues/1010
> 
> Thanks, yes we need this fix in mkbaselibs.

Good news, after creating the github ticket, this got addressed.

@Atri, could you check if things are starting to work for you (it may take a while until the update has arrived in Factory/TW)? If so, we may be able to close this ticket.

(In reply to Egbert Eich from comment #19)
> (In reply to Atri Bhattacharya from comment #18)
> > (In reply to Egbert Eich from comment #17)
> > > The current baselibs.conf still uses the apparently broken
> > > | liblapack3
> > > |   -/usr/lib(64)?/liblapack.so.3
> > > directive
> > > 
> > > I've therefore created https://github.com/openSUSE/obs-build/issues/1010
> > 
> > Thanks, yes we need this fix in mkbaselibs.
> 
> Good news, after creating the github ticket, this got addressed.
> 
> @Atri, could you check if things are starting to work for you (it may take a
> while until the update has arrived in Factory/TW)? If so, we may be able to
> close this ticket.

Thanks Egbert, this works great. Checkout rev 35 in obs://home:badshah400:lapack2023/lapack, where I have enabled the -v3 libs. In the same project I have patched the `build` package to add the mkbaselibs commit referenced in the github issue to get this working.

This is just for testing now, I shall revert the hwcaps change in lapack before making the sr for boo#1223783 (since, as you have noted, we need to wait until Factory catches up with the mkbaselibs fix for this).

Also kudos for the great catch as to where the problem lay!

(In reply to Atri Bhattacharya from comment #20)
> 
> Thanks Egbert, this works great. Checkout rev 35 in
> obs://home:badshah400:lapack2023/lapack, where I have enabled the -v3 libs.
> In the same project I have patched the `build` package to add the mkbaselibs
> commit referenced in the github issue to get this working.

This has now moved to a new project: https://build.opensuse.org/project/show/home:badshah400:lapack-hwcaps
so that I can go ahead and submit the fix to boo#1223783 from the old (home:badshah400:lapack2023) project where I have reverted the hwcaps generation.

Sorry for the confusion.

@Atri: the major issues I'm seeing with the approach in home:badshah400:lapackv3/lapack are lines in baselib.conf like this:
  postin "ln -sf /etc/alternatives/libblas.so.3_<targettype> /usr/%_lib/libblas.so.3"
  postin "/usr/sbin/update-alternatives --force --install /usr/%_lib/libblas.so.3 libblas.so.3_<targettype> /usr/%_lib/blas/libblas.so.3  50"
  postun "/usr/sbin/update-alternatives --remove libblas.so.3_<targettype> /usr/%_lib/blas/libblas.so.3"

%_lib is a standard define which expands to /usr/lib or /usr/lib64. It doesn't expand to /usr/lib64/glibc-hwcaps/<targettype>:

home:badshah400:lapack-hwcaps/lapack/binaries$ rpm -q --scripts -p libcblas3-x86-64-v3-3.12.0-1.1.x86_64.rpm
warning: libcblas3-x86-64-v3-3.12.0-1.1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 4aeaf2b5: NOKEY
postinstall scriptlet (using /bin/sh):
/sbin/ldconfig
ln -sf /etc/alternatives/libcblas.so.3_x86-64-v3 /usr/lib64/libcblas.so.3
/usr/sbin/update-alternatives --force --install /usr/lib64/libcblas.so.3 libcblas.so.3_x86-64-v3 /usr/lib64/blas/libcblas.so.3  50
preuninstall scriptlet (using /bin/sh):
/usr/sbin/update-alternatives --remove libcblas.so.3_x86-64-v3 /usr/lib64/blas/libcblas.so.3

The only way to handle this I can think of would be to do something like this:

  postin "ldconfig -n /usr/%_lib/glibc-hwcaps/<targettype>/blas"
  postin "case <targettype> in x86-64-v*) p=glibc-hwcaps/<targettype> ;; esac"
  postin "/usr/sbin/update-alternatives --force --install /usr/%_lib/$p/libblas.so.3 libblas.so.3_<targettype> /usr/%_\
lib/$p/blas/libblas.so.3  50"
  postun "case <targettype> in x86-64-v*) p=glibc-hwcaps/<targettype> ;; esac"
  postun "/usr/sbin/update-alternatives --remove libblas.so.3_<targettype> /usr/%_lib/$p/libblas.so.3"

Disclaimer: I haven't tested this.

(In reply to Egbert Eich from comment #23)
> @Atri: the major issues I'm seeing with the approach in
> home:badshah400:lapackv3/lapack are lines in baselib.conf like this:
>   postin "ln -sf /etc/alternatives/libblas.so.3_<targettype>
> /usr/%_lib/libblas.so.3"
>   postin "/usr/sbin/update-alternatives --force --install
> /usr/%_lib/libblas.so.3 libblas.so.3_<targettype>
> /usr/%_lib/blas/libblas.so.3  50"
>   postun "/usr/sbin/update-alternatives --remove libblas.so.3_<targettype>
> /usr/%_lib/blas/libblas.so.3"
> 
> %_lib is a standard define which expands to /usr/lib or /usr/lib64. It
> doesn't expand to /usr/lib64/glibc-hwcaps/<targettype>:
> 
> home:badshah400:lapack-hwcaps/lapack/binaries$ rpm -q --scripts -p
> libcblas3-x86-64-v3-3.12.0-1.1.x86_64.rpm
> warning: libcblas3-x86-64-v3-3.12.0-1.1.x86_64.rpm: Header V3 RSA/SHA256
> Signature, key ID 4aeaf2b5: NOKEY
> postinstall scriptlet (using /bin/sh):
> /sbin/ldconfig
> ln -sf /etc/alternatives/libcblas.so.3_x86-64-v3 /usr/lib64/libcblas.so.3
> /usr/sbin/update-alternatives --force --install /usr/lib64/libcblas.so.3
> libcblas.so.3_x86-64-v3 /usr/lib64/blas/libcblas.so.3  50
> preuninstall scriptlet (using /bin/sh):
> /usr/sbin/update-alternatives --remove libcblas.so.3_x86-64-v3
> /usr/lib64/blas/libcblas.so.3
> 
> The only way to handle this I can think of would be to do something like
> this:
> 
>   postin "ldconfig -n /usr/%_lib/glibc-hwcaps/<targettype>/blas"
>   postin "case <targettype> in x86-64-v*) p=glibc-hwcaps/<targettype> ;;
> esac"
>   postin "/usr/sbin/update-alternatives --force --install
> /usr/%_lib/$p/libblas.so.3 libblas.so.3_<targettype> /usr/%_\
> lib/$p/blas/libblas.so.3  50"
>   postun "case <targettype> in x86-64-v*) p=glibc-hwcaps/<targettype> ;;
> esac"
>   postun "/usr/sbin/update-alternatives --remove libblas.so.3_<targettype>
> /usr/%_lib/$p/libblas.so.3"
> 
> Disclaimer: I haven't tested this.

The attempt in obs://home:badshah400:lapackv3/lapack is to generate the x86-64-v3 libs purely as a separate flavour, *without* the baselibs.conf coming into play at all in so far as these -v3 libs are concerned.

Baselibs.conf is still used to produce 32-bit biarch packages for pure x86_64 in this case, but it simply does not matter for x86-64-v3 flavour since there aren't i586-v3 equivalents.

But perhaps I misunderstand your question?

In other words, for no-name flavour:

> ~> osc ls -b home:badshah400:lapackv3 lapack -r openSUSE_Tumbleweed -a x86_64
> ::import::i586::blas-devel-32bit-3.12.0-117.1.x86_64.rpm
> ::import::i586::cblas-devel-32bit-3.12.0-117.1.x86_64.rpm
> ::import::i586::lapack-devel-32bit-3.12.0-117.1.x86_64.rpm
> ::import::i586::lapacke-devel-32bit-3.12.0-117.1.x86_64.rpm
> ::import::i586::libblas3-32bit-3.12.0-117.1.x86_64.rpm
> ::import::i586::libblas3-32bit-debuginfo-3.12.0-117.1.x86_64.rpm
> ::import::i586::libcblas3-32bit-3.12.0-117.1.x86_64.rpm
> ::import::i586::libcblas3-32bit-debuginfo-3.12.0-117.1.x86_64.rpm
> ::import::i586::liblapack3-32bit-3.12.0-117.1.x86_64.rpm
> ::import::i586::liblapack3-32bit-debuginfo-3.12.0-117.1.x86_64.rpm
> ::import::i586::liblapacke3-32bit-3.12.0-117.1.x86_64.rpm
> ::import::i586::liblapacke3-32bit-debuginfo-3.12.0-117.1.x86_64.rpm
> _buildenv
> _statistics
> blas-devel-3.12.0-117.1.x86_64.rpm
> cblas-devel-3.12.0-117.1.x86_64.rpm
> lapack-3.12.0-117.1.src.rpm
> lapack-debugsource-3.12.0-117.1.x86_64.rpm
> lapack-devel-3.12.0-117.1.x86_64.rpm
> lapacke-devel-3.12.0-117.1.x86_64.rpm
> libblas3-3.12.0-117.1.x86_64.rpm
> libblas3-debuginfo-3.12.0-117.1.x86_64.rpm
> libcblas3-3.12.0-117.1.x86_64.rpm
> libcblas3-debuginfo-3.12.0-117.1.x86_64.rpm
> liblapack3-3.12.0-117.1.x86_64.rpm
> liblapack3-debuginfo-3.12.0-117.1.x86_64.rpm
> liblapacke3-3.12.0-117.1.x86_64.rpm
> liblapacke3-debuginfo-3.12.0-117.1.x86_64.rpm
> libtmglib3-3.12.0-117.1.x86_64.rpm
> libtmglib3-debuginfo-3.12.0-117.1.x86_64.rpm
> rpmlint.log
> tmglib-devel-3.12.0-117.1.x86_64.rpm

while no baselibs-based biarch RPMs for the "x86-64-v3" flavour:

> ~> osc ls -b home:badshah400:lapackv3 lapack:x86-64-v3 -r openSUSE_Tumbleweed -a x86_64 
> _buildenv
> _statistics
> lapack-x86-64-v3-3.12.0-117.1.src.rpm
> lapack-x86-64-v3-debugsource-3.12.0-117.1.x86_64.rpm
> libblas3-x86-64-v3-3.12.0-117.1.x86_64.rpm
> libblas3-x86-64-v3-debuginfo-3.12.0-117.1.x86_64.rpm
> libcblas3-x86-64-v3-3.12.0-117.1.x86_64.rpm
> libcblas3-x86-64-v3-debuginfo-3.12.0-117.1.x86_64.rpm
> liblapack3-x86-64-v3-3.12.0-117.1.x86_64.rpm
> liblapack3-x86-64-v3-debuginfo-3.12.0-117.1.x86_64.rpm
> liblapacke3-x86-64-v3-3.12.0-117.1.x86_64.rpm
> liblapacke3-x86-64-v3-debuginfo-3.12.0-117.1.x86_64.rpm
> libtmglib3-x86-64-v3-3.12.0-117.1.x86_64.rpm
> libtmglib3-x86-64-v3-debuginfo-3.12.0-117.1.x86_64.rpm
> rpmlint.log

(In reply to Atri Bhattacharya from comment #24)
> 
> The attempt in obs://home:badshah400:lapackv3/lapack is to generate the
> x86-64-v3 libs purely as a separate flavour, *without* the baselibs.conf
> coming into play at all in so far as these -v3 libs are concerned.
> 
> Baselibs.conf is still used to produce 32-bit biarch packages for pure
> x86_64 in this case, but it simply does not matter for x86-64-v3 flavour
> since there aren't i586-v3 equivalents.
> 
> But perhaps I misunderstand your question?

No, you don't. What confused me: you were using the %suse_build_hwcaps macro - which you have removed since. The problem I see is: this macro is crafted to add the right 'magic' to the spec file (see https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros#%{?suse_build_hwcaps_libs}). This magic is "to automatically set specific build targets and schedule the job on workers which match the intended buildconstraint". Unfortunately, one can only guess how this works. Without baselibs.conf, two arch flavors will be built: x86_64 and x86_x6_v3. So I would think if you want to use flavors, you'd need to add:
#!BuildTarget: x86_64_v3-linux
#!BuildConstraint: hardware:cpu:flag x86-64-v3
to the spec file in the -v3 flavor on x86_64. When using baselibs.conf for -v3,  mkbaselibs will create a spec file which consumes these packages and 'repackages them into the main architecture'. You may need to do all this manually.
I'm currently trying to figure out how all this works.

(In reply to Egbert Eich from comment #26)
> (In reply to Atri Bhattacharya from comment #24)
> > 
> > The attempt in obs://home:badshah400:lapackv3/lapack is to generate the
> > x86-64-v3 libs purely as a separate flavour, *without* the baselibs.conf
> > coming into play at all in so far as these -v3 libs are concerned.
> > 
> > Baselibs.conf is still used to produce 32-bit biarch packages for pure
> > x86_64 in this case, but it simply does not matter for x86-64-v3 flavour
> > since there aren't i586-v3 equivalents.
> > 
> > But perhaps I misunderstand your question?
> 
> No, you don't. What confused me: you were using the %suse_build_hwcaps macro
> - which you have removed since.

Yes, this macro should not be used if we want to use flavours to manually produce the -v3 libs instead of their generation via baselibs.

> The problem I see is: this macro is crafted
> to add the right 'magic' to the spec file (see
> https://en.opensuse.org/openSUSE:
> Packaging_Conventions_RPM_Macros#%{?suse_build_hwcaps_libs}). This magic is
> "to automatically set specific build targets and schedule the job on workers
> which match the intended buildconstraint". Unfortunately, one can only guess
> how this works. 

My understanding is that it pretty much checks for the avx/avx2 instruction support on the build host's CPU. Similar to having a _constraint file that limits the build to the avx2 supporting CPUs:

> ~> cat _constraints
> <constraints>
>   <hardware><cpu>
>     <flag>sse3</flag>
>     <flag>avx2</flag>
>   </cpu></hardware>
> </constraints>

> Without baselibs.conf, two arch flavors will be built:
> x86_64 and x86_x6_v3. So I would think if you want to use flavors, you'd
> need to add:
> #!BuildTarget: x86_64_v3-linux
> #!BuildConstraint: hardware:cpu:flag x86-64-v3
> to the spec file in the -v3 flavor on x86_64. 

Yes, this is true. I have been only trying this out on my local machine (which supports x86-64-v3) but for a final version for OBS, my plan is to include a _constraints file to do this as documented here (or, equivalently, add the comments to specfile as you have noted):
<https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.build_constraints#id-1.5.10.16.8.6.3.3>

> When using baselibs.conf for
> -v3,  mkbaselibs will create a spec file which consumes these packages and
> 'repackages them into the main architecture'. You may need to do all this
> manually.
> I'm currently trying to figure out how all this works.

Same here: home:badshah400:lapackv3 is an early experiment about using flavours to generate the -v3 libs. Not (yet) ready for prime time :) Thanks for your reviews/advice.

Side note: I also learnt that RPM natively supports generating actual x86_64_v3 arch packages since version 4.19.0 (i.e. already in Factory). Perhaps we can have a look at how it does so:
<https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847>