Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 201321

Summary: sci-mathematics/sage (new ebuild)
Product: Gentoo Linux Reporter: Daniel Gulotta <dgulotta>
Component: New packagesAssignee: Default Assignee for New Packages <maintainer-wanted>
Status: CONFIRMED ---    
Severity: enhancement CC: aghitza, andrija.prcic, anton.kochkov, artjom.simon, bitte.keine.werbung.einwerfen, buchner.johannes, burcin, cbm, ccordoba12, chris.burroughs, christian.kotz, ckonstanski, coldwind, cruzki123, ephemient, flophousejoe-gentoo-bugzilla-ehx, frp.bissey, gunix, handgranaten-herbert, igor.poboiko, ilmostro7, jlp.bugs, lssndrbarbieri, meheschmid, mjo, mmokrejs, orzel, rb6, sci-mathematics, SebastianLuther, shiningarcanine, strogdon, thomas.pani, tim, timmy8765, usefuljunk, v_2e, yamadharma, Zeliboba
Priority: High Keywords: EBUILD
Version: unspecified   
Hardware: All   
OS: Linux   
URL: http://www.sagemath.org
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 49282, 88093, 100123, 120794, 220521, 221771, 227803, 230423, 230427, 230429, 230431, 230433, 230437, 230439, 230441, 230447, 230449, 230457, 232014, 232033, 293381, 293383, 293969, 301691, 446698    
Bug Blocks:    
Attachments: sage-2.8.15.ebuild
sage-2.8.15-fortran-symlink.patch
sage-2.8.15.ebuild
ebuild for sage-2.10
needed for sage-fortran setup.
needed for sage-fortran setup (as well).
patch the sage dependency tree to remove packages provided by portage
patch the prereq file.
patch sage internal scipy to find portage installed atlas/lapack
patch sage internal scipy_sandbox to find portage installed atlas/lapack
patch cvxopt internal package to remove dependency on libf77blas.
update ebuild to sage-2.10.1
patch to deps and prereq-0.3-install for sage-2.10.1
updated patch to the internal copy of scipy
updated patch to the internal copy of scipy_sandbox
2.10.1 ebuild revision to include gmp patch
combined gmp patches from the forum
sage-4.1.2.ebuild
revised ebuild for 4.2 with patch
spkg patch to get rid of sandbox violiation from ecm
tentative patch for the ldconfig sandbox violation.
new ebuild still failing because of sandbox violation error
fixes a typo in ecm spkg
fix for pari spkg
Silly me forgot to make it EAPI=2
revised ecm patch
revised pari patch
revision to pari-2.3.3.p5.patch
sage startup log
ipy_profile_sage

Description Daniel Gulotta 2007-12-05 06:00:12 UTC
SAGE is a Python based computer algebra system.

Reproducible: Always
Comment 1 Daniel Gulotta 2007-12-05 06:00:53 UTC
Created attachment 137773 [details]
sage-2.8.15.ebuild
Comment 2 François Bissey 2007-12-05 20:13:23 UTC
You should indicate that your ebuild is for the binary version.
I took an interest in sage recently looking at building from sources
(for arches other than x86 you know). The main problem is that it
come with the sources for stuff that is already in portage and has a
very bad building system in that you cannot use stuff that you already
have installed at _all_. It is fully "integrated" with its own internal 
packaging system. 
Comment 3 Daniel Gulotta 2007-12-05 21:26:03 UTC
This is the source version.  I'm compiling it on a ppc machine right now.

I agree with you that the SAGE build system is very poorly designed.  I have to admit, it seems like it would be a huge pain to do security fixes.
Comment 4 François Bissey 2007-12-05 22:42:13 UTC
My apologies, I misread the ebuild - it looked so short.
Not only security but space. I haven't installed it on my ppc machine
because I was lacking space-that I probably wouldn't if it was using the
system maxima, mpfr and so on.
I may give your ebuild a go later next week then.
Comment 5 Daniel Gulotta 2007-12-06 00:54:22 UTC
SAGE finished compiling on my laptop but it doesn't seem to work.  The interactive python shell starts up but the SAGE modules are failing to load.  I'm not really sure why it works on my workstation but not on my laptop, but I'll try to figure it out.
Comment 6 cruzki 2007-12-08 13:09:03 UTC
I just install and I have the following error

/usr/bin/env: sage.bin: No existe el fichero o el directorio
/opt/sage/local/bin/sage-sage: /opt/sage/local/bin/sage-ipython: sage.bin:

All links in /opt/sage/local/bin/sage-sage are broken. Where it is supposed have to link  sage.bin?

Comment 7 François Bissey 2007-12-08 18:53:49 UTC
I am not sure about the sed line in the ebuild.
If we follow the install instructions we want to change
SAGE_ROOT="....." (and the dots are really in that file) by
SAGE_ROOT="/opt/sage/"
And that's it. What do you have in /opt/sage/sage?
The more I look at the sage script the more I think it doesn't do 
the right thing.
Comment 8 Daniel Gulotta 2007-12-08 21:20:33 UTC
cruzki: I just want to make sure, you are running either /opt/bin/sage or /opt/sage/sage, correct?  On my computer, I don't get that error because /opt/sage/local/bin is being added to PATH, but I haven't figured out where this happens yet.

Francois Bissey: /opt/sage/sage is one of the files that sed is acting on.  SAGE_ROOT is being set to /opt/sage.
Comment 9 Daniel Gulotta 2007-12-09 03:13:08 UTC
It seems that the reason SAGE isn't working on my laptop is that the install script is running gfortran from a symlink, which gfortran doesn't like.  I'm not sure why it worked on my workstation.
Comment 10 Daniel Gulotta 2007-12-09 04:43:12 UTC
Created attachment 138064 [details, diff]
sage-2.8.15-fortran-symlink.patch

This should fix the problem with the fortran symlinks.
Comment 11 Daniel Gulotta 2007-12-09 04:44:40 UTC
Created attachment 138066 [details]
sage-2.8.15.ebuild
Comment 12 cruzki 2007-12-09 13:29:23 UTC
@Daniel Gulotta

With both options I have the same error. Even if I add /opt/sage/local/bin to PATH I still have the same error.
Comment 13 Daniel Gulotta 2007-12-09 19:16:23 UTC
cruzki: Could you check if there are any error messages at the end of /opt/sage/install.log?
Comment 14 Randall Wald 2007-12-10 06:04:21 UTC
Current ebuild fails to compile for me, with the following error:

configure: error: ABI=amd64 is not among the following valid choices: 64 32
Failed to configure.

I'm using an amd64-based system (nocona, to be specific), so that's probably why.
Comment 15 Daniel Gulotta 2007-12-10 07:44:22 UTC
It seems that gmp handles the ABI variable in a nonstandard way.  There is a workaround for it in the gmp ebuild.  Things like this lead me to believe that the only way to write an ebuild for SAGE that anyone is going to want to maintain is to make it use packages that are already in Portage as much as possible.  There is a similar effort going on right now for Debian (http://groups.google.com/group/debian-sage/).  I'm not sure that I have the time or the patience to attempt this, but I am considering it.  Of course, any help would be greatly appreciated.
Comment 16 cruzki 2007-12-10 09:35:21 UTC
I have the same problem as Randall Wald.
Comment 17 François Bissey 2008-01-20 22:54:46 UTC
Created attachment 141407 [details]
ebuild for sage-2.10

This is an ebuild for the latest version of sage, sage moves very fast so it
will be superceded in about 2 weeks.
This ebuild start using basic stuff provided by portage rather than internally.
It's baby steps - but people who don't want to rebuild atlas because they already
have it on their system and it takes forever to tune will be happy. Note that
sage-2.10.1 will provide a way to do that out of the box.
I savaged their fortran package to impose gfortran everywhere. 
It needs the following files in the "files" folder:
which_fortran
sage_fortran
prereq.patch
deps.patch
scipy.patch
scipy_sandbox.patch
cvxopt.patch

Pulling other things out will require attention and probably the set up 
of an overlay. gmp for example needs a patch. sage is picky about versions:
maxima-5.13 is required, 5.14 cause 4 tests (sage -testall) to fail.
This version fails on one test called qqbar.py, don't know why yet (gsl1.10
instead of 1.9, dodgy atlas/lapack? -if you test with gsl-1.9 and it pass
the test let me know.)
Comment 18 François Bissey 2008-01-20 22:56:25 UTC
Created attachment 141408 [details]
needed for sage-fortran setup.
Comment 19 François Bissey 2008-01-20 22:57:17 UTC
Created attachment 141410 [details]
needed for sage-fortran setup (as well).
Comment 20 François Bissey 2008-01-20 22:58:56 UTC
Created attachment 141412 [details, diff]
patch the sage dependency tree to remove packages provided by portage
Comment 21 François Bissey 2008-01-20 23:00:18 UTC
Created attachment 141414 [details, diff]
patch the prereq file.
Comment 22 François Bissey 2008-01-20 23:01:20 UTC
Created attachment 141416 [details, diff]
patch sage internal scipy to find portage installed atlas/lapack
Comment 23 François Bissey 2008-01-20 23:01:55 UTC
Created attachment 141417 [details, diff]
patch sage internal scipy_sandbox to find portage installed atlas/lapack
Comment 24 François Bissey 2008-01-20 23:03:16 UTC
Created attachment 141418 [details, diff]
patch cvxopt internal package to remove dependency on libf77blas.
Comment 25 François Bissey 2008-02-03 22:57:33 UTC
Created attachment 142615 [details]
update ebuild to sage-2.10.1

Sage-2.10.1 has been released and here is an updated/cleaned ebuild.
I bumped a number of requirements to match (gnutls and gsl) versions
included in sage. I updated the maxima warning with more info, added
an einfo section about licences. I bumped some patches, I cannot unfortunately
reduce the number any further. The cvxopt patch is still valid but the file
should be renamed cvxopt-0.9.p5.patch. It also still needs attachments
141408 and 14110.

This is raw and not tested apart from the fact that the patches apply 
correctly.

The test failure of 2.10 has been taken care of upstream.

Also I didn't mention it for 2.10 but it should take care of all the 
problems mentioned in earlier post. If it doesn't I can take it upstream.

A method for using atlas from the system has landed but it is not usable 
by Gentoo in its current state.

I have been working on replacing sage python components by Gentoo provided 
ones but progress is slow. Also I'd really like feedback, even if it is to
tell me you are using it successfully (you can send a private email for
that) so I now I really can continue working on this.
Progress will be further slowed down by my impeding fatherhood so I may
miss a few releases.
Comment 26 François Bissey 2008-02-03 22:58:45 UTC
Created attachment 142616 [details, diff]
patch to deps and prereq-0.3-install for sage-2.10.1
Comment 27 François Bissey 2008-02-03 22:59:49 UTC
Created attachment 142618 [details, diff]
updated patch to the internal copy of scipy
Comment 28 François Bissey 2008-02-03 23:00:22 UTC
Created attachment 142619 [details, diff]
updated patch to the internal copy of scipy_sandbox
Comment 29 François Bissey 2008-02-10 08:36:58 UTC
Created attachment 143099 [details]
2.10.1 ebuild revision to include gmp patch

OK new ebuild for 2.10.1. It should solve the ABI issue on amd64.
Thanks for serial_penguin on the forum for testing. However serial_penguin
had a lot of failures in the test suite. So it needs wider testing preferably
under both x86 and amd64 (ppc and ppc64 welcome as well).
More discussions over at:
http://forums.gentoo.org/viewtopic-p-4840637.html
Comment 30 François Bissey 2008-02-10 08:38:01 UTC
Created attachment 143100 [details, diff]
combined gmp patches from the forum
Comment 31 Thomas Kahle (RETIRED) gentoo-dev 2008-02-13 09:40:56 UTC
Hi, still fails to build on my machine (x86).

Here is the error and emerge --info.
Thanks for your effort:

building 'numpy.linalg.lapack_lite' extension
compiling C sources
C compiler: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC

