Octave won't run since a lib is missing.
I can re-emerge it without problems, but the problem still
persist. The lib is there but it has a different version.
Anyone know what this is about ?
$ ldd /usr/bin/octave-cli-4.2.2 | grep not
liblapack.so.0 => not found
$ ls -l /usr/lib64/liblapac
On Thursday, 6 February 2020 08:28:05 GMT k...@aspodata.se wrote:
> Octave won't run since a lib is missing.
> I can re-emerge it without problems, but the problem still
> persist. The lib is there but it has a different version.
>
> Anyone know what this is about ?
>
> $ ldd /usr/bin/octave-cli-
Mick:
...
> I don't have these packages on my systems to check, but does 'eselect lapack
> list' reveal anything amiss?
...
$ eselect lapack list
Available LAPACK (lib) candidates:
(none found)
Available LAPACK (lib64) candidates:
(none found)
$ eselect blas list
Available BLAS/CBLAS (lib) ca
On Thursday, 6 February 2020 13:44:22 GMT k...@aspodata.se wrote:
> Mick:
> ...
>
> > I don't have these packages on my systems to check, but does 'eselect
> > lapack list' reveal anything amiss?
>
> ...
>
> $ eselect lapack list
> Available LAPACK (lib) candidates:
> (none found)
> Available
Sounds like a ebuild dependency bug, or possibly a bad mix of stable and
non-stable packages that haven't been sussed out fully.
Not a good long-term solution, especially if you're forgetful like me, but
as a test you might try creating a symlink for libapack.so.0 pointing to
libapack.so.3 and see
Mick:
...
> Unless someone shows up with more knowledge on the specifics it would be
> worth
> posting a bug, or contacting the maintainer for suggestions.
...
Since octave compiles/emerges successfully, there are no log files left.
Can I tell emerge to not remove the build directory ?
Regards,
Mark:
> Sounds like a ebuild dependency bug, or possibly a bad mix of stable and
> non-stable packages that haven't been sussed out fully.
>
> Not a good long-term solution, especially if you're forgetful like me, but
> as a test you might try creating a symlink for libapack.so.0 pointing to
> lib
On Thu, 6 Feb 2020 17:33:25 +0100 (CET), k...@aspodata.se wrote:
> > Unless someone shows up with more knowledge on the specifics it would
> > be worth posting a bug, or contacting the maintainer for suggestions.
> >
> ...
>
> Since octave compiles/emerges successfully, there are no log files
On 2020-02-05 22:14, Matt Connell wrote:
> I know that gentoo-sources tracks on the most current LTS kernel
> release, currently 4.19.97.
5.4 has just become the newest LTS.
--
Ian
On 2020-02-06 09:56, Mick wrote:
> Otherwise the latest sci-libs/lapack is 3.8.0, so your links above look
> correct as far as I can tell.
Note that sci-libs/lapack and sci-libs/lapack-reference are 2 distinct
packages. The OP presumably has the latter.
Both of them existing may be the real bu
On Sun, 5 Jan 2020 07:48:04 - (UTC)
Martin Vaeth wrote:
> This looks like a bug in the perl distribution to me:
>
> man perl5300delta
>
> claims "Locale::Codes has been upgraded from version 3.56 to 3.57." and
>
> man perl5301delta
>
> neither mentions "Locale" nor "Codes", yet the whole
Am Donnerstag, 6. Februar 2020, 18:45:12 CET schrieb Ian Zimmerman:
> On 2020-02-06 09:56, Mick wrote:
> > Otherwise the latest sci-libs/lapack is 3.8.0, so your links above look
> > correct as far as I can tell.
>
> Note that sci-libs/lapack and sci-libs/lapack-reference are 2 distinct
> packages.
200206 Ian Zimmerman wrote:
> On 2020-02-06 09:56, Mick wrote:
>> Otherwise the latest sci-libs/lapack is 3.8.0,
> so your links above look correct as far as I can tell.
> Note that sci-libs/lapack and sci-libs/lapack-reference
> are 2 distinct packages. The OP presumably has the latter.
> Both of
Ian:
> On 2020-02-06 09:56, Mick wrote:
>
> > Otherwise the latest sci-libs/lapack is 3.8.0, so your links above look
> > correct as far as I can tell.
>
> Note that sci-libs/lapack and sci-libs/lapack-reference are 2 distinct
> packages. The OP presumably has the latter.
>
> Both of them exis
> == Upstream has unbundled this and migrated it to be a "CPAN only" dep.
>
> Op needs to request an addition of dev-perl/Locale-Codes , which
> provides both Locale::Codes and Locale::Language
commit 5e9859f72c23a21b16dc72053cc6077b33fc77ce
Author: Andreas K. Hüttel
AuthorDate: Wed Jan 8 12
On Sat, 2020-02-01 at 17:08 -0500, Jack wrote:
> CAUTION: This is an EXTERNAL email. Do not click links or open
> attachments unless you recognize the sender and know the content is
> safe.
>
> Relying on the collective experience and advice of the group here.
>
> As may be obvious to many of
On 2020.02.06 17:36, Laurence Perkins wrote:
On Sat, 2020-02-01 at 17:08 -0500, Jack wrote:
CAUTION: This is an EXTERNAL email. Do not click links or open
attachments unless you recognize the sender and know the content is
safe.
I didn't write that. :-)
>
> Relying on the collective experie
On 2/6/20 3:36 PM, Laurence Perkins wrote:
Sure you can set up just a simple email server
Having run a personal email server for 20 years, including all
contemporary hygiene measures, I don't think "simple" and "email server"
go together any more.
I can rattle off most of what I'm doing in
On 2020-02-06 11:40, Ian Zimmerman wrote:
> 5.4 has just become the newest LTS.
I see that now. But my original question still stands as to why the
stable version of gentoo-sources is consistently a few versions behind
the latest LTS release.
On Thu, 06 Feb 2020 19:00:09 -0500,
Grant Taylor wrote:
>
> On 2/6/20 3:36 PM, Laurence Perkins wrote:
> > Sure you can set up just a simple email server
>
> Having run a personal email server for 20 years, including all
> contemporary hygiene measures, I don't think "simple" and "email
> serve
That article you linked to is about a variant of linux, "rt". And as it
looks they didn't update their branch since the release of 4.19.100-r41.
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.19-rt
linux is at 4.19.102 now...
AFAIR the Gentoo kernel team knows wha
21 matches
Mail list logo
