[gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[Nuno Silva]

On 2020-04-08, gevisz wrote:

> I've tried to install julia-1.4.0 but one of its dependencies, namely,
> sci-libs/spqr-1.2.3-r1 failed to emerge with the following error message:
>
> * Failed Running automake !
>  *
>  * Include in your bugreport the contents of:
>  *
>  *   /var/tmp/portage/sci-libs/spqr-1.2.3-r1/temp/automake.out
[...]
> I tried to look into the automake.out file mentioned above but it even
> does not exists (or empty).



Could this be bug 586582? (But that one has an automake.out?)

https://bugs.gentoo.org/show_bug.cgi?id=586582

And see also: https://bugs.gentoo.org/show_bug.cgi?id=627094

From a quick read, it looks like there is no fix for 1.2.3-r1, but that
the plan is to drop 1.2.3-r1 if 2.0.9 works.


-- 
Nuno Silva

[gentoo-user] sci-libs/spqr-1.2.3-r1 failed to emerge

[gevisz]

[-- Attachment #1: Type: text/plain, Size: 7621 bytes --]

I've tried to install julia-1.4.0 but one of its dependencies, namely,
sci-libs/spqr-1.2.3-r1 failed to emerge with the following error message:

* Failed Running automake !
 *
 * Include in your bugreport the contents of:
 *
 *   /var/tmp/portage/sci-libs/spqr-1.2.3-r1/temp/automake.out

 * ERROR: sci-libs/spqr-1.2.3-r1::gentoo failed (prepare phase):
 *   Failed Running automake !
 *
 * Call stack:
 *     ebuild.sh, line  125:  Called src_prepare
 *   environment, line 2324:  Called autotools-utils_src_prepare
 *   environment, line  512:  Called eautoreconf
 *   environment, line  830:  Called eautomake
 *   environment, line  784:  Called autotools_run_tool 'automake'
'--add-missing' '--copy' '--foreign' '--force-missing'
 *   environment, line  648:  Called die
 * The specific snippet of code:
 *           die "Failed Running $1 !";
 *
 * If you need support, post the output of `emerge --info
'=sci-libs/spqr-1.2.3-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=sci-libs/spqr-1.2.3-r1::gentoo'`.
 * The complete build log is located at
'/var/log/portage/sci-libs:spqr-1.2.3-r1:20200408-071552.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sci-libs/spqr-1.2.3-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/sci-libs/spqr-1.2.3-r1/work/SPQR'
 * S: '/var/tmp/portage/sci-libs/spqr-1.2.3-r1/work/SPQR'

>>> Failed to emerge sci-libs/spqr-1.2.3-r1, Log file:  '/var/log/portage/sci-libs:spqr-1.2.3-r1:20200408-071552.log'

I tried to look into the automake.out file mentioned above but it even
does not exists (or empty).

The log file is attached. The output of emerge --info
'=sci-libs/spqr-1.2.3-r1::gentoo' is as follows:
# emerge --info '=sci-libs/spqr-1.2.3-r1::gentoo'
Portage 2.3.89 (python 3.6.10-final-0,
default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.29-r7,
4.19.86-gentoo+ x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.19.86-gentoo+-x86_64-AMD_Phenom-tm-_II_X4_945_Processor-with-gentoo-2.6
KiB Mem:    20554020 total,  12064808 free
KiB Swap:   11718652 total,  11718652 free
Timestamp of repository gentoo: Tue, 07 Apr 2020 00:45:01 +0000
sh bash 4.4_p23-r1
ld GNU ld (Gentoo 2.32 p2) 2.32.0
app-shells/bash:          4.4_p23-r1::gentoo
dev-lang/perl:            5.30.1::gentoo
dev-lang/python:          2.7.17-r2::gentoo, 3.6.10-r1::gentoo, 3.7.7-r1::gentoo
dev-util/cmake:           3.16.5::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/openrc:          0.42.1::gentoo
sys-apps/sandbox:         2.13::gentoo
sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.16.1-r1::gentoo
sys-devel/binutils:       2.32-r1::gentoo, 2.33.1-r1::gentoo
sys-devel/gcc:            9.2.0-r2::gentoo
sys-devel/gcc-config:     2.2.1::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 5.4::gentoo (virtual/os-headers)
sys-libs/glibc:           2.29-r7::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: webrsync
    sync-uri: "http://mirror.netcologne.de/gentoo/"
    priority: -1000
    sync-webrsync-verify-signature: yes

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb/symbols/ /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--ask --fail-clean"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT
PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME
XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-march=native -O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs
config-protect-if-modified distlocks ebuild-locks fail-clean
fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news
parallel-fetch pid-sandbox preserve-libs protect-owned
qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn
unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync
webrsync-gpg"
FFLAGS="-march=native -O2 -pipe"
GENTOO_MIRRORS="http://mirror.netcologne.de/gentoo/
https://mirrors.lug.mtu.edu/gentoo http://de-mirror.org/gentoo/
http://www.mirrorservice.org/sites/distfiles.gentoo.org/
http://distfiles.gentoo.org
http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS=""
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--omit-dir-times --compress --force --whole-file --delete --stats
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local
--exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa amd64 berkdb bzip2 cairo cdda cdr cli
crypt cups dbus dri dts dvd dvdr encode exif flac fortran gdbm gif gpm
gtk iconv icu jpeg lcms ldap libnotify libtirpc mad mng mp3 mp4 mpeg
multilib ncurses nptl ocamlopt ogg opengl openmp pango pcre pdf png
ppds qt5 readline sdl seccomp smp spell split-usr ssl
startup-notification svg tcpd tiff truetype udev udisks unicode upower
usb vorbis wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64"
ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem
bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801
hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx
via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core
socache_shmcb unixd actions alias auth_basic authn_alias authn_anon
authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache cgi
cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter
file_cache filter headers include info log_config logio mem_cache mime
mime_magic negotiation rewrite setenvif speling status unique_id
userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words"
COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog"
CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a"
ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18
garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom
oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq
superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc"
INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text"
LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer"
OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2"
POSTGRES_TARGETS="postgres10 postgres11"
PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6"
RUBY_TARGETS="ruby24 ruby25" USERLAND="GNU" VIDEO_CARDS="radeon r600"
XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset
ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat
logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL,
PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS,
PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

[3]+  Done                    gvim
/var/tmp/portage/sci-libs/spqr-1.2.3-r1/temp/automake.out

[-- Attachment #2: sci-libs:spqr-1.2.3-r1:20200408-071552.log --]
[-- Type: application/octet-stream, Size: 2717 bytes --]

Re: [gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

On Wed, 8 Apr 2020 17:45:25 +0300, gevisz wrote:
> Anyway, it did not helped to emerge julia because of the following:
> 
> # emerge julia
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild     UD ] sci-libs/cholmod-2.1.2 [3.0.13] USE="-lapack* -metis%
> -minimal%"
> [ebuild  N     ] sci-libs/umfpack-5.6.2  USE="cholmod -doc -static-libs"
> [ebuild  N    ~] dev-lang/julia-1.4.0-r1
> 
> !!! Multiple package instances within a single package slot have been
> pulled !!! into the dependency graph, resulting in a slot conflict:
> 
> sci-libs/cholmod:0
> 
>   (sci-libs/cholmod-3.0.13:0/0::gentoo, installed) USE="lapack
> matrixops modify partition -cuda -doc -static-libs" ABI_X86="(64)"
> pulled in by
>     >=sci-libs/cholmod-2[lapack,partition?] required by  
> (sci-libs/spqr-2.0.9:0/0::gentoo, installed) USE="-doc -partition
> -static-libs -tbb" ABI_X86="(64)"
>                                 ^^^^^^^^^^

Try setting USE=partition for sqpr


-- 
Neil Bothwick

No trees were harmed in the sending of this message. However, a large
number of electrons were terribly inconvenienced.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[gevisz]

ср, 8 апр. 2020 г. в 13:29, Nuno Silva <nunojsilva@ist.utl.pt>:
>
> On 2020-04-08, gevisz wrote:
>
> > I've tried to install julia-1.4.0 but one of its dependencies, namely,
> > sci-libs/spqr-1.2.3-r1 failed to emerge with the following error message:
> >
> > * Failed Running automake !
> >  *
> >  * Include in your bugreport the contents of:
> >  *
> >  *   /var/tmp/portage/sci-libs/spqr-1.2.3-r1/temp/automake.out
> [...]
> > I tried to look into the automake.out file mentioned above but it even
> > does not exists (or empty).
>
>
>
> Could this be bug 586582? (But that one has an automake.out?)
>
> https://bugs.gentoo.org/show_bug.cgi?id=586582
>
> And see also: https://bugs.gentoo.org/show_bug.cgi?id=627094
>
> From a quick read, it looks like there is no fix for 1.2.3-r1, but that
> the plan is to drop 1.2.3-r1 if 2.0.9 works.
>
Yes, unmasking
=sci-libs/spqr-2.0.9
which lead to unmasking
=sci-libs/cholmod-3.0.13
=sci-libs/amd-2.4.6
=sci-libs/colamd-2.9.6
=sci-libs/camd-2.4.6
=sci-libs/ccolamd-2.9.6
=sci-libs/suitesparseconfig-5.4.0
=sci-libs/metis-5.1.0-r2
allowed emerging spqr-2.0.9.

Re: [gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[gevisz]

ср, 8 апр. 2020 г. в 17:19, gevisz <gevisz@gmail.com>:
>
> ср, 8 апр. 2020 г. в 13:29, Nuno Silva <nunojsilva@ist.utl.pt>:
> >
> > On 2020-04-08, gevisz wrote:
> >
> > > I've tried to install julia-1.4.0 but one of its dependencies, namely,
> > > sci-libs/spqr-1.2.3-r1 failed to emerge with the following error message:
> > >
> > > * Failed Running automake !
> > >  *
> > >  * Include in your bugreport the contents of:
> > >  *
> > >  *   /var/tmp/portage/sci-libs/spqr-1.2.3-r1/temp/automake.out
> > [...]
> > > I tried to look into the automake.out file mentioned above but it even
> > > does not exists (or empty).
> >
> >
> >
> > Could this be bug 586582? (But that one has an automake.out?)
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=586582
> >
> > And see also: https://bugs.gentoo.org/show_bug.cgi?id=627094
> >
> > From a quick read, it looks like there is no fix for 1.2.3-r1, but that
> > the plan is to drop 1.2.3-r1 if 2.0.9 works.
> >
> Yes, unmasking
> =sci-libs/spqr-2.0.9
> which lead to unmasking
> =sci-libs/cholmod-3.0.13
> =sci-libs/amd-2.4.6
> =sci-libs/colamd-2.9.6
> =sci-libs/camd-2.4.6
> =sci-libs/ccolamd-2.9.6
> =sci-libs/suitesparseconfig-5.4.0
> =sci-libs/metis-5.1.0-r2
> allowed emerging spqr-2.0.9.

Anyway, it did not helped to emerge julia because of the following:

# emerge julia

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     UD ] sci-libs/cholmod-2.1.2 [3.0.13] USE="-lapack* -metis%
-minimal%"
[ebuild  N     ] sci-libs/umfpack-5.6.2  USE="cholmod -doc -static-libs"
[ebuild  N    ~] dev-lang/julia-1.4.0-r1

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sci-libs/cholmod:0

  (sci-libs/cholmod-3.0.13:0/0::gentoo, installed) USE="lapack
matrixops modify partition -cuda -doc -static-libs" ABI_X86="(64)"
pulled in by
    >=sci-libs/cholmod-2[lapack,partition?] required by
(sci-libs/spqr-2.0.9:0/0::gentoo, installed) USE="-doc -partition
-static-libs -tbb" ABI_X86="(64)"
                                ^^^^^^^^^^

  (sci-libs/cholmod-2.1.2:0/0::gentoo, ebuild scheduled for merge)
USE="(-cuda) -doc -lapack -metis -minimal -static-libs" ABI_X86="(64)"
pulled in by
    >=sci-libs/cholmod-2[-minimal] required by
(sci-libs/umfpack-5.6.2:0/0::gentoo, ebuild scheduled for merge)
USE="cholmod -doc -static-libs" ABI_X86="(64)"
                         ^^^^^^^^


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.

Re: [gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[gevisz]

ср, 8 апр. 2020 г. в 16:00, Neil Bothwick <neil@digimed.co.uk>:
>
> On Wed, 8 Apr 2020 17:45:25 +0300, gevisz wrote:
> > Anyway, it did not helped to emerge julia because of the following:
> >
> > # emerge julia
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild     UD ] sci-libs/cholmod-2.1.2 [3.0.13] USE="-lapack* -metis%
> > -minimal%"
> > [ebuild  N     ] sci-libs/umfpack-5.6.2  USE="cholmod -doc -static-libs"
> > [ebuild  N    ~] dev-lang/julia-1.4.0-r1
> >
> > !!! Multiple package instances within a single package slot have been
> > pulled !!! into the dependency graph, resulting in a slot conflict:
> >
> > sci-libs/cholmod:0
> >
> >   (sci-libs/cholmod-3.0.13:0/0::gentoo, installed) USE="lapack
> > matrixops modify partition -cuda -doc -static-libs" ABI_X86="(64)"
> > pulled in by
> >     >=sci-libs/cholmod-2[lapack,partition?] required by
> > (sci-libs/spqr-2.0.9:0/0::gentoo, installed) USE="-doc -partition
> > -static-libs -tbb" ABI_X86="(64)"
> >                                 ^^^^^^^^^^
>
> Try setting USE=partition for sqpr

Unfortunately, it did not helped.

Re: [gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[Michael Orlitzky]

On 4/8/20 11:01 AM, gevisz wrote:
> 
> Unfortunately, it did not helped.
> 

Before you do anything else, keyword all of the latest suitesparse
components:

  ~sci-libs/suitesparseconfig-5.4.0
  ~sci-libs/amd-2.4.6
  ~sci-libs/btf-1.2.6
  ~sci-libs/camd-2.4.6
  ~sci-libs/ccolamd-2.9.6
  ~sci-libs/cholmod-3.0.13
  ~sci-libs/colamd-2.9.6
  ~sci-libs/cxsparse-3.2.0
  ~sci-libs/klu-1.3.9
  ~sci-libs/ldl-2.2.6
  ~sci-libs/spqr-2.0.9
  ~sci-libs/umfpack-5.7.9

Those aren't the latest upstream releases, but at least they work, which
is more than I can say for the stable versions.

The other thing you should be aware of is that dev-lang/julia is, from a
software engineering point of view, an absolute trainwreck (upstream,
not the Gentoo maintainer's fault). Your experience so far is going to
be typical, I fear.

Re: [gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[gevisz]

ср, 8 апр. 2020 г. в 18:13, Michael Orlitzky <mjo@gentoo.org>:
>
> On 4/8/20 11:01 AM, gevisz wrote:
> >
> > Unfortunately, it did not helped.
> >
>
> Before you do anything else, keyword all of the latest suitesparse
> components:
>
>   ~sci-libs/suitesparseconfig-5.4.0
>   ~sci-libs/amd-2.4.6
>   ~sci-libs/btf-1.2.6
>   ~sci-libs/camd-2.4.6
>   ~sci-libs/ccolamd-2.9.6
>   ~sci-libs/cholmod-3.0.13
>   ~sci-libs/colamd-2.9.6
>   ~sci-libs/cxsparse-3.2.0
>   ~sci-libs/klu-1.3.9
>   ~sci-libs/ldl-2.2.6
>   ~sci-libs/spqr-2.0.9
>   ~sci-libs/umfpack-5.7.9
>
> Those aren't the latest upstream releases, but at least they work, which
> is more than I can say for the stable versions.
>
> The other thing you should be aware of is that dev-lang/julia is, from a
> software engineering point of view, an absolute trainwreck (upstream,
> not the Gentoo maintainer's fault). Your experience so far is going to
> be typical, I fear.

After I added all these files to the
/etc/portage/package.accept_keywords/julia file,
julia finally emerged. Thank you. However, I am affraid what will be
when I try to
update my Gentoo system in a month or so.

Re: [gentoo-user] sci-libs/spqr-1.2.3-r1 failed to emerge

[David Haller]

Hello,

On Wed, 08 Apr 2020, gevisz wrote:
>I've tried to install julia-1.4.0 but one of its dependencies, namely,
>sci-libs/spqr-1.2.3-r1 failed to emerge with the following error message:
>
>* Failed Running automake !
> *
> * Include in your bugreport the contents of:
> *
> *   /var/tmp/portage/sci-libs/spqr-1.2.3-r1/temp/automake.out

The patch spqr-1.2.3-autotools.patch is broken, it includes two
AM_INIT_AUTOMAKE lines in configure.ac:

====
[..]
--- configure.ac        1969-12-31 19:00:00.000000000 -0500
+++ configure.ac        2009-10-22 23:42:32.000000000 -0400
@@ -0,0 +1,55 @@
+AC_PREREQ(2.59)
+AC_INIT(spqr, 1.2, davis@cise.ufl.edu)
+AM_INIT_AUTOMAKE([foreign])
+AC_CONFIG_SRCDIR([Source/spqr_kernel.cpp])
+AM_INIT_AUTOMAKE([foreign])
[..]
====

Deleting the first (and adjusting the patchlength: '@@ -0,0 +1,54 @@')
and it works.

HTH,
-dnh

-- 
> Write the code like you are going to lose your memory in six months.
Most people would say I write code like I've already lost my mind.
Is that the same thing?                         -- Randal L. Schwartz

Re: [gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[gevisz]

ср, 8 апр. 2020 г. в 19:31, gevisz <gevisz@gmail.com>:
>
> ср, 8 апр. 2020 г. в 18:13, Michael Orlitzky <mjo@gentoo.org>:
> >
> > On 4/8/20 11:01 AM, gevisz wrote:
> > >
> > > Unfortunately, it did not helped.
> > >
> >
> > Before you do anything else, keyword all of the latest suitesparse
> > components:
> >
> >   ~sci-libs/suitesparseconfig-5.4.0
> >   ~sci-libs/amd-2.4.6
> >   ~sci-libs/btf-1.2.6
> >   ~sci-libs/camd-2.4.6
> >   ~sci-libs/ccolamd-2.9.6
> >   ~sci-libs/cholmod-3.0.13
> >   ~sci-libs/colamd-2.9.6
> >   ~sci-libs/cxsparse-3.2.0
> >   ~sci-libs/klu-1.3.9
> >   ~sci-libs/ldl-2.2.6
> >   ~sci-libs/spqr-2.0.9
> >   ~sci-libs/umfpack-5.7.9
> >
> > Those aren't the latest upstream releases, but at least they work, which
> > is more than I can say for the stable versions.
> >
> > The other thing you should be aware of is that dev-lang/julia is, from a
> > software engineering point of view, an absolute trainwreck (upstream,
> > not the Gentoo maintainer's fault). Your experience so far is going to
> > be typical, I fear.
>
> After I added all these files to the
> /etc/portage/package.accept_keywords/julia file,
> julia finally emerged. Thank you. However, I am affraid what will be
> when I try to update my Gentoo system in a month or so.

A small addition: I've just noticed that I've managed to emerge only
julia-1.3.0;
julia-1.4.0-r1 still fails to be emerged (at a compile phase).

[gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[Nuno Silva]

On 2020-04-09, gevisz wrote:

> ср, 8 апр. 2020 г. в 19:31, gevisz <gevisz@gmail.com>:
>>
>> ср, 8 апр. 2020 г. в 18:13, Michael Orlitzky <mjo@gentoo.org>:
>> >
>> > The other thing you should be aware of is that dev-lang/julia is, from a
>> > software engineering point of view, an absolute trainwreck (upstream,
>> > not the Gentoo maintainer's fault). Your experience so far is going to
>> > be typical, I fear.
>>
>> After I added all these files to the
>> /etc/portage/package.accept_keywords/julia file,
>> julia finally emerged. Thank you. However, I am affraid what will be
>> when I try to update my Gentoo system in a month or so.
>
> A small addition: I've just noticed that I've managed to emerge only
> julia-1.3.0;
> julia-1.4.0-r1 still fails to be emerged (at a compile phase).

What errors?

There is bug 716434[1] where julia fails because it tries to download
more tarballs (yes, during compilation). An ebuild change was made to
address this, so it might be worth syncing the tree and trying to emerge
again.

[1] https://bugs.gentoo.org/show_bug.cgi?id=716434

-- 
Nuno Silva

Re: [gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[gevisz]

чт, 9 апр. 2020 г. в 10:32, Nuno Silva <nunojsilva@ist.utl.pt>:
>
> On 2020-04-09, gevisz wrote:
>
> > ср, 8 апр. 2020 г. в 19:31, gevisz <gevisz@gmail.com>:
> >>
> >> ср, 8 апр. 2020 г. в 18:13, Michael Orlitzky <mjo@gentoo.org>:
> >> >
> >> > The other thing you should be aware of is that dev-lang/julia is, from a
> >> > software engineering point of view, an absolute trainwreck (upstream,
> >> > not the Gentoo maintainer's fault). Your experience so far is going to
> >> > be typical, I fear.
> >>
> >> After I added all these files to the
> >> /etc/portage/package.accept_keywords/julia file,
> >> julia finally emerged. Thank you. However, I am affraid what will be
> >> when I try to update my Gentoo system in a month or so.
> >
> > A small addition: I've just noticed that I've managed to emerge only
> > julia-1.3.0;
> > julia-1.4.0-r1 still fails to be emerged (at a compile phase).
>
> What errors?
>
> There is bug 716434[1] where julia fails because it tries to download
> more tarballs (yes, during compilation). An ebuild change was made to
> address this, so it might be worth syncing the tree and trying to emerge
> again.

Thank you. I will try.

> [1] https://bugs.gentoo.org/show_bug.cgi?id=716434

Re: [gentoo-user] Re: sci-libs/spqr-1.2.3-r1 failed to emerge

[gevisz]

чт, 9 апр. 2020 г. в 10:32, Nuno Silva <nunojsilva@ist.utl.pt>:
>
> On 2020-04-09, gevisz wrote:
>
> > ср, 8 апр. 2020 г. в 19:31, gevisz <gevisz@gmail.com>:
> >>
> >> ср, 8 апр. 2020 г. в 18:13, Michael Orlitzky <mjo@gentoo.org>:
> >> >
> >> > The other thing you should be aware of is that dev-lang/julia is, from a
> >> > software engineering point of view, an absolute trainwreck (upstream,
> >> > not the Gentoo maintainer's fault). Your experience so far is going to
> >> > be typical, I fear.
> >>
> >> After I added all these files to the
> >> /etc/portage/package.accept_keywords/julia file,
> >> julia finally emerged. Thank you. However, I am affraid what will be
> >> when I try to update my Gentoo system in a month or so.
> >
> > A small addition: I've just noticed that I've managed to emerge only
> > julia-1.3.0;
> > julia-1.4.0-r1 still fails to be emerged (at a compile phase).
>
> What errors?
>
> There is bug 716434[1] where julia fails because it tries to download
> more tarballs (yes, during compilation). An ebuild change was made to
> address this, so it might be worth syncing the tree and trying to emerge
> again.
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=716434

After updating the portgage repository, julia-1.4.0-r1 was
successfully compiled. Thank you.