creating build/temp.linux-i686-2.5/numpy/linalg
compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include -Ibuild/src.linux-i686-2.5/numpy/core -Inumpy/core/src -Inumpy/core/include -I/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/local/include/python2.5 -c'
gcc: numpy/linalg/lapack_litemodule.c
/usr/bin/gfortran -Wall -Wl,-O1 build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o -L/usr/lib -llapack -lblas -lgfortran -o build/lib.linux-i686-2.5/numpy/linalg/lapack_lite.so
build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o: In function `initlapack_lite':
/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/numpy/linalg/lapack_litemodule.c:827: undefined reference to `Py_InitModule4'
build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o: In function `_import_array':
/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/build/src.linux-i686-2.5/numpy/core/__multiarray_api.h:945: undefined reference to `PyImport_ImportModule'
/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/build/src.linux-i686-2.5/numpy/core/__multiarray_api.h:948: undefined reference to `PyObject_GetAttrString'
/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/build/src.linux-i686-2.5/numpy/core/__multiarray_api.h:950: undefined reference to `PyCObject_Type'
/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/build/src.linux-i686-2.5/numpy/core/__multiarray_api.h:958: undefined reference to `PyExc_RuntimeError'
.
.
.
build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o: In function `lapack_lite_dgeev':
/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/numpy/linalg/lapack_litemodule.c:165: undefined reference to `Py_BuildValue'
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgfortranbegin.a(fmain.o): In function `main':
(.text+0x23): undefined reference to `MAIN__'
collect2: ld returned 1 exit status
error: Command "/usr/bin/gfortran -Wall -Wl,-O1 build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o -L/usr/lib -llapack-lblas -lgfortran -o build/lib.linux-i686-2.5/numpy/linalg/lapack_lite.so" failed with exit status 1
Error building numpy.

real    2m29.308s
user    1m52.603s
sys     0m5.537s
sage: An error occurred while installing numpy-20080104-1.0.4.p2
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/install.log.  Describe your computer, operating system, etc.
If you want to try to fix the problem, yourself *don't* just cd to
/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2 and type 'make'.
Instead type "/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/sage -sh"
in order to set all environment variables correctly, then cd to
/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2
(When you are done debugging, you can type "exit" to leave the
subshell.)
make[1]: *** [installed/numpy-20080104-1.0.4.p2] Error 1
make[1]: Leaving directory `/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg'


-------------------

denkmatte tom # emerge --info
Portage 2.1.3.19 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r3 i686)
=================================================================
System uname: 2.6.23-gentoo-r3 i686 Mobile Intel(R) Pentium(R) III CPU - M 1200MHz
Timestamp of tree: Wed, 13 Feb 2008 07:16:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p17-r1
dev-java/java-config: 1.3.7, 2.1.4
dev-lang/python:     2.4.4-r6
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.10-r5
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.23-r3
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium3m -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/4.0/env /usr/kde/4.0/share/config /usr/kde/4.0/shutdown /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -march=pentium3m -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ "
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en de ja es fr it"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/science /usr/portage/local/layman/kde /usr/portage/local/layman/tom-overlay"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi alsa anthy apache2 arts avahi bash-completion berkdb bitmap-fonts bluetooth bzip2 cairo canna cddb cdparanoia cdr cjk cli cracklib crypt ctype cups curl daap dbus dri dvd dvdr dvdread eds emacs encode esd evo expat fam fbcon ffmpeg firefox flac fortran freewnn ftp gd gdbm gif glut gmp gphoto2 gpm graphviz gstreamer gtk guile hal iconv ieee1394 imagemagick imap imlib ipod ipv6 isdnlog java javascript jpeg kde kerberos ldap leim libnotify lm_sensors m17n-lib mad midi migemo mikmodmime mmx mp3 mp4 mpeg mplayer mudflap mule musicbrainz mysql mysqli ncurses networkmanager nls nptl nptlonly nsplugin obex ocaml ogg oggvorbis openal opengl openmp oss pam pcmcia pcre pdf perl php plotutils png pppd python qt3 qt3support qt4 quicktime readline real reflection samba sasl sdl session slang spell spl sqlite3 sse ssl svg tcpd tetex theora tiff tk truetype truetype-fonts type1-fonts unicode usb vhosts vim vim-syntax visualization vorbis wifi win32codecs wxwindows x86 xine xml xorg xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" FRITZCAPI_CARDS="fcpcmcia" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de ja es fr it" USERLAND="GNU" VIDEO_CARDS="i810 vesa"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 32 François Bissey 2008-02-13 19:15:28 UTC
Someone actually reported a similar error in the forum thread I mention in
comment #29. It turns out that you have to make sure that the files:
which_fortran and sage_fortran that you got from this bug are executable.
(chmod 0755). That should solve this problem. Post here or in the forum if 
you have another problem.
Comment 33 Thomas Capricelli 2008-03-09 22:49:59 UTC
I'm not allowed to do that, but someone should now remove the version number from the summary field.

I'm looking forward to seeing this ebuild in the official tree.
++
Comment 34 François Bissey 2008-03-16 04:21:05 UTC
I am not sure the title can be changed. May be the original poster can.
Anyway I am not sure sage will make it to the official tree any time soon,
and if it does it will be outdated as sage has a release every 2 to 3 weeks
currently.
Anyway if you want to test I have now a mini overlay as a tarball on
demand, I may find some web space to post it properly. But there are a lot of problems with the ebuild of the latest releases. Tests are failing and no clue
where to look. On amd64 python shipped with sage seem to have the dreaded
double free bug when built in portage.
So if you want it you will have to be ready to step up for testing and 
reporting at least.
Comment 35 Tristan Heaven (RETIRED) gentoo-dev 2008-05-02 15:59:27 UTC
*** Bug 220039 has been marked as a duplicate of this bug. ***
Comment 36 Markus Dittrich (RETIRED) gentoo-dev 2008-05-03 13:07:33 UTC
Folks,

Thanks much for the great work! I've been keeping an eye
on sage but haven't had much time to look at it in any
depth. Maybe we can get an ebuild into the science overlay
for a bit more testing.

best,
Markus 
Comment 37 François Bissey 2008-05-04 02:57:26 UTC
(In reply to comment #36)
> Folks,
> 
> Thanks much for the great work! I've been keeping an eye
> on sage but haven't had much time to look at it in any
> depth. Maybe we can get an ebuild into the science overlay
> for a bit more testing.
> 
Hi Markus,

I guess being in the official science overlay would be
nice. I am currently making progress splitting sage into
its components. A number of packages currently in the portage
tree should be updated (pari, ntl, singular and may be a few
other - I can provide ebuilds for a few of them).
Then there is a few ugly cases that I am not sure how to handle
like gmp. Sage use an experimental upstream patch deemed stable
but not officially included. I have a patched ebuild of gmp
and it works for me and a few other - but as it is not fixing
anything broken I don't know it would become an official part 
of Gentoo. Also sage uses sympy which is currently in the 
sunrise overlay if we bring a split sage in the science overlay
it would be nice to have it moved in the science overlay.
I guess I could become a proxy maintainer for sage once we get 
something usable again. I am thinking of Gentoo dev-hood, in the
science herd even, but I don't think my 3 month old will let me 
have enough time for that.

Nice to have some dev listening.

Comment 38 Markus Dittrich (RETIRED) gentoo-dev 2008-05-04 14:50:29 UTC
(In reply to comment #37)
> A number of packages currently in the portage
> tree should be updated (pari, ntl, singular and may be a few
> other - I can provide ebuilds for a few of them).

Please just file bugs for them if you are aware of any version
bumps. If you can provide ebuilds or a simple "old ebuild
works by just renaming" that would be even better :)

> Then there is a few ugly cases that I am not sure how to handle
> like gmp. Sage use an experimental upstream patch deemed stable
> but not officially included. I have a patched ebuild of gmp
> and it works for me and a few other - but as it is not fixing
> anything broken I don't know it would become an official part 
> of Gentoo.

If the patch looks reasonable and doesn't break anything I don't
see why we couldn't add it to support other packages (such as 
sage) in the tree.

> I am thinking of Gentoo dev-hood, in the
> science herd even, but I don't think my 3 month old will let me 
> have enough time for that.

:)

> 
> Nice to have some dev listening.
> 

We do listen, but due to missing manpower it is (very unfortunately)
simply impossible to follow up and comment on everything.

