This is a bug tracker to follow the update of the new virtuals for blas, cblas and lapack mentioned on the science list. It resides now in the science overlay. Bugs (old ones and newer ones) involving blas,cblas,lapack configuration should block this one. We could proceed as follow: 1- Quick stabilization of the latest {blas,cblas,lapack}-reference packages (just commited, but I only tested x86 and amd64). 2 - Import all new virtual packages and optimized libraries. 3 - Wait 30 days, ask for stabilization of optmized libraries without bugs. 4 - cleanup of obsolete versions, virtuals and stale bugs. We have also a new documentation going on in bug #189680. Sébastien
*** Bug 189802 has been marked as a duplicate of this bug. ***
I've been running into vast quantities of issues lately where cblas-reference or some lapack is looking for a pkgconfig file that my older blas didn't install. One way to deal with this is to bump the virtual so it requires pkgconfig-safe versions.
> I've been running into vast quantities of issues lately where cblas-reference > or some lapack is looking for a pkgconfig file that my older blas didn't > install. One way to deal with this is to bump the virtual so it requires > pkgconfig-safe versions. I am waiting for various arches to stabilize the *-reference so we can bump the new virtuals. We also need to have the possibility of re-eselecting the same profile, which is the eselect bug #189942 ;-), and is probably also what's slowing down arches to stabilize. I must admit the whole process is a bit circular.
(In reply to comment #2) > I've been running into vast quantities of issues lately where cblas-reference > or some lapack is looking for a pkgconfig file that my older blas didn't > install. One way to deal with this is to bump the virtual so it requires > pkgconfig-safe versions. > We may also need to bump eselect and make sure it is pulled in via eselect-blas etc, so users have the fixed /usr/share/eselect/libs/skel.bash on their systems before they get started with the new ebuilds. Markus
(In reply to comment #4) > We may also need to bump eselect and make sure it is pulled in via eselect-blas > etc, so users have the fixed /usr/share/eselect/libs/skel.bash on their systems > before they get started with the new ebuilds. We first need to find someone who will roll an eselect release.
All done here too.
