From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 60F0B138247 for ; Wed, 22 Jan 2014 10:02:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ABA9BE0F57; Wed, 22 Jan 2014 10:02:12 +0000 (UTC) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E3F4BE0F57 for ; Wed, 22 Jan 2014 10:02:11 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id t10so4711620eei.40 for ; Wed, 22 Jan 2014 02:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=5aKDymoaI0e7vWOL9bvqmV6pvx68koVlNhcn9S0EiUw=; b=Tpxqu2RkeBkibJuTQHe5uqrfu2iyDlJvrwab3wO1UTUBartPojyxKR01tL8I9EHrC2 WQNvxCQpaWgEPQi85aZ6RnMNtuvXhsj3qg+ZKS3meeGEy7LuecSjFHI7KaaHXKwIkdPj e/nm35XphPLKj+MNMJMqXJI8gwl5pFChfEA/Qkz3X3LYSdu9lq+ar18v0Yy6PiM3YfDI O7NZtB2oJdynKgYMLYdfj7sJXMwnbjbbrkp6MyvXprSK+DjwiE8gLPRFZFbU/G2Ydt94 hq7Qu29UtLFG0VBRgVDbwWMO1EDC1gatbgF35zTQFXkheXNTOyNHm8olMmKfPyQt8I0M bPFw== X-Received: by 10.14.246.68 with SMTP id p44mr605220eer.72.1390384930677; Wed, 22 Jan 2014 02:02:10 -0800 (PST) Received: from dhcppc1 (dsl-trebrasgw2-58c0d8-67.dhcp.inet.fi. [88.192.216.67]) by mx.google.com with ESMTPSA id x1sm21711187een.17.2014.01.22.02.02.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2014 02:02:10 -0800 (PST) Date: Wed, 22 Jan 2014 12:02:07 +0200 From: Reinis Danne To: gentoo-science@lists.gentoo.org Subject: Re: [gentoo-science] blas selection in lapack-reference Message-ID: <20140122100207.GE13149@dhcppc1> Mail-Followup-To: gentoo-science@lists.gentoo.org References: <589fdf2e04e21f3fad949727e20880b6@slingshot.co.nz> <20140121194748.78c0f91f.strogdon@d.umn.edu> <20140122094732.GD13149@dhcppc1> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-science@lists.gentoo.org Reply-to: gentoo-science@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Archives-Salt: d462ed51-7eaf-410f-9352-9c8ad7e91763 X-Archives-Hash: 1f7c3c0ec6ff468e9e22eea5bc0dc72e 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 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