cheers,
Markus
Comment 39 Christian Kotz 2008-06-04 13:27:34 UTC
Has someone already created patches and ebuild for the current sage-3.0.2?
Comment 40 François Bissey 2008-07-02 02:22:04 UTC
(In reply to comment #39)
> Has someone already created patches and ebuild for the current sage-3.0.2?
> 

I have made some progress and will start to put more stuff on
Bugzilla. I hope to have a whole split sage in the 3.0.4 time frame.
Otherwise aiming for 3.1 .
Comment 41 François Bissey 2008-07-04 21:17:37 UTC
Can someone with enough power make bug #49282 block this one?
Neither the sage bug or the gap belongs to me so I can't.

Francois
Comment 42 Markus Dittrich (RETIRED) gentoo-dev 2008-07-05 10:44:32 UTC
(In reply to comment #41)
> Can someone with enough power make bug #49282 block this one?
> Neither the sage bug or the gap belongs to me so I can't.
> 

Hi Francois,

It looks like this bug already depends on #49282 or did I
misunderstand your request?

Best,
Markus
 

Comment 43 Sébastien Fabbro (RETIRED) gentoo-dev 2008-07-05 10:51:25 UTC
> Hi Francois,
> 
> It looks like this bug already depends on #49282 or did I
> misunderstand your request?

I just made the dependency today.
sage and deps would greatly benefit from a science overlay testing bed. We should start review all these ebuilds.
Thanks for your work.
Comment 44 François Bissey 2008-07-05 11:06:16 UTC
(In reply to comment #43)
> > Hi Francois,
> > 
> > It looks like this bug already depends on #49282 or did I
> > misunderstand your request?
> 
> I just made the dependency today.
> sage and deps would greatly benefit from a science overlay testing bed. We
> should start review all these ebuilds.
> Thanks for your work.
> 
Thanks guys. I actually would like to get stuff into bugzilla
for the upcoming 3.0.4 release and there are a number of issues
including gap (bug #49282) to discuss.
*In my own overlay I created a category called dev-sage for stuff
that solely belongs to sage or is in a special "sage" state (sage
ship a snapshot of ipython1 for example).
*Sage releases have somewhat slowed downed since 3.0 but it still
moving fast and individual spkg (sage tar.bz2 tarball) are removed
from their server to be replaced by the new ones. The only way to get
old spkg is to download a full release containing it - that will 
create trouble unless we decide to get stuff from the release tarball.
This would negate some benefits of split ebuild.
*I have a simple eclass that has evolved from the time I was trying
monolithic build it has some cruft not used anymore unless someone wants
to make a new monolithic ebuild.

That's it for now. I am hanging in irc (kiwi_fb is my current nick for a bit).
Comment 45 Tim Cera 2008-10-09 00:19:35 UTC
I have a _binary_ package ebuild for Sage 3.1.2 in the science overlay.  See http://bugs.gentoo.org/show_bug.cgi?id=240622
Comment 46 Tim Cera 2009-10-24 00:59:27 UTC
Created attachment 208108 [details]
sage-4.1.2.ebuild 

This ebuild builds sage the monolithic, everything plus the kitchen sink way that the Sage developers want you to build it.  Every single Sage dependency is included within Sage's own packaging system which probably duplicates many packages already installed.  Sage does keep track of it's packages within it's own directory so it isn't a question of conflicting with installed Gentoo packages, but still not the Gentoo way at all.
Comment 47 Christopher Schwan 2009-10-24 15:30:53 UTC
Thanks for supplying the ebuild - compiled fine on my i686 machine but install fails with an access violation:

...
Sage build/upgrade complete!
>>> Source compiled.        
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE "/var/log/sandbox/sandbox-8418.log"                                    

VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status  
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path               
FORMAT: C - Command Line                 

F: open_wr
S: deny   
P: /etc/ld.so.cache~
A: /etc/ld.so.cache~
R: /etc/ld.so.cache~
C: ldconfig         

F: unlinkat
S: deny    
P: /lib/libecm.*
A: /lib/libecm.*
R: /lib/libecm.*
C: rm -f /lib/libecm.* 
--------------------------------------------------------------------------------

Do you know how to fix this ?
Comment 48 Tim Cera 2009-10-24 21:51:39 UTC
No.  I don't know how to fix, yet.  Will do some research.  Is the pasted in portion the contents of /var/log/sandbox/sandbox-8418.log?  If not, could you post?  How long did it take to compile?

Kindest regards,
Tim
Comment 49 François Bissey 2009-10-25 01:56:32 UTC
(In reply to comment #48)
> No.  I don't know how to fix, yet.  Will do some research.  Is the pasted in
> portion the contents of /var/log/sandbox/sandbox-8418.log?  If not, could you
> post?  How long did it take to compile?
> 
Hi guys,

it looks like to losely based that ebuild on some of my earlier work.
I may be able to help. In fact I may be able to have another shot at 
packaging sage in the next few weeks. Hopefully it won't be shot of course
at the last minute like last time. I very much would like to see the 
complete sandbox violation file as well. gzip it and attach it to the 
bug, it would also be interesting to have the build log as well, 
sometime build can continue while a component has failed (especially
true of the optional ones).

I have some idea of what is wrong from the 2 lines posted but 
I will have to see the latest iteration of the sage build system.
Comment 50 Christopher Schwan 2009-10-25 08:12:34 UTC
Tim Cera: Yes, the sandbox file does not contain more infomation as pasted.

Francois Bissey: The build took about 208 minutes (see also at the end of the build log)
Comment 51 Christopher Schwan 2009-10-25 08:35:18 UTC
If you would like to see my complete build log, download from:

http://www.students.uni-mainz.de/cschwan/sage-build.log.tar.bz2

(File is too big for bugzilla).
Comment 52 François Bissey 2009-10-25 09:11:24 UTC
(In reply to comment #51)
> If you would like to see my complete build log, download from:
> 
> http://www.students.uni-mainz.de/cschwan/sage-build.log.tar.bz2
> 
> (File is too big for bugzilla).
> 
Thank you so much! One of the violation occurred much earlier during
the building process and points to an error in the coding of ecm spkg 
(I think):
ecm-6.2.1.p0/.hg/00changelog.i
ecm-6.2.1.p0/spkg-check
Finished extraction
****************************************************
Host system
uname -a:
Linux gnuke-notebook 2.6.31-gentoo-r3 #1 PREEMPT Wed Oct 14 21:01:01 CEST 2009 i686 Intel(R) Pentium(R) M processor 1.73GHz GenuineIntel GNU/Linux
****************************************************
****************************************************
CC Version
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --disable-libgomp --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.0, pie-10.1.5'
Thread model: posix
gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5) 
****************************************************
Removing old binary, headers and static library
[31;01mACCESS DENIED[0m  unlinkat:     /lib/libecm.*
rm: cannot remove `/lib/libecm.*': Permission denied
rm: cannot remove `/var/tmp/portage/sci-mathematics/sage-4.1.2/work/sage-4.1.2/local/include/ecm.h': No such file or directory
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes


I will look for the other one. I probably can do something about those.
Sage-4.2 is out by the way....
Comment 53 François Bissey 2009-10-25 09:38:25 UTC
OK found the error in ecm and filled a bug upstream in sage as it is
a typo in the spkg-install file.
The ldconfig call is more tricky - it looks like a change of the way
sage is build that may need to be addressed. 
Comment 54 Tim Cera 2009-10-25 13:31:47 UTC
If this helps I didn't have a sandbox violation on AMD64.  I do use paludis, but usually that means a stricter interpretation of the ebuild, rules, environement, ...etc.

Trying 4.2 right now.

Kindest regards,
Tim
Comment 55 François Bissey 2009-10-25 21:22:15 UTC
(In reply to comment #54)
> If this helps I didn't have a sandbox violation on AMD64.  I do use paludis,
> but usually that means a stricter interpretation of the ebuild, rules,
> environement, ...etc.
> 
> Trying 4.2 right now.
> 
Hi,

not sure about paludis configuration but I have the following features 
enabled in /etc/make.conf I wonder if you have the paludis equivalent:
FEATURES="parallel-fetch userfetch sandbox collision-protect ccache"
I definitely recommend having sandbox and collision-protect if you 
develop ebuilds as it catch some QA (quality assurance) issue as reported
by Christopher. 
Those 2 issues are not solved in 4.2. I think I found the origin of 
the ldconfig issue. Since there seems to be interest for a monolithic
ebuild at this time I may post a patched ebuild later today to try
to solve those issues. Testers are welcome as I lack the building 
power at the moment (which is one the reason split sage has stopped).
Comment 56 Christopher Schwan 2009-10-25 22:32:35 UTC
I can confirm this - 4.2 also failed to install, though i managed to write a patched ebuild which solves the first issue. If you post a new ebuild i am definitely willing to test it - we need sage in portage or at least an ebuild.
Comment 57 François Bissey 2009-10-26 01:07:14 UTC
(In reply to comment #56)
> I can confirm this - 4.2 also failed to install, though i managed to write a
> patched ebuild which solves the first issue. If you post a new ebuild i am
> definitely willing to test it - we need sage in portage or at least an ebuild.
> 
My experience is that Gentoo sage testers experience fatigue :(
Now which issue did you solve? ldconfig or ecm? And how, I think 
I have tracked down ldconfig to something not done right in pari
and that's non-trivial if you fixed that somehow I want to see it.
 
Comment 58 François Bissey 2009-10-26 02:06:59 UTC
Created attachment 208276 [details]
revised ebuild for 4.2 with patch

Resurrected a few functions that I had buried when moving to a split 
sage to make it easier to patch spkg. I am posting 2 patches to go 
with it. They are in the format requested by upstream if there is a problem
I'll amend them.
Happy testing.
Comment 59 François Bissey 2009-10-26 02:07:52 UTC
Created attachment 208278 [details, diff]
spkg patch to get rid of sandbox violiation from ecm
Comment 60 François Bissey 2009-10-26 02:11:49 UTC
Created attachment 208279 [details, diff]
tentative patch for the ldconfig sandbox violation.

It should take care of some ldconfig error in the sage build but I am
not 100% it will take care of the sandbox violation.
Comment 61 Christopher Schwan 2009-10-26 12:27:25 UTC
I fixed the ecm issue (found your bugreport on sagemath.org) in a similar way you did - I am currently compiling your new ebuild and i will report back if the patch works.
Comment 62 Christopher Schwan 2009-10-26 23:35:33 UTC
Ok tested your ebuild but unfortunately the pari patch did not fix the last sandbox violation issue. Your ebuild also contained a function src_prepare which does not get called (at least on my system). Also the patches you provided did not work since they were generated with mercurial - i have fixed this so that others can try to find the violation error. I also did some minor changes that were reported by repoman.
Comment 63 Christopher Schwan 2009-10-26 23:39:57 UTC
Created attachment 208383 [details]
new ebuild still failing because of sandbox violation error
Comment 64 Christopher Schwan 2009-10-26 23:40:53 UTC
Created attachment 208385 [details, diff]
fixes a typo in ecm spkg
Comment 65 Christopher Schwan 2009-10-26 23:41:32 UTC
Created attachment 208386 [details, diff]
fix for pari spkg
Comment 66 François Bissey 2009-10-27 01:44:52 UTC
Created attachment 208391 [details]
Silly me forgot to make it EAPI=2

src_prepare didn't get called because I forgot to set EAPI=2 in
the ebuild.
Comment 67 François Bissey 2009-10-27 01:53:39 UTC
(In reply to comment #62)
> Ok tested your ebuild but unfortunately the pari patch did not fix the last
> sandbox violation issue. Your ebuild also contained a function src_prepare
> which does not get called (at least on my system). Also the patches you
> provided did not work since they were generated with mercurial - i have fixed
> this so that others can try to find the violation error. I also did some minor
> changes that were reported by repoman.
> 
OK I am revising the patches it is almost certainly because of the folder "a"
and "b" provided in the headers so patch doesn't know to apply them. Easily
fixed with a minor edit. Could you provide your new build log somewhere
for me to examine.

Comment 68 François Bissey 2009-10-27 01:54:18 UTC
Created attachment 208393 [details, diff]
revised ecm patch
Comment 69 François Bissey 2009-10-27 01:54:55 UTC
Created attachment 208394 [details, diff]
revised pari patch
Comment 70 Steven Trogdon 2009-10-27 06:23:30 UTC
Created attachment 208405 [details, diff]
revision to pari-2.3.3.p5.patch

I was unable to get the pari-2.3.3.p5 patch to take relative to the sage-4.2 ebuild. I've attached what I used. The patch file was renamed to that used by Francois (pari-2.3.3.p5.patch) so the sage-4.2 ebuild could be used.
Comment 71 Christopher Schwan 2009-10-27 07:53:26 UTC
I accidentally destroyed my build log :-/ - rebuilding will take its time. Francois, are you available on irc ? My nick is gnuke.
Comment 72 Christopher Schwan 2009-10-27 16:40:17 UTC
I uploaded my build.log to http://www.students.uni-mainz.de/cschwan/sage-build2.log.tar.bz2 - build fails because of the known ldconfig violation error.
Comment 73 Steven Trogdon 2009-10-28 01:59:09 UTC
Created attachment 208471 [details]
sage startup log

On an amd64 machine I was able to build and install sage using the sage-4.2 ebuild with the exception that the documentation could not be built 
('sage -docbuild all html' failed). However, there are serious compilation issues since sage will not startup cleanly. I've attached a log of what happens when sage is started from the shell prompt.
Comment 74 François Bissey 2009-10-28 02:10:13 UTC
(In reply to comment #73)
> Created an attachment (id=208471) [details]
> sage startup log
> 
> On an amd64 machine I was able to build and install sage using the sage-4.2
> ebuild with the exception that the documentation could not be built 
> ('sage -docbuild all html' failed). However, there are serious compilation
> issues since sage will not startup cleanly. I've attached a log of what happens
> when sage is started from the shell prompt.
> 
It looks to me as if the doc is not the only thing that failed - but 
the rest must have failed silently. Can you find a file called:
ipy_profile_sage anywhere and post it for my post mortem?
Comment 75 François Bissey 2009-10-28 02:42:58 UTC
(In reply to comment #72)
> I uploaded my build.log to
> http://www.students.uni-mainz.de/cschwan/sage-build2.log.tar.bz2 - build fails
> because of the known ldconfig violation error.
> 
could you go in:
/var/tmp/portage/sci-mathematics/sage-4.2-r1/work/sage-4.2/local/lib/
and report the result of "ls -la libpari*"
please.
Comment 76 Steven Trogdon 2009-10-28 02:57:22 UTC
Created attachment 208475 [details]
ipy_profile_sage

(In reply to comment #74)
> (In reply to comment #73)
> > Created an attachment (id=208471) [details] [details]
> > sage startup log
> > 
> > On an amd64 machine I was able to build and install sage using the sage-4.2
> > ebuild with the exception that the documentation could not be built 
> > ('sage -docbuild all html' failed). However, there are serious compilation
> > issues since sage will not startup cleanly. I've attached a log of what happens
> > when sage is started from the shell prompt.
> > 
> It looks to me as if the doc is not the only thing that failed - but 
> the rest must have failed silently. Can you find a file called:
> ipy_profile_sage anywhere and post it for my post mortem?
> 

I've attached the file. I assume it's ipy_profile_sage.py
Comment 77 Christopher Schwan 2009-10-28 11:26:10 UTC
Francois: Here is a list of the libraries:

-rwxr-xr-x 1 root root 3085961 Oct 27 09:35 libpari-gmp.so.2
-rwxr-xr-x 1 root root 3085961 Oct 27 09:35 libpari-gmp.so.2.3.3
-rw-r--r-- 1 root root 3234730 Oct 27 09:35 libpari.a
-rwxr-xr-x 1 root root 3085961 Oct 27 09:35 libpari.so
Comment 78 Christopher Schwan 2009-11-04 17:34:30 UTC
After days of testing i am sure zlib is causing the last sandbox violation error. I rewrote the makefile to use the portage version of it and now sage compiles and installs fine.

I also set up an repository on github (http://github.com/cschwan/sage-on-gentoo) which already contains patches needed to remove some internal dependencies of sage and thus making the installation more "gentoo-ish" (and noticably faster). Try it!
Comment 79 François Bissey 2009-11-04 18:30:56 UTC
(In reply to comment #78)
> After days of testing i am sure zlib is causing the last sandbox violation
> error. I rewrote the makefile to use the portage version of it and now sage
> compiles and installs fine.
> 
> I also set up an repository on github
> (http://github.com/cschwan/sage-on-gentoo) which already contains patches
> needed to remove some internal dependencies of sage and thus making the
> installation more "gentoo-ish" (and noticably faster). Try it!
> 
zlib I will look into that.
That reminds me of my early efforts!
pari needs the data or at least part of it. I opened the bug to include 
data specially for sage. numpy is python so it will cause you pain at the 
moment (scons is OK on the other hand). maxima won't work is compiled
against sbcl lisp, it works with ecls - now the default in sage - and worked with clisp. So you can remove ecls from the deps list.
If you look at my previous work I was providing a replacement of the deps
file rather than patching it.
Which should switch to gfortran by setting the SAGE_FORTRAN variable before
making sage. sage g95 package is causing me pain with R and gcc-4.4.
rpy is nested in R (at least it was), we need rpy so careful with that one.
Comment 80 Steven Trogdon 2009-11-05 02:12:38 UTC
(In reply to comment #78)
> After days of testing i am sure zlib is causing the last sandbox violation
> error. I rewrote the makefile to use the portage version of it and now sage
> compiles and installs fine.
> 
> I also set up an repository on github
> (http://github.com/cschwan/sage-on-gentoo) which already contains patches
> needed to remove some internal dependencies of sage and thus making the
> installation more "gentoo-ish" (and noticably faster). Try it!
> 
I gave this a try on my amd64 desktop. I was unable to get sage to compile flint unless I added the gmp use flag to dev-libs/ntl. The package use flags I have enabled from previous testing of sage are:

sci-mathematics/maxima clisp
sci-mathematics/pari gmp cremona galois static doc
dev-lang/R lapack
dev-python/numpy lapack
sci-libs/scipy fftw sandbox

with dev-libs/ntl gmp now added. As mentioned in comment #73, installing the documentation still fails. This is in spite of the fact that the doc use flag was NOT enabled. There must be somewhere else that the sage install script is being overwritten. Even though sage seemed to compile and install I still got the same sage start-up errors as mentioned in comment #73. So, on my desktop, compilation fails somewhere.

It would seem that some of the "system default" packages are still being built by sage. On my machine I get that the following are still being built by sage:

cython-0.11.2.1
matplotlib-0.99.1.p2
numpy-1.3.0.p2
scipy-0.7.p2


Comment 81 François Bissey 2009-11-05 02:26:27 UTC
(In reply to comment #80)
> (In reply to comment #78)
> > 
> I gave this a try on my amd64 desktop. I was unable to get sage to compile
> flint unless I added the gmp use flag to dev-libs/ntl. The package use flags I
> have enabled from previous testing of sage are:
> 
> sci-mathematics/maxima clisp
> sci-mathematics/pari gmp cremona galois static doc
> dev-lang/R lapack
> dev-python/numpy lapack
> sci-libs/scipy fftw sandbox
> 
> with dev-libs/ntl gmp now added. As mentioned in comment #73, installing the
> documentation still fails. This is in spite of the fact that the doc use flag
> was NOT enabled. There must be somewhere else that the sage install script is
> being overwritten. Even though sage seemed to compile and install I still got
> the same sage start-up errors as mentioned in comment #73. So, on my desktop,
> compilation fails somewhere.
> 
> It would seem that some of the "system default" packages are still being built
> by sage. On my machine I get that the following are still being built by sage:
> 
> cython-0.11.2.1
> matplotlib-0.99.1.p2
> numpy-1.3.0.p2
> scipy-0.7.p2
> 

The pari flags cremona and galois have been replaced by data.
ntl should be built with gmp yes. The last four you mentioned
are python dependent, it is hard work to drop the internal python
from sage. So first stop is too remove anything non-python. 

I haven't looked at the doc problem do you have tex4html? It may need that.

Last round we were doing seriously doing stuff around sage there
was trouble with amd64 and supporting /usr/lib64 correctly.
I am not sure that short of a completely split ebuild we will sole that
problem.

I have a few ebuilds that should be updated in the science overlay and
on my hard drive which would enable us to pull more stuff out of sage.
Comment 82 Christopher Schwan 2009-11-05 11:59:56 UTC
(In reply to comment #80)
> As mentioned in comment #73, installing the 
> documentation still fails. This is in spite of the fact that the doc use flag
> was NOT enabled. There must be somewhere else that the sage install script is
> being overwritten.

The "spkg/install" script gets overwritten by sage_scripts-4.2.spkg which contains a copy of that file, but I am patching both install-files to not build the documentation - you think there is a third overwrite ? On my system documentation is not generated.

> Even though sage seemed to compile and install I still got
> the same sage start-up errors as mentioned in comment #73. So, on my desktop,
> compilation fails somewhere.

I your log file there is the following error message: "NotImplementedError: <type 'sage.rings.real_mpfr.int_toRR'>". I think this a sage bug on amd64, you should file a bug on their trac-site. I also found (http://www.mailinglistarchive.com/sage-support@googlegroups.com/msg02438.html) a user having a similar issue.

(In reply to comment #81)
> I have a few ebuilds that should be updated in the science overlay and
> on my hard drive which would enable us to pull more stuff out of sage.

That would be fine!
Comment 83 Steven Trogdon 2009-11-05 17:40:51 UTC
(In reply to comment #82)
> The "spkg/install" script gets overwritten by sage_scripts-4.2.spkg which
> contains a copy of that file, but I am patching both install-files to not build
> the documentation - you think there is a third overwrite ? On my system
> documentation is not generated.
> 

You're correct. The documentation isn't installed. The errors I see are the result of the "/opt/sage/sage -c quit" from the ebuild since sage will not start cleanly. However, the documentation still won't install if I try to do so with 'sage -docbuild all html'.

> 
> I your log file there is the following error message: "NotImplementedError:
> <type 'sage.rings.real_mpfr.int_toRR'>". I think this a sage bug on amd64, you
> should file a bug on their trac-site. I also found
> (http://www.mailinglistarchive.com/sage-support@googlegroups.com/msg02438.html)
> a user having a similar issue.
> 

Perhaps so. However, when I build sage the "usual" sage way, not using portage, I get no errors and all tests pass. The above seems to refer to building sage in the "usual" way, but maybe there is a connection.

Comment 84 Johannes Buchner 2009-11-28 02:55:50 UTC
*** Bug 293235 has been marked as a duplicate of this bug. ***
Comment 85 Christopher Schwan 2009-11-28 12:32:56 UTC
Seeing the previous comment I thought that it would be a good idea to report our (currently me and Francois Bissey, reports from Steven Trogdon) progress in making split sage ebuilds:

http://github.com/cschwan/sage-on-gentoo

Francois already sent a message to the science mailing list, but I think most people interested in sage have CC'ed to this bug.

As written in the README on the project page, Sage ships all of its dependencies (about 90 packages!) and we managed to remove about 30 of these. Currently I am trying to remove Singular from Sage - if this is done, all bigger non-Python packages are removed. The Python packages will take a bit more investigation since Sage ships (again ...) its own version of the Python interpreter.

Testers welcome!
Comment 86 Sébastien Fabbro (RETIRED) gentoo-dev 2009-12-02 18:08:34 UTC
*** Bug 295201 has been marked as a duplicate of this bug. ***
Comment 87 Christopher Schwan 2010-01-28 13:33:28 UTC
It has been a while since my last comment about splitting, so here are some updates:

- Sage is now available via layman (make sure you have updated your list with "layman -L" and add the repository with "layman -a sage-on-gentoo", for general info about layman see http://www.gentoo.org/proj/en/overlays/userguide.xml)

- Only a handful of packages are to split out - the remaining will need more time

- I have tested Sage on x86 and had mail from people which ran it successfully on amd64 - reports from other architectures would be fine

Comment 88 cruzki 2010-02-02 14:14:46 UTC
I'm having 2 problems when trying to install from overlay:

1º maxima didn't install if I have as-needed in my LDFLAGS.
2º ghmm have a linker problem:

readed-atlas                                                                                                                                                 
libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -ftracer -msse4 -mcx16 -msahf -msse4.1 -msse4.2 -floop-interchange -floop-strip-mine -floop-block -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o scluster scluster.o  ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas                                                                                                                                               
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':                                                                             
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'                                                                                             
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':                                                                                         
matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf'                                                                                            
matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri'                                                                                            
collect2: ld returned 1 exit status                                                                                                                          
distcc[7219] ERROR: compile (null) on localhost failed                                                                                                       
make[4]: *** [smo2xml] Error 1                                                                                                                               
make[4]: *** Se espera a que terminen otras tareas....                                                                                                       
libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -ftracer -msse4 -mcx16 -msahf -msse4.1 -msse4.2 -floop-interchange -floop-strip-mine -floop-block -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smix_hmm smix_hmm.o  ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas                                                                                                                                               
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':                                                                             
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'                                                                                             
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':                                                                                         
matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf'
matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri'
collect2: ld returned 1 exit status
distcc[7303] ERROR: compile (null) on localhost failed
make[4]: *** [probdist] Error 1
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':
matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf'
matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri'
collect2: ld returned 1 exit status
distcc[7339] ERROR: compile (null) on localhost failed
make[4]: *** [cluster] Error 1
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':
matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf'
matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri'
collect2: ld returned 1 exit status
distcc[7364] ERROR: compile (null) on localhost failed
make[4]: *** [scluster] Error 1
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':
matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf'
matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri'
collect2: ld returned 1 exit status
distcc[7399] ERROR: compile (null) on localhost failed
make[4]: *** [smix_hmm] Error 1
make[4]: se sale del directorio `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools'
make[3]: *** [all-recursive] Error 1
make[3]: se sale del directorio `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools'
make[2]: *** [all] Error 2
make[2]: se sale del directorio `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools'
make[1]: *** [all-recursive] Error 1
make[1]: se sale del directorio `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1'
make: *** [all] Error 2
 * ERROR: sci-libs/ghmm-0.9_rc1 failed:

any idea about the last one?

PS: in a pure 64 bit machine another package didn't install because missing 32 bits headers. I try to pass -m64 bit but it is filtering the CFLAGS, when I come back to house I search for the specific package.
Comment 89 Christopher Schwan 2010-02-02 17:36:35 UTC
What version of 

- sci-libs/blas-atlas
- sci-libs/lapack-atlas

do you have (should be 3.9.3) ?
Comment 90 cruzki 2010-02-02 18:14:42 UTC
The problem was with 3.9.3 for sure but i'm not sure if it is presented with 3.9.21 as well.

PS: the packages that I said before was tachyon:

n el fichero inclu�do de /usr/include/features.h:371En el fichero inclu�do de /usr/include/features.h:371,
                 de /usr/include/stdio.h:28,
                 de ../src/machine.h:7,
                 de /usr/include/stdio.h:28,
                 de ../src/apigeom.c:8,
                 de ../src/machine.h:7,
                 de ../src/api.c:8:
/usr/include/gnu/stubs.h:7:27::
/usr/include/gnu/stubs.h:7:27:  error: error: gnu/stubs-32.h:
Comment 91 Christopher Schwan 2010-02-03 14:49:52 UTC
I dont know whats the reason for ghmm compilation problem; could you please try to compile (lapack-blas, blas-lapack and ghmm in this order) once more with more conservative CFLAGS ("-march=core2 -O2 -pipe") ? If emerge still fails we can be sure ghmm is not confused with custom compilation flags.

Also make sure youre reporting logs with english error messages (prepending LC_ALL=C to "emerge" should do it).
Comment 92 cruzki 2010-02-05 12:38:25 UTC
I suppose you was saying that I make this:

LC_ALL=C emerge -qa1 lapack-atlas blas-atlas  ghmm

as  lapack-blas, blas-lapack does not exist.

mv -f .deps/smo2xml.Tpo .deps/smo2xml.Po                                                                                                                     
/bin/sh ../libtool --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc  -march=core2 -O2 -pipe   -I/usr/include/libxml2    -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smo2xml smo2xml.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread  -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread   -lxml2                                                                                                                                         
mv -f .deps/probdist.Tpo .deps/probdist.Po                                                                                                                   
/bin/sh ../libtool --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc  -march=core2 -O2 -pipe   -I/usr/include/libxml2    -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o probdist probdist.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread  -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread   -lxml2                                                                                                                                       
mv -f .deps/cluster.Tpo .deps/cluster.Po                                                                                                                     
mv -f .deps/scluster.Tpo .deps/scluster.Po                                                                                                                   
/bin/sh ../libtool --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc  -march=core2 -O2 -pipe   -I/usr/include/libxml2    -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o cluster cluster.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread  -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread   -lxml2                                                                                                                                         
/bin/sh ../libtool --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc  -march=core2 -O2 -pipe   -I/usr/include/libxml2    -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o scluster scluster.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread  -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread   -lxml2                                                                                                                                       
mv -f .deps/smix_hmm.Tpo .deps/smix_hmm.Po                                                                                                                   
/bin/sh ../libtool --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc  -march=core2 -O2 -pipe   -I/usr/include/libxml2    -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smix_hmm smix_hmm.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread  -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread   -lxml2                                                                                                                                       
libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smo2xml smo2xml.o  ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas                                                                                      
libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o probdist probdist.o  ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas                                                                                    
libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o scluster scluster.o  ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas                                                                                    
libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o cluster cluster.o  ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas                                                                                      
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':                                                                             
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'                                                                                             
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':                                                                                         
matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf'                                                                                            
matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri'                                                                                            
collect2: ld returned 1 exit status                                                                                                                          
distcc[16638] ERROR: compile (null) on localhost failed                                                                                                      
make[4]: *** [smo2xml] Error 1                                                                                                                               
make[4]: *** Waiting for unfinished jobs....                                                                                                                 
libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smix_hmm smix_hmm.o  ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas                                                                                    
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':                                                                             
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'                                                                                             
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':                                                                                         
matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf'                                                                                            
matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri'                                                                                            
collect2: ld returned 1 exit status                                                                                                                          
distcc[16733] ERROR: compile (null) on localhost failed                                                                                                      
make[4]: *** [probdist] Error 1                                                                                                                              
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':                                                                             
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'                                                                                             
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':                                                                                         
matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf'                                                                                            
matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri'                                                                                            
collect2: ld returned 1 exit status                                                                                                                          
distcc[16764] ERROR: compile (null) on localhost failed                                                                                                      
make[4]: *** [scluster] Error 1                                                                                                                              
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':                                                                             
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'                                                                                             
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':                                                                                         
matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf'                                                                                            
matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri'                                                                                            
collect2: ld returned 1 exit status                                                                                                                          
distcc[16792] ERROR: compile (null) on localhost failed                                                                                                      
make[4]: *** [cluster] Error 1                                                                                                                               
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition':                                                                             
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'                                                                                             
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':                                                                                         
matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf'                                                                                            
matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri'                                                                                            
collect2: ld returned 1 exit status                                                                                                                          
distcc[16821] ERROR: compile (null) on localhost failed                                                                                                      
make[4]: *** [smix_hmm] Error 1                                                                                                                              
make[4]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools'                                                             
make[3]: *** [all-recursive] Error 1                                                                                                                         
make[3]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools'                                                             
make[2]: *** [all] Error 2                                                                                                                                   
make[2]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools'                                                             
make[1]: *** [all-recursive] Error 1                                                                                                                         
make[1]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1'                                                                   
make: *** [all] Error 2         

I have noticed that the error depend on the blas and cblas implementation that have been selected with eselect. 
Comment 93 Christopher Schwan 2010-02-05 17:08:21 UTC
(In reply to comment #92)
> I suppose you was saying that I make this:
> 
> LC_ALL=C emerge -qa1 lapack-atlas blas-atlas  ghmm
> 
> as  lapack-blas, blas-lapack does not exist.
> 

Yes!

> [..]

Ok, so changing CFLAGS does not solve the problem. Please try again with more conservative LDFLAGS:

LDFLAGS="-Wl,-O1"
         
> 
> I have noticed that the error depend on the blas and cblas implementation that
> have been selected with eselect. 
> 

What do you exactly mean with "depends" ?
Comment 94 François Bissey 2010-02-05 20:35:48 UTC
(In reply to comment #93)
> (In reply to comment #92)
> > I suppose you was saying that I make this:
> > 
> > LC_ALL=C emerge -qa1 lapack-atlas blas-atlas  ghmm
> > 
> > as  lapack-blas, blas-lapack does not exist.
> > 
> 
> Yes!
> 
> > [..]
> 
> Ok, so changing CFLAGS does not solve the problem. Please try again with more
> conservative LDFLAGS:
> 
> LDFLAGS="-Wl,-O1"
>

A more conservative set is LDFLAGS="" as far as I know -Wl,-O1 is 
useless as the linker doesn't do optimization.
 
> > 
> > I have noticed that the error depend on the blas and cblas implementation that
> > have been selected with eselect. 
> > 
> 
> What do you exactly mean with "depends" ?
> 

I guess he means this:                                    
../ghmm/.libs/libghmm.a(matrixop.o): In function
`ighmm_cholesky_decomposition':                                                 
matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf'                
../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det':            
matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf'               
matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri'               
collect2: ld returned 1 exit status                                             

--------------
Are you sure lapack-atlas is properly selected? This is the only
supported clapack implementation as far as I can tell.
Can you give us the output of:
ls -la /usr/lib64/liblapack*


After looking carefully, I don't think the path to liblapack.so is
properly set. We have -L/usr/lib64/blas/threaded-atlas but nothing
similar for lapack. If I am not mistaken lapack should live in
/usr/lib64/lapack/(maybe threaded-atlas). I will inspect the ebuild
but I am almost sure that the proper path for lapack is not passed to it.
Comment 95 François Bissey 2010-02-05 21:03:38 UTC
Do you have several lapack installed? Can you give us the config.log?
Comment 96 cruzki 2010-02-05 21:12:42 UTC
I can't prove anythings until monday (the computer is on my office, not at home :( )
Comment 97 François Bissey 2010-02-06 10:03:13 UTC
(In reply to comment #96)
> I can't prove anythings until monday (the computer is on my office, not at home
> :( )
> 

That's all right. It gives me more time to give you a list of stuff to 
check. So I will want the following:
Output of "equery f lapack-atlas"
Output of "pkg-config --libs lapack"
Output of "pkg-config --cflags lapack"

All I can think of right now. And thank you for reminding me about the
maxima problem since I am having a look at maxima these days.
Although it should be a separate bug really.
Comment 98 cruzki 2010-02-08 10:47:49 UTC
Well, my homework :)

Seems like the links to lapack are set properly.
$ ls -la /usr/lib64/liblapack*
lrwxrwxrwx 1 root root 28 oct 19 17:28 /usr/lib64/liblapack.a -> lapack/reference/liblapack.a
lrwxrwxrwx 1 root root 29 oct 19 17:28 /usr/lib64/liblapack.so -> lapack/reference/liblapack.so
lrwxrwxrwx 1 root root 31 oct 19 17:28 /usr/lib64/liblapack.so.0 -> lapack/reference/liblapack.so.0

I only have the lapack that was instaled by sage.
$ eselect blas list
Installed BLAS for library directory lib64
  [1]   atlas
  [2]   atlas-threads
  [3]   reference *

$ eselect cblas list
Installed CBLAS for library directory lib64
  [1]   atlas
  [2]   atlas-threads
  [3]   gsl *

The config.log of the last try of building ghmm is in
http://personales.unican.es/borgesce/config.txt

My emerge --info
 emerge --info
Portage 2.2_rc62 (default/linux/amd64/10.0, gcc-4.4.2, glibc-2.11-r1, 2.6.32-gentoo-r3 x86_64)
=================================================================                             
System uname: Linux-2.6.32-gentoo-r3-x86_64-Intel-R-_Xeon-R-_CPU_E5520_@_2.27GHz-with-gentoo-2.0.1
Timestamp of tree: Mon, 08 Feb 2010 09:45:03 +0000                                                
distcc 3.1 x86_64-pc-linux-gnu [enabled]                                                          
app-shells/bash:     4.0_p37                                                                      
dev-java/java-config: 2.1.10                                                                      
dev-lang/python:     2.6.4-r99
dev-python/pycrypto: 2.1.0
dev-util/cmake:      2.8.0-r2
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.0-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.65
sys-devel/automake:  1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:  2.20
sys-devel/gcc:       4.4.2
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.30-r1
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -O2 -pipe -ftracer -msse4 -mcx16 -msahf -msse4.1 -msse4.2 -floop-interchange -floop-strip-mine -floop-block"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=core2 -O2 -pipe -ftracer -msse4 -mcx16 -msahf -msse4.1 -msse4.2 -floop-interchange -floop-strip-mine -floop-block"
DISTDIR="/home/portage/distfiles/"
EMERGE_DEFAULT_OPTS="--jobs 6 --keep-going --load-average 8"
FEATURES="assume-digests distcc distlocks fixpackages news parallel-fetch sandbox sfperms strict unmerge-logs unmerge-orphans userfetch usersandbox"
GENTOO_MIRRORS="http://sunsite.rediris.es/mirror/gentoo/"
LANG="es_ES"
LC_ALL="es_ES@euro"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common"
LINGUAS="es es_ES"
MAKEOPTS="-j11"
PKGDIR="/home/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/home/portage"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage/layman/kde /usr/local/portage/layman/java-overlay /usr/local/portage/layman/sage-on-gentoo /usr/local/portage/layman/toolchain /usr/local/portage/overlay"
SYNC="rsync://kassandra/gentoo-portage"
USE="X a52 aac acpi alsa amd64 avi branding bzip2 cdr cleartype cli cracklib crypt cups cxx dbus djvu dri dvd ffmpeg gif gmp gpm hal iconv jpeg kde lame latex lm_sensors lzma matroska mmx mmxext modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly nsl ntpl ogg oggvorbis opengl openmp pam pcre pdf pic pie png pppd qt3support qt4 readline reflection samba semantic-desktop session smp spell spl sse sse2 ssl ssse3 svg symlink sysfs tcpd theora threads tiff truetype type1 unicode usb vdpau vorbis x264 xcb xcomposite xinerama xml xorg xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm asym copy dmix dsnoop empty file ioplug null plug rate shm softvol" APACHE2_MODULES="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 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" ELIBC="glibc" FOO2ZJS_DEVICES="hp1020" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es es_ES" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset:  CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Note that i have a core i7 and this are the "safe cflags" recomended (exept ftracer, but i have tryed it before). 

Next
$equery f lapack-atlas
 * Searching for lapack-atlas ...
 * Contents of sci-libs/lapack-atlas-3.9.3:
/etc
/etc/env.d
/etc/env.d/lapack
/etc/env.d/lapack/lib64
/etc/env.d/lapack/lib64/atlas
/usr
/usr/include
/usr/include/atlas
/usr/include/atlas/clapack.h
/usr/include/clapack.h -> atlas/clapack.h
/usr/lib64
/usr/lib64/lapack
/usr/lib64/lapack/atlas
/usr/lib64/lapack/atlas/lapack.pc
/usr/lib64/lapack/atlas/liblapack.a
/usr/lib64/lapack/atlas/liblapack.la
/usr/lib64/lapack/atlas/liblapack.so -> liblapack.so.0.0.0
/usr/lib64/lapack/atlas/liblapack.so.0 -> liblapack.so.0.0.0
/usr/lib64/lapack/atlas/liblapack.so.0.0.0
/usr/share
/usr/share/doc
/usr/share/doc/lapack-atlas-3.9.3
/usr/share/doc/lapack-atlas-3.9.3/AtlasCredits.txt.bz2
/usr/share/doc/lapack-atlas-3.9.3/ChangeLog.bz2
/usr/share/doc/lapack-atlas-3.9.3/README.bz2

$ pkg-config --libs lapack
-llapack -lblas
$ pkg-config --cflags lapack

(empty)

I'am trying with 

CFLAGS="-O2 -march=native -pipe" LDFLAGS="" LC_ALL=C emerge -qa1 lapack-atlas blas-atlas ghmm

I will post the result. Note that it was updating blas-atlas and lapack atlas to 3.9.21-r1
Comment 99 cruzki 2010-02-08 11:43:35 UTC
The result of the emerge:

mv -f .deps/sdmodel.Tpo .deps/sdmodel.Plo                                                                                                                    
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT pviterbi.lo -MD -MP -MF .deps/pviterbi.Tpo -c pviterbi.c -o pviterbi.o >/dev/null 2>&1                                                             
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT pviterbi_propagate.lo -MD -MP -MF .deps/pviterbi_propagate.Tpo -c pviterbi_propagate.c -o pviterbi_propagate.o >/dev/null 2>&1                     
mv -f .deps/pviterbi.Tpo .deps/pviterbi.Plo                                                                                                                  
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT mes.lo -MD -MP -MF .deps/mes.Tpo -c mes.c -o mes.o >/dev/null 2>&1                                                                                 
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT scanner.lo -MD -MP -MF .deps/scanner.Tpo -c scanner.c -o scanner.o >/dev/null 2>&1                                                                 
mv -f .deps/pviterbi_propagate.Tpo .deps/pviterbi_propagate.Plo                                                                                              
mv -f .deps/mes.Tpo .deps/mes.Plo                                                                                                                            
mv -f .deps/scanner.Tpo .deps/scanner.Plo                                                                                                                    
In file included from matrixop.c:48:                                                                                                                         
/usr/include/clapack.h:4:24: error: atlas_misc.h: No such file or directory                                                                                  
In file included from matrixop.c:48:                                                                                                                         
/usr/include/clapack.h:42: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:42: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:43: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:44: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:44: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:45: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:46: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:46: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:47: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:48: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:48: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:49: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:77: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:77: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:78: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:79: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:79: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:80: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:81: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:81: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:82: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:83: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:83: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:84: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                 
/usr/include/clapack.h:112: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:112: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:113: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:114: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:114: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:115: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:116: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:116: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:117: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:118: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:118: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:119: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:147: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:147: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:148: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:149: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:149: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:150: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:151: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:151: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:152: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:153: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:153: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
/usr/include/clapack.h:154: error: expected declaration specifiers or '...' before 'ATL_CINT'                                                                
distcc[32136] ERROR: compile (null) on localhost failed                                                                                                      
make[3]: *** [matrixop.lo] Error 1                                                                                                                           
make[3]: *** Waiting for unfinished jobs....                                                                                                                 
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT linkedlist.lo -MD -MP -MF .deps/linkedlist.Tpo -c linkedlist.c -o linkedlist.o >/dev/null 2>&1                                                     
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT gauss_tail.lo -MD -MP -MF .deps/gauss_tail.Tpo -c gauss_tail.c -o gauss_tail.o >/dev/null 2>&1                                                     
mv -f .deps/linkedlist.Tpo .deps/linkedlist.Plo                                                                                                              
mv -f .deps/gauss_tail.Tpo .deps/gauss_tail.Plo                                                                                                              
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT mprintf.lo -MD -MP -MF .deps/mprintf.Tpo -c mprintf.c -o mprintf.o >/dev/null 2>&1                                                                 
mv -f .deps/mprintf.Tpo .deps/mprintf.Plo                                                                                                                    
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT vector.lo -MD -MP -MF .deps/vector.Tpo -c vector.c -o vector.o >/dev/null 2>&1                                                                     
mv -f .deps/vector.Tpo .deps/vector.Plo                                                                                                                      
make[3]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/ghmm'                                                              
make[2]: *** [all-recursive] Error 1                                                                                                                         
make[2]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/ghmm'                                                              
make[1]: *** [all-recursive] Error 1                                                                                                                         
make[1]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1'                                                                   
make: *** [all] Error 2                                                                                                                                      

Fail in the same file but the error is when compiling, not at link phase.
Comment 100 Steven Trogdon 2010-02-08 16:25:50 UTC
(In reply to comment #98)
> Well, my homework :)
> 
> I only have the lapack that was instaled by sage.
> $ eselect blas list
> Installed BLAS for library directory lib64
>   [1]   atlas
>   [2]   atlas-threads
>   [3]   reference *
> 
> $ eselect cblas list
> Installed CBLAS for library directory lib64
>   [1]   atlas
>   [2]   atlas-threads
>   [3]   gsl *
> 

I don't mean to muddy things, but I get similar errors to yours in building ghmm if I set blas and cblas to what you have and if I

eselect lapack set reference (3.1.1-r1)

What do you have lapack set to? If I 

eselect lapack set atlas (3.9.3)

then ghmm builds. Generally, I have all these packages set to either atlas or atlas-threads and ghmm builds.
Comment 101 François Bissey 2010-02-08 18:10:35 UTC
I believe this problems are solved with blas-atlas/lapack-atlas 3.9.21-r1
give it a try. I should have posted this 2 days ago.
Comment 102 cruzki 2010-02-23 18:50:04 UTC
It doesn't work until I set lapack to atlas instead of reference.

Thanks for the hard work :)
Comment 103 François Bissey 2010-02-23 19:48:06 UTC
(In reply to comment #102)
> It doesn't work until I set lapack to atlas instead of reference.
> 
> Thanks for the hard work :)
> 

lapack-atlas at least needs to be selected. Yes we know.
The reason is that a number of sage packages are using 
atlas implementation of clapack. There are no standard
for clapack, there is another implementation in the science
overlay but it is probably not compatible. 
culprits that I know for sure are: 
linbox
ghmm
Comment 104 Richard 2010-07-06 12:15:21 UTC
It has been 2.5 years since the first ebuild became available. Is there any chance that this will be included in the official tree, even if it is out of date?

By the way, version 4.4.4 is out.
Comment 105 Christopher Schwan 2010-07-06 12:32:16 UTC
(In reply to comment #104)
> It has been 2.5 years since the first ebuild became available. Is there any
> chance that this will be included in the official tree, even if it is out of
> date?

Though I am not a official gentoo developer I tend to say yes ! The main problem would be a small patch which is applied to python and which is not (yet) adopted by upstream (http://bugs.python.org/issue7689). Also, Sage has a long list of dependencies which one needs to put in the main tree first.

In the mean-time you may use our "sage-on-gentoo"-overlay at http://github.com/cschwan/sage-on-gentoo which always supports the most recent version of Sage (that includes 4.4.4).

> 
> By the way, version 4.4.4 is out.
> 

Comment 106 R Bar-On 2010-08-17 19:22:37 UTC
getting this into portage would be absolutely wonderful.  Layman overlay good for now though :)
Comment 107 Christopher Schwan 2010-08-17 19:44:08 UTC
Getting it into portage is our long-term objective, of course. And always remember: If you have problems with sage-on-gentoo, just write a mail to the gentoo-science list!

Cheers
Comment 108 Igor Poboiko 2010-11-04 11:49:00 UTC
I have some (maybe QA) questions about current sage ebuilds from sage-on-gentoo overlay (4.6-r1 versions).
First of all, why sage-banner is installed to /usr/bin/? It isn't executable file, after all.
Secondly, I don't agree that some debugger helpers (like sage-gdb or sage-valgrind) should be installed only when debug use-flag is enabled (sage-baselayout ebuild). Correct me please if I'm wrong, but I think this flag is used to enable some extra debug _code_.
Comment 109 François Bissey 2010-11-04 19:59:28 UTC
(In reply to comment #108)
> I have some (maybe QA) questions about current sage ebuilds from sage-on-gentoo
> overlay (4.6-r1 versions).
> First of all, why sage-banner is installed to /usr/bin/? It isn't executable
> file, after all.
> Secondly, I don't agree that some debugger helpers (like sage-gdb or
> sage-valgrind) should be installed only when debug use-flag is enabled
> (sage-baselayout ebuild). Correct me please if I'm wrong, but I think this flag
> is used to enable some extra debug _code_.
> 
Your two concerns are well noted. Moving sage-banner would be a further departure from upstream, I believe upstream may do something about it soon
so we'll wait before finding a solution.
I think you are right about the debug flag.

Thanks for your feed back, do not hesitate to voice your opinion we are listening!
Comment 110 Christopher Schwan 2010-11-29 10:57:27 UTC
(In reply to comment #109)
> (In reply to comment #108)
> > I have some (maybe QA) questions about current sage ebuilds from sage-on-gentoo
> > overlay (4.6-r1 versions).
> > First of all, why sage-banner is installed to /usr/bin/? It isn't executable
> > file, after all.
> > Secondly, I don't agree that some debugger helpers (like sage-gdb or
> > sage-valgrind) should be installed only when debug use-flag is enabled
> > (sage-baselayout ebuild). Correct me please if I'm wrong, but I think this flag
> > is used to enable some extra debug _code_.
> > 
> Your two concerns are well noted. Moving sage-banner would be a further
> departure from upstream, I believe upstream may do something about it soon
> so we'll wait before finding a solution.
> I think you are right about the debug flag.

Thats absolutely right. I just removed the USE-flag so that these files are installed by default.

> 
> Thanks for your feed back, do not hesitate to voice your opinion we are
> listening!
> 
Comment 111 Christopher Schwan 2010-11-29 11:00:31 UTC
There are least two people experiencing startup problems on amd64. If this sounds familiar to you, please take a look at my mail:

http://archives.gentoo.org/gentoo-science/msg_fbdeb9ffce6dd65a98953b648fd31000.xml
Comment 112 Richard 2010-11-29 12:42:49 UTC
In the past, I have wanted to install sage, but did not try because all of the USE flags that had to be enabled manually turned me away. I just tried again today and I am receiving fetch failures for the following packages:

sci-libs/libcliquer-1.2_p6
sci-mathematics/flintqs-20070817_p4

I also had to enable USE flags for an inordinate number of ebuilds. I think that many of them are in the sage overlay, so having to enable USE flags for them does not make sense to me. I put the sage USE flag into /etc/make.conf because it occurred so many times. Here are the lines that I had to add to /etc/portage/package.use:

dev-lisp/ecls -unicode
dev-python/numpy lapack
media-gfx/tachyon threads
sci-libs/flint ntl
sci-libs/linbox ntl
sci-mathematics/eclib pari24
sci-mathematics/glpk gmp
sci-mathematics/lcalc pari24
sci-mathematics/maxima ecls
sci-mathematics/pari data gmp
sci-mathematics/singular libsingular
Comment 113 Christopher Schwan 2010-11-29 13:35:20 UTC
(In reply to comment #112)
> In the past, I have wanted to install sage, but did not try because all of the
> USE flags that had to be enabled manually turned me away. I just tried again
> today and I am receiving fetch failures for the following packages:
> 
> sci-libs/libcliquer-1.2_p6
> sci-mathematics/flintqs-20070817_p4

Thank you for notifying me - those were updatedand I already uploaded new ebuilds for them. If this happens again, please notify us so we can fix it. These problems happened before (and will happen again, i think) because once you have downloaded the files you wont noticed that they are removed from upstream.

> 
> I also had to enable USE flags for an inordinate number of ebuilds. I think
> that many of them are in the sage overlay, so having to enable USE flags for
> them does not make sense to me. I put the sage USE flag into /etc/make.conf
> because it occurred so many times. Here are the lines that I had to add to
> /etc/portage/package.use:
> 
> dev-lisp/ecls -unicode
> dev-python/numpy lapack
> media-gfx/tachyon threads
> sci-libs/flint ntl
> sci-libs/linbox ntl
> sci-mathematics/eclib pari24
> sci-mathematics/glpk gmp
> sci-mathematics/lcalc pari24
> sci-mathematics/maxima ecls
> sci-mathematics/pari data gmp
> sci-mathematics/singular libsingular
> 

We have prepared a package.use file for that - please read the file README.rst in our overlay or go to

  https://github.com/cschwan/sage-on-gentoo

where you may read a formatted version of it. Everyone interested in Sage should take a look at this site!
Comment 114 Beetle B. 2010-11-29 15:38:55 UTC
(In reply to comment #112)
> In the past, I have wanted to install sage, but did not try because all of the
> USE flags that had to be enabled manually turned me away. I just tried again
> today and I am receiving fetch failures for the following packages:

Install the autounmask package, and learn how to use it. It's very handy, and I think it also handles USE flags. 

Essentially, if you want to install a package and it needs some USE flags to be set in other packages, it will populate package.use for you. 
Comment 115 Christopher Schwan 2010-11-29 16:34:20 UTC
(In reply to comment #114)
> (In reply to comment #112)
> > In the past, I have wanted to install sage, but did not try because all of the
> > USE flags that had to be enabled manually turned me away. I just tried again
> > today and I am receiving fetch failures for the following packages:
> 
> Install the autounmask package, and learn how to use it. It's very handy, and I
> think it also handles USE flags. 
> 
> Essentially, if you want to install a package and it needs some USE flags to be
> set in other packages, it will populate package.use for you. 
> 

There is even a third option:

emerge --autounmask sage

which was introduced with portage 2.1.9.x (though I havent tested that).
Comment 116 SpanKY gentoo-dev 2011-07-01 01:32:12 UTC
*** Bug 372683 has been marked as a duplicate of this bug. ***
Comment 117 Sebastian Luther (few) 2011-08-16 08:49:58 UTC
Is there a chance to get an init script for sage to run a sage server?
Comment 118 Christopher Schwan 2011-08-16 08:59:16 UTC
(In reply to comment #117)
> Is there a chance to get an init script for sage to run a sage server?

sci-mathematics/sage-notebook-server is written exactly for this purpose. I wrote it some time ago, but it should still work. If it does no longer work or if you have any ideas how to improve it, let me know.
Comment 119 Sebastian Luther (few) 2011-08-16 09:51:16 UTC
(In reply to comment #118)
> (In reply to comment #117)
> > Is there a chance to get an init script for sage to run a sage server?
> 
> sci-mathematics/sage-notebook-server is written exactly for this purpose. I
> wrote it some time ago, but it should still work. If it does no longer work or
> if you have any ideas how to improve it, let me know.

Thank you!

It mostly works. Only 'mostly' because I couldn't start a secure notebook. It complained that 'certtool' is missing when running the setup. Until recently I used upstream's tarball to compile and run sage in my home directoy. After copying my .sage directory over to /var/lib/sage the server started.

Two additional points:
a) It would be nice if the user that runs the notebook would be configurable.
b) Why don't you install sci-mathematics/sage-notebook-server as a dependency of sage? Two files won't hurt anyone and those searching for an init script would find it right away.
Comment 120 Peter Gantner (a.k.a. nephros) 2011-08-16 10:13:50 UTC
(In reply to comment #119)
> It mostly works. Only 'mostly' because I couldn't start a secure notebook. It
> complained that 'certtool' is missing when running the setup.

/usr/bin/certool is a part of gnutls. Do you get the error as well if you have net-libs/gnutls installed? If yes, maybe it's a PATH problem?
Comment 121 Christopher Schwan 2011-08-16 11:13:11 UTC
(In reply to comment #119)
> (In reply to comment #118)
> > (In reply to comment #117)
> > > Is there a chance to get an init script for sage to run a sage server?
> > 
> > sci-mathematics/sage-notebook-server is written exactly for this purpose. I
> > wrote it some time ago, but it should still work. If it does no longer work or
> > if you have any ideas how to improve it, let me know.
> 
> Thank you!
> 
> It mostly works. Only 'mostly' because I couldn't start a secure notebook. It
> complained that 'certtool' is missing when running the setup. Until recently I
> used upstream's tarball to compile and run sage in my home directoy. After
> copying my .sage directory over to /var/lib/sage the server started.
> 
> Two additional points:
> a) It would be nice if the user that runs the notebook would be configurable.

Thats a good idea. I will add some code to interactively configure it.

> b) Why don't you install sci-mathematics/sage-notebook-server as a dependency
> of sage? Two files won't hurt anyone and those searching for an init script
> would find it right away.

I tried to be careful because I do not have any experience regarding servers. I am also not sure if the current behavior (starting everything as user "sage") is safe. If the startup scripts are thoroughly tested I will include them into sci-mathematics/sage.
Comment 122 Sebastian Luther (few) 2011-08-16 17:56:40 UTC
(In reply to comment #120)
> (In reply to comment #119)
> > It mostly works. Only 'mostly' because I couldn't start a secure notebook. It
> > complained that 'certtool' is missing when running the setup.
> 
> /usr/bin/certool is a part of gnutls. Do you get the error as well if you have
> net-libs/gnutls installed? If yes, maybe it's a PATH problem?

You're right, I didn't have gnutls installed.

Now that this error is gone, there is another problem. For 'setup' to do all necessary things, sage needs to be passed all the arguments it's started later on with. If this doesn't happen it tries to run notebook.setup() on start which is interactive in my case.

The following line worked for me in setup():

su sage -c "/usr/bin/sage -notebook accounts=${accounts-False} interface=${interface-localhost} open_viewer=False port=${port-8000} require_login=${require_login-True} secure=${secure-False} timeout=${timeout-0}"
Comment 123 Sebastian Luther (few) 2011-08-16 17:59:20 UTC
(In reply to comment #121)
> (In reply to comment #119)
> > Two additional points:
> > a) It would be nice if the user that runs the notebook would be configurable.
> 
> Thats a good idea. I will add some code to interactively configure it.
> 

I thought more about a setting in /etc/conf.d/sage-notebook-server
Comment 124 Sebastian Luther (few) 2011-08-23 07:34:55 UTC
After upgrading from 4.7-r2 to 4.7.1, sage does no longer work. On the first start it asked me to run %upgrade and after that it asked me to delete a file in ~/.sage. After that it asked again for %upgrade, but that had no effect.
After removing ~/.sage, I get the trace back below.

----------------------------------------------------------------------
| Sage Version 4.7.1, Release Date: 2011-08-11                       |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------

Please wait while the Sage Notebook server starts...
Traceback (most recent call last):
  File "/usr/bin/sage-notebook-real", line 9, in <module>
    from sage.server.notebook.all import notebook
  File "/usr/lib/python2.7/site-packages/sage/server/notebook/all.py", line 22, in <module>
    from sagenb.notebook.all import *
  File "/usr/lib/python2.7/site-packages/sagenb/notebook/all.py", line 16, in <module>
    from notebook_object import notebook, inotebook
  File "/usr/lib/python2.7/site-packages/sagenb/notebook/notebook_object.py", line 17, in <module>
    import notebook as _notebook
  File "/usr/lib/python2.7/site-packages/sagenb/notebook/notebook.py", line 35, in <module>
    from sagenb.misc.misc import (pad_zeros, cputime, tmp_dir, load, save,
  File "/usr/lib/python2.7/site-packages/sagenb/misc/misc.py", line 183, in <module>
    import sage.all
  File "/usr/lib/python2.7/site-packages/sage/all.py", line 85, in <module>
    import sage.symbolic.pynac
  File "expression.pxd", line 6, in init sage.symbolic.pynac (sage/symbolic/pynac.cpp:19320)
  File "expression.pyx", line 6651, in init sage.symbolic.expression (sage/symbolic/expression.cpp:36442)
  File "/usr/lib/python2.7/site-packages/sage/misc/decorators.py", line 648, in __call__
    @sage_wraps(func)
  File "/usr/lib/python2.7/site-packages/sage/misc/decorators.py", line 106, in f
    argspec = sage_getargspec(wrapped)
  File "/usr/lib/python2.7/site-packages/sage/misc/sageinspect.py", line 1076, in sage_getargspec
    return inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj)))
  File "/usr/lib/python2.7/site-packages/sage/misc/sageinspect.py", line 865, in _sage_getargspec_cython
    raise ValueError, "Could not parse cython argspec"
ValueError: Could not parse cython argspec
Comment 125 Christopher Schwan 2011-08-23 08:05:29 UTC
Thanks for reporting!

You can solve the problem immediately by compiling sage and sage-baselayout with USE=testsuite. However, I will upload a new ebuild shortly which takes care of that.

See also the following discussions on gentoo-science:

http://archives.gentoo.org/gentoo-science/msg_715609e30f80b243448c4cee38bc8028.xml

http://archives.gentoo.org/gentoo-science/msg_e70ba547fd186a09cb1d5754930cead6.xml
Comment 126 Sebastian Luther (few) 2011-08-23 08:19:21 UTC
(In reply to comment #125)
> Thanks for reporting!
> 
Thank you for the quick reply!
Comment 127 Christopher Schwan 2011-08-23 08:22:38 UTC
No problem. Sage should now work again!
Comment 128 Christopher Schwan 2011-08-28 08:21:59 UTC
(In reply to comment #123)
> (In reply to comment #121)
> > (In reply to comment #119)
> > > Two additional points:
> > > a) It would be nice if the user that runs the notebook would be configurable.
> > 
> > Thats a good idea. I will add some code to interactively configure it.
> > 
> 
> I thought more about a setting in /etc/conf.d/sage-notebook-server

I just updated the startup script and its configuration file. If Sage isnt properly setup, it should detect this and print instructions how to do this.

I plan to keep sage-notebook-server.ebuild separate for a little longer; tell me if you like the current behavior of the startup script, what to do better and so on. If I feel fine with it, I will eventually merge it with sage-notebook.
Comment 129 Sebastian Luther (few) 2011-08-28 12:16:34 UTC
(In reply to comment #128)
> I just updated the startup script and its configuration file. If Sage isnt
> properly setup, it should detect this and print instructions how to do this.
>
> I plan to keep sage-notebook-server.ebuild separate for a little longer; tell
> me if you like the current behavior of the startup script, what to do better
> and so on. 

Following instructions works. I think this approach is better than the old one.
Some comments:
a) Steps 2 and 3 could be one step with su $user -c "$cmd".
b) It would be nice if the sever would not start after the configuration steps.

> If I feel fine with it, I will eventually merge it with sage-notebook.
Makes sense. Could you use some versioning for sage-notebook-server? Otherwise it's not possible to go forth and back and one easily misses changes you make.

Keep up the good work!
Comment 130 Sebastian Luther (few) 2011-08-28 17:51:26 UTC
$ LC_ALL=C sage
----------------------------------------------------------------------
| Sage Version 4.7.1, Release Date: 2011-08-11                       |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
sage: var('i n')
(i, n)
sage: sum(4*i+1, i, 1, n)
/usr/bin/sage-sage: line 230:  8666 Power failure           sage-ipython "$@" -i
Comment 131 Christopher Schwan 2011-08-28 18:22:31 UTC
(In reply to comment #129)
> (In reply to comment #128)
> > I just updated the startup script and its configuration file. If Sage isnt
> > properly setup, it should detect this and print instructions how to do this.
> >
> > I plan to keep sage-notebook-server.ebuild separate for a little longer; tell
> > me if you like the current behavior of the startup script, what to do better
> > and so on. 
> 
> Following instructions works. I think this approach is better than the old one.
> Some comments:
> a) Steps 2 and 3 could be one step with su $user -c "$cmd".

That is much better.

> b) It would be nice if the sever would not start after the configuration steps.

You are right, but I am not sure if this is possible with the current approach.

> 
> > If I feel fine with it, I will eventually merge it with sage-notebook.
> Makes sense. Could you use some versioning for sage-notebook-server? Otherwise
> it's not possible to go forth and back and one easily misses changes you make.

OK, I changed the version from 9999 to 1 and 1-r1.

> 
> Keep up the good work!

Thank you!

(In reply to comment #130)
> $ LC_ALL=C sage
> ----------------------------------------------------------------------
> | Sage Version 4.7.1, Release Date: 2011-08-11                       |
> | Type notebook() for the GUI, and license() for information.        |
> ----------------------------------------------------------------------
> sage: var('i n')
> (i, n)
> sage: sum(4*i+1, i, 1, n)
> /usr/bin/sage-sage: line 230:  8666 Power failure           sage-ipython "$@"
> -i

Strange. Yields

LC_ALL=C sage
----------------------------------------------------------------------
| Sage Version 4.7.1, Release Date: 2011-08-11                       |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
sage: var('i n')
(i, n)
sage: sum(4*i+1,i,1,n)
2*n^2 + 3*n

on my box. Is anyone able to reproduce that behavior?
Comment 132 François Bissey 2011-08-29 01:53:03 UTC
Paulo (from Mandriva) reported something similar in:
http://trac.sagemath.org/sage_trac/ticket/11752

Do you have boehm-gc/ecls with threads enabled? I have threads in boehm-gc but not ecls and don't have any issue.
Comment 133 Sebastian Luther (few) 2011-08-29 06:56:17 UTC
(In reply to comment #132)
> Paulo (from Mandriva) reported something similar in:
> http://trac.sagemath.org/sage_trac/ticket/11752
> 
> Do you have boehm-gc/ecls with threads enabled? I have threads in boehm-gc but
> not ecls and don't have any issue.

I had both with +threads. Rebuilding ecls with -threads and then rebuilding maxima and sage fixed the issue (and the one in sage bug tracker too). Rebuilding ecls only cuased sage to segfault.
Comment 134 François Bissey 2011-08-29 12:47:01 UTC
(In reply to comment #133)
> (In reply to comment #132)
> > Paulo (from Mandriva) reported something similar in:
> > http://trac.sagemath.org/sage_trac/ticket/11752
> > 
> > Do you have boehm-gc/ecls with threads enabled? I have threads in boehm-gc but
> > not ecls and don't have any issue.
> 
> I had both with +threads. Rebuilding ecls with -threads and then rebuilding
> maxima and sage fixed the issue (and the one in sage bug tracker too).
> Rebuilding ecls only cuased sage to segfault.

Yes one would need to rebuild sage as well because of sage/libs/ecl.pyx.
Paulo has included a nice patch that will make the problem go away whatever the threads setting. So we'll include that at some point. Thank you for coming back with the info.
Comment 135 François Bissey 2011-08-29 19:44:26 UTC
(In reply to comment #133)
> (In reply to comment #132)
> > Paulo (from Mandriva) reported something similar in:
> > http://trac.sagemath.org/sage_trac/ticket/11752
> > 
> > Do you have boehm-gc/ecls with threads enabled? I have threads in boehm-gc but
> > not ecls and don't have any issue.
> 
> I had both with +threads. Rebuilding ecls with -threads and then rebuilding
> maxima and sage fixed the issue (and the one in sage bug tracker too).
> Rebuilding ecls only cuased sage to segfault.

Paulo's patch is now in the overlay so you can use threads with ecls and it shouldn't cause any trouble anymore.
Comment 136 Sebastian Luther (few) 2011-08-30 07:50:13 UTC
(In reply to comment #135)
> Paulo's patch is now in the overlay so you can use threads with ecls and it
> shouldn't cause any trouble anymore.

Works now. Thanks!
Comment 137 Sebastian Luther (few) 2011-09-01 09:20:29 UTC
Any idea why 3d plotting doesn't work for me?

I tried an example from the sage documentation in the notebook:

#The stuff below works.
x, y = var('x y')
W = plot3d(sin(pi*((x)^2+(y)^2))/2,(x,-1,1),(y,-1,1), frame=False, color='purple', opacity=0.8) 
S = sphere((0,0,0),size=0.3, color='red', aspect_ratio=[1,1,1])

#This does not.
show(W + S, figsize=8)

A popup appears telling me: "ReferenceError: jmolSetDocument is not defined".
Comment 138 Christopher Schwan 2011-09-01 09:26:59 UTC
(In reply to comment #137)
> [..]
> 
> A popup appears telling me: "ReferenceError: jmolSetDocument is not defined".

Did you compile the sage-notebook with USE=-java ?
Comment 139 Sebastian Luther (few) 2011-09-01 10:55:54 UTC
(In reply to comment #138)
> (In reply to comment #137)
> > [..]
> > 
> > A popup appears telling me: "ReferenceError: jmolSetDocument is not defined".
> 
> Did you compile the sage-notebook with USE=-java ?

Right, that was the problem. Somewhat unexpected, but I don't have a better idea how to deal with this. Maybe +java should be an IUSE default and everyone insisting on -java can do this, sacrificing some functionality. 

Additionally to the use flag change I had to keyword =sci-libs/vecmath-objectclub-1.14.

Now the applet shows up and seems to work properly, except that I again and again get popups telling me things like:
"Second attempt to finish launch of Jmol Applet #2 failed.  Recommend reevaluating the cell manually"
Comment 140 François Bissey 2011-09-01 12:34:40 UTC
I'll confess that the jmol integration in the sage-notebook is not quite as good as the rest in sage-on-gentoo. I'll try to find the source of the problem. What browser are you using or does that make no difference?
Comment 141 Sebastian Luther (few) 2011-09-01 15:13:31 UTC
(In reply to comment #140)
> What browser are you using or does that make no difference?

On Windows 7, with firefox 5 it happens that often that it's really annoying. On gentoo with firfox 3 and chromium 13 is much harder to trigger, but it happens too from time to time. I have yet to find a reproducible way to trigger it.
Comment 142 Steven Trogdon 2011-09-01 17:14:46 UTC
(In reply to comment #140)
> I'll confess that the jmol integration in the sage-notebook is not quite as
> good as the rest in sage-on-gentoo. I'll try to find the source of the problem.
> What browser are you using or does that make no difference?

Here the popups are associated with one of the patches

   epatch "${FILESDIR}"/trac_9238_interactive_js.patch
   epatch "${FILESDIR}"/trac_9238_jmol_lib_async.patch

in sage-notebook. I'm not sure exactly where. I suspect a search path isn't quite correct for the sog installation. If I remove the patches and re-install sage-notebook, I get no pop-ups but one looses the "interactive" functionality.
Comment 143 François Bissey 2011-09-01 23:49:27 UTC
We need help from someone who knows js or possibly jmol well. I am out of my depth here. And possibly not in the best condition to find stuff by raw mental power.
Comment 144 Steven Trogdon 2011-09-02 00:34:38 UTC
(In reply to comment #143)
> We need help from someone who knows js or possibly jmol well. I am out of my
> depth here. And possibly not in the best condition to find stuff by raw mental
> power.
Yep. No popups with just the first patch. The second patch produces the problem. And I believe somewhere around


function jmolUpdateState(n){
    //make sure the default directory is correct
//    jmolScript('x=defaultdirectory;data "directory @x";');<--this is done on launch of the applet.
    jmolStatus.defaultdirectory[n] = jmolEvaluate("x",n);

in jmol_lib.js

For some reason jmolEvaluate("x",n) isn't returning what one would like it to return?
Comment 145 Sebastian Luther (few) 2011-09-02 06:08:05 UTC
(In reply to comment #144)
> (In reply to comment #143)
> > We need help from someone who knows js or possibly jmol well. I am out of my
> > depth here. And possibly not in the best condition to find stuff by raw mental
> > power.
> Yep. No popups with just the first patch. The second patch produces the
> problem. [...]


Does the plugin work for you after omitting this patch? Without it I don't get the popups either (at least on ubunut 10.04 with firefox and chromium), but there is nothing drawn inside the window (except the Jmol Text and the Advanced Controls button).
Comment 146 Sebastian Luther (few) 2011-09-02 06:36:50 UTC
(In reply to comment #145)
> (In reply to comment #144)
> > (In reply to comment #143)
> > > We need help from someone who knows js or possibly jmol well. I am out of my
> > > depth here. And possibly not in the best condition to find stuff by raw mental
> > > power.
> > Yep. No popups with just the first patch. The second patch produces the
> > problem. [...]
> 
> 
> Does the plugin work for you after omitting this patch? Without it I don't get
> the popups either (at least on ubunut 10.04 with firefox and chromium), but
> there is nothing drawn inside the window (except the Jmol Text and the Advanced
> Controls button).

Correction. It didn't work on that system with the patch either. Apparently this is caused by the icedtea6 plugin. After installing the sun plugin it works.
Without the patch I got no popups so far. Loading a worksheet with lots of 3d plots is faster now too (the pictures show up faster).
Comment 147 Sebastian Luther (few) 2011-09-02 09:07:42 UTC
(In reply to comment #146)
> Without the patch I got no popups so far. Loading a worksheet with lots of 3d
> plots is faster now too (the pictures show up faster).

Same on Windows 7, where it got tons of popups before.
Comment 148 François Bissey 2011-09-02 12:34:22 UTC
(In reply to comment #147)
> (In reply to comment #146)
> > Without the patch I got no popups so far. Loading a worksheet with lots of 3d
> > plots is faster now too (the pictures show up faster).
> 
> Same on Windows 7, where it got tons of popups before.

So we are incriminating the second patch? It works better for you without it, so long as you use sun (now oracle) java? Can we presume then that the other patch was meant to get things working on ubuntu? I should check if the patch for the latest jmol have been updated we never know.
Comment 149 Sebastian Luther (few) 2011-09-02 12:43:03 UTC
(In reply to comment #148)
> Can we presume then that the other patch was meant to get things working on ubuntu? 

Even with the patch it didin't work on ubuntu using the icedtea plugin. I don't see this patch doing any good atm. Do you have an idea what it was supposed to fix?
Comment 150 François Bissey 2011-09-02 13:06:09 UTC
(In reply to comment #149)
> (In reply to comment #148)
> > Can we presume then that the other patch was meant to get things working on ubuntu? 
> 
> Even with the patch it didin't work on ubuntu using the icedtea plugin. I don't
> see this patch doing any good atm. Do you have an idea what it was supposed to
> fix?

It's all part of http://trac.sagemath.org/sage_trac/ticket/9238
which is a bit of a mess at the moment, to upgrade jmol to version 12.0.xx. According to the description it is to work around some safari bugs.

We kind of want to go to jmol 12.0.xx because jmoll-11 has problems with modern browser it seems. Sorting out what is useful on that ticket is not easy and I must say I didn't go through it with a fine comb. If you want to help with that, that would be most welcome. In the meantime, I'll remove the offending patch from the overlay.
Comment 151 Martin Mokrejš 2012-02-09 11:33:08 UTC
Is this package going to appear in sci overlay? Any current sage-4.8.ebuild?
Comment 152 Christopher Schwan 2012-02-09 11:37:47 UTC
(In reply to comment #151)
> Is this package going to appear in sci overlay? Any current sage-4.8.ebuild?

No, we have our own overlay at https://github.com/cschwan/sage-on-gentoo, see the README on that page for the installation procedure. An ebuild for Sage 4.8 is available.
Comment 153 gentoo 2012-07-18 14:07:52 UTC
The currently stable version doesn't work on amd64 because dependencies cannot be satisfied:

emerge: there are no ebuilds to satisfy ">=sci-libs/symmetrica-2.0".
(dependency required by "sci-mathematics/sage-4.5.3" [ebuild])
(dependency required by "sage" [argument])
Comment 154 Christopher Schwan 2012-07-18 14:20:02 UTC
Did you sync your local copy of our overlay? Some days before we pushed Sage 5.1 and your are trying to install 4.5.3 ...
Comment 155 Beetle B. 2012-07-26 03:18:47 UTC
I have some dependency conflicts. For example, sage-5.1 insists on numpy-1.5.1, yet I have another package that needs numpy-1.6.1.

Ditto for a few other packages.

Is there any way to resolve this?

Thanks.
Comment 156 François Bissey 2012-07-26 03:29:15 UTC
(In reply to comment #155)
> I have some dependency conflicts. For example, sage-5.1 insists on
> numpy-1.5.1, yet I have another package that needs numpy-1.6.1.
> 
> Ditto for a few other packages.
> 
> Is there any way to resolve this?
> 
That's a very annoying thing I am afraid. There is a problem in numpy 1.6.x with regards to sage (numpy devs have acknowledged it was something they have to fix).

Technically you can use sage with numpy-1.6. and I am tempted to change the ebuild to allow it but you should be warned that some stuff involving numpy may not work as expected unless you explicitly cast to a numpy type.
 http://trac.sagemath.org/sage_trac/ticket/11334

Which ebuilds require numpy-1.6?

Francois
Comment 157 Beetle B. 2012-07-27 01:55:16 UTC
> Which ebuilds require numpy-1.6?

  (dev-python/numpy-1.6.1-r1::gentoo, installed) pulled in by
    >=dev-python/numpy-1.6.1-r1 required by (dev-python/cython-0.15.1-r1::sage-on-gentoo, ebuild scheduled for merge)


(dev-python/pexpect-2.4-r1::sage-on-gentoo, installed) pulled in by
    >=dev-python/pexpect-2.1 required by (app-backup/duplicity-0.6.19::gentoo, installed)
Comment 158 François Bissey 2012-07-29 10:38:00 UTC
(In reply to comment #157)
> > Which ebuilds require numpy-1.6?
> 
>   (dev-python/numpy-1.6.1-r1::gentoo, installed) pulled in by
>     >=dev-python/numpy-1.6.1-r1 required by
> (dev-python/cython-0.15.1-r1::sage-on-gentoo, ebuild scheduled for merge)
> 

That's because cython has a numpy useflag requiring numpy-1.6. However that particular useflag is useless. Add:
dev-python/cython -numpy 
to /etc/portage/package.use


> 
> (dev-python/pexpect-2.4-r1::sage-on-gentoo, installed) pulled in by
>     >=dev-python/pexpect-2.1 required by
> (app-backup/duplicity-0.6.19::gentoo, installed)

Not numpy but still annoying. Thanksfully pexpect-2.4-r1 from the sage-on-gentoo overlay is functional overall if I remember correctly but it is slow compared to the earlier version.
Comment 159 Julian Ospald 2014-05-23 12:01:08 UTC
why is this not in the gentoo tree, but in an overlay?
Comment 160 François Bissey 2014-05-23 12:13:03 UTC
We have come a long way but there are still a few bits and pieces that are not quite ready for the main tree. 

Bits that are shaky:
libsingular
pexpect for which I ended up making a sage specific ebuild because we are locked into that particular version. 
ppl main tree is stuck with 0.12 so long as we keep some gcc depending on it.
jmol
Comment 161 François Bissey 2014-11-04 06:14:59 UTC
sage-ppl will be gone from the overlay in the next 24h. I may have to drop further version of sage depending on ppl<1.0 we'll see what's in the tree and in what shape.
Comment 162 Anton Kochkov 2020-01-02 03:18:25 UTC
Sage 9.0 was released since, with the Python 3 usage only:

https://wiki.sagemath.org/Python3-Switch

https://www.sagemath.org/download-source.html
Comment 163 Michael Orlitzky gentoo-dev 2020-01-02 14:38:52 UTC
(In reply to Anton Kochkov from comment #162)
> Sage 9.0 was released since, with the Python 3 usage only:
> 
> https://wiki.sagemath.org/Python3-Switch
> 
> https://www.sagemath.org/download-source.html

Now that SageMath is gaining the ability to use system packages,

  https://trac.sagemath.org/ticket/27330

I've begun to move those packages into ::gentoo from the overlay.

That means that in the meantime, at least, you can build a git checkout of sage (after installing all of those packages), and it will use the system copies.

Your best bet as an end user is still the sage-on-gentoo overlay, but as more and more things get moved to the ::gentoo tree, the overlay can shrink in size. At some point, it will finally be feasible to move the rest of it into ::gentoo.
Comment 164 Michael Orlitzky gentoo-dev 2024-03-06 13:57:24 UTC
All that remains missing are a few databases that need to be refactored into separate python packages. In the sage-on-gentoo overlay these are called,

  * sci-mathematics/sage-data-elliptic_curves
  * sci-mathematics/sage-data-graphs
  * sci-mathematics/sage-data-polytopes_db

See also: https://github.com/sagemath/sage/issues/30914