public inbox for gentoo-science@lists.gentoo.org
 help / color / mirror / Atom feed
From: Reinis Danne <rei4dan@gmail.com>
To: gentoo-science@lists.gentoo.org
Subject: Re: [gentoo-science] blas selection in lapack-reference
Date: Wed, 22 Jan 2014 12:02:07 +0200	[thread overview]
Message-ID: <20140122100207.GE13149@dhcppc1> (raw)
In-Reply-To: <aa3d32b86d5dda0f42756d75035a4b67@slingshot.co.nz>

On Wed, Jan 22, 2014 at 10:54:48PM +1300, François Bissey wrote:
> On 2014-01-22 22:47, Reinis Danne wrote:
> > On Tue, Jan 21, 2014 at 07:47:48PM -0600, Steven Trogdon wrote:
> >> On Wed, 22 Jan 2014 13:52:57 +1300
> >> François Bissey <fbissey@slingshot.co.nz> wrote:
> >> 
> >> > We have yet another instance of someone emerging lapack-reference
> >> > without
> >> > a valid blas configuration in
> >> > https://bugs.gentoo.org/show_bug.cgi?id=498490
> >> > (not their original problem).
> >> > I think we should do something about this in lapack-reference and
> >> > possibly
> >> > other ebuilds.
> >> > In pkg_setup, we could run
> >> > eselect blas update
> >> > to make sure that a valid configuration is active
> >> > and display an informational message about the blas provider
> >> > used with the output of
> >> > eselect blas show
> >> >
> >> > Who thinks is a good/bad idea?
> >> >
> >> > Francois
> >> >
> >> 
> >> For one, I'm in favor of something like this - though I probably don't 
> >> have
> >> much say in the matter. I've been bitten by not eselecting {blas, 
> >> cblas,
> >> lapack} after an upgrade. And I've even posted on this forum the 
> >> problem.
> >> 
> >> http://article.gmane.org/gmane.linux.gentoo.science/1915
> >> http://article.gmane.org/gmane.linux.gentoo.science/1916
> >> 
> >> I resolved things, quite accidently, by re-eselecting the important
> >> components which were eselected before the upgrade.
> >> 
> >> Steve
> >> 
> > 
> > I fixed provider selection during upgrades in overlay
> > (yesterday). Now it should have valid provider set at any time.
> > With that do you still think it would need this extra eselect
> > update in ebuild?
> > 
> > 
> It seems that the difficult point is when you go from no provider 
> available
> to one provider available. If that case is fixed then: No

That case also works.


Reinis


      reply	other threads:[~2014-01-22 10:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22  0:52 [gentoo-science] blas selection in lapack-reference François Bissey
2014-01-22  1:47 ` Steven Trogdon
2014-01-22  9:47   ` Reinis Danne
2014-01-22  9:54     ` François Bissey
2014-01-22 10:02       ` Reinis Danne [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140122100207.GE13149@dhcppc1 \
    --to=rei4dan@gmail.com \
    --cc=gentoo-science@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox