sage-4.5.rc1 released
Robert Miller
http://sage.math.washington.edu/home/release/sage-4.5/sage-4.5.rc1.tar
The only blocker ticket left is #9435, which is dubious since nobody
has been able to reproduce it. (William -- Can you give it another
try?)
I've also had my eyes on #9396 and #9475, but at this late in the game
I would rather this rc1 just work and release it as is.
This is an *actual* release candidate.
--
Robert L. Miller
http://www.rlmiller.org/
William Stein
> Hello,
>
> http://sage.math.washington.edu/home/release/sage-4.5/sage-4.5.rc1.tar
>
> The only blocker ticket left is #9435, which is dubious since nobody
> has been able to reproduce it. (William -- Can you give it another
> try?)
OK, giving it a try now on sage.math (where the last rc0's and alpha's
didn't work), on bsd.math,
and an intel 10.5 box.
>
> I've also had my eyes on #9396 and #9475, but at this late in the game
> I would rather this rc1 just work and release it as is.
>
> This is an *actual* release candidate.
>
> --
> Robert L. Miller
> http://www.rlmiller.org/
>
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to sage-release...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-release?hl=en.
>
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
John Cremona
MAKE="make -j 10", and all tests (ptestlong) passed.
John
William Stein
> On Wed, Jul 14, 2010 at 8:38 PM, Robert Miller <r...@rlmiller.org> wrote:
>> Hello,
>>
>> http://sage.math.washington.edu/home/release/sage-4.5/sage-4.5.rc1.tar
>>
>> The only blocker ticket left is #9435, which is dubious since nobody
>> has been able to reproduce it. (William -- Can you give it another
>> try?)
>
> OK, giving it a try now on sage.math (where the last rc0's and alpha's
> didn't work), on bsd.math,
> and an intel 10.5 box.
My build on bsd.math fails in exactly the same way:
...
checking how to get verbose linking output from gcc -std=gnu99... -v
checking for C libraries of gcc -std=gnu99... -lcrt1.10.6.o
-L/Users/was/build/sage-4.5.rc1/local/lib/
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64
-L/usr/lib/i686-apple-darwin10/4.2.1
-L/Users/was/build/sage-4.5.rc1/local/lib
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../.. -lSystem
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... unknown
configure: WARNING: unknown Fortran name-mangling scheme
checking whether sage_fortran appends underscores to external names... unknown
configure: error: cannot use Fortran
Error configuring R.
real 0m39.011s
user 0m10.052s
sys 0m15.875s
real 0m46.900s
user 0m13.021s
sys 0m17.206s
----
-- William
Robert Miller
> My build on bsd.math fails in exactly the same way:
1. I'm sorry if this is redundant, but can you give careful
instructions on exactly how to reproduce this? I'd like to give it a
try myself.
2. Also, did this first occur in 4.5.alpha3? Or is it a problem in
earlier releases? I'm assuming it doesn't occur in 4.4.4.
3. Possible causes of this, assuming it doesn't occur in 4.4.4:
in alpha0:
#9186 - not likely(?), updated the R spkg to have empty MAKEFLAGS
#7982 - not likely(?), updated the Fortran spkg on sunos with 64bit
in alpha1:
#9346 - not likely(?), updated Fortran again to fix #7982
#9368 - not likely(?), updated Fortran again to fix #9346, IIRC
...nothing at all relevant in alpha2, IMHO
in alpha3:
#9351 - not likely(?), touches deps, but in an irrelevant place
Once I get your instructions on reproducing this problem, I'm going to
try to narrow it down to a single alpha...
William Stein
> On Wed, Jul 14, 2010 at 11:34 PM, William Stein <wst...@gmail.com> wrote:
>> My build on bsd.math fails in exactly the same way:
>
> 1. I'm sorry if this is redundant, but can you give careful
> instructions on exactly how to reproduce this? I'd like to give it a
> try myself.
>
1. Copy the file /Users/was/bb from bsd.math.washington.edu to your computer.
2. Type ./bb
> 2. Also, did this first occur in 4.5.alpha3? Or is it a problem in
> earlier releases? I'm assuming it doesn't occur in 4.4.4.
It occurred at Sage Days 22 at MSRI. I don't know the version.
Building 4.4.4 was fine. I've started a 4.4.4 build just to be sure.
Sage does build for me now on sage.math.washington.edu. Thanks for
reverting the ecl+maxima packages, or whatever, which sorted that out.
> 3. Possible causes of this, assuming it doesn't occur in 4.4.4:
>
> in alpha0:
>
> #9186 - not likely(?), updated the R spkg to have empty MAKEFLAGS
> #7982 - not likely(?), updated the Fortran spkg on sunos with 64bit
>
> in alpha1:
>
> #9346 - not likely(?), updated Fortran again to fix #7982
> #9368 - not likely(?), updated Fortran again to fix #9346, IIRC
>
> ...nothing at all relevant in alpha2, IMHO
>
> in alpha3:
>
> #9351 - not likely(?), touches deps, but in an irrelevant place
>
> Once I get your instructions on reproducing this problem, I'm going to
> try to narrow it down to a single alpha...
I ran out of space with /scratch on that machine, so be sure to use /scratch2.
William
leif
> [...]
>
> http://sage.math.washington.edu/home/release/sage-4.5/sage-4.5.rc1.tar
> [...]
> This is an *actual* release candidate.
Python fails to "build" on both Ubuntu 9.04 x86 and x86_64 due to
testsuite errors (see below).
IIRC, I've never attempted to build Sage from scratch with
SAGE_CHECK=yes before on those systems, though.
Will continue builds with SAGE_CHECK unset...
-Leif
______________________________________________________________________
[...]
test_zlib
test test_zlib failed -- Traceback (most recent call last):
File
"/home/leif64/Sage/sage-4.5.rc1-par-j10-sage-check/spkg/build/python-2.6.4.p9/src/Lib/test/test_zlib.py",
line 84, in test_baddecompressobj
self.assertRaises(ValueError, zlib.decompressobj, 0)
AssertionError: ValueError not raised
321 tests OK.
2 tests failed:
test_distutils test_zlib
42 tests skipped:
test_aepack test_al test_applesingle test_bsddb test_bsddb185
test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
test_dbm test_dl test_gdbm test_gl test_imageop test_imgfile
test_kqueue test_linuxaudiodev test_macos test_macostools
test_normalization test_ossaudiodev test_pep277 test_py3kwarn
test_scriptpackages test_smtpnet test_socketserver test_ssl
test_startfile test_sunaudiodev test_tcl test_timeout
test_unicode_file test_urllib2net test_urllibnet test_winreg
test_winsound test_zipfile64
5 skips unexpected on linux2:
test_tcl test_dbm test_ssl test_gdbm test_bsddb
make[2]: *** [test] Error 1
make[2]: Leaving directory
`/home/leif64/Sage/sage-4.5.rc1-par-j10-sage-check/spkg/build/python-2.6.4.p9/src'
An error occurred while testing Python
*************************************
Error testing package ** python-2.6.4.p9 **
*************************************
sage: An error occurred while testing python-2.6.4.p9
Please email sage-devel http://groups.google.com/group/sage-devel
[...]
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/python-2.6.4.p9] Error 1
make[1]: Leaving directory
`/home/leif64/Sage/sage-4.5.rc1-par-j10-sage-check/spkg'
real 7m9.501s
user 3m7.540s
sys 0m48.691s
Error building Sage.
______________________________________________________________________
[This is from a log of a resumed build. The result on the other machine
is nearly the same, only differing in "323 tests OK" (instead of 321)
and "40 tests skipped" (instead of 42).]
Justin C. Walker
On Jul 14, 2010, at 11:38 , Robert Miller wrote:
> http://sage.math.washington.edu/home/release/sage-4.5/sage-4.5.rc1.tar
Built from scratch, and all tests passed on both Mac OS X, 10.5.8 and
10.6.4!
Not sure why William is having Fortran problems on 10.5, but I did not
see them.
One sidelight: the two systems are
10.5: 3.0 GHz Dual Quad Xeon [8 cores total], 4GBytes RAM; ran tests
with "-j6"
10.6: 2.66 GHz Core i7 [4 cores], 8GBytes RAM; ran tests with "-j3"
On 10.5, the tests took 123 minutes.
On 10.6, the tests took 94 minutes (both "real" time).
I believe the difference is paging (the 10.5 system runs with a lot
less free RAM most of the time).
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
If you're not confused,
You're not paying attention
--------
Dr. David Kirkby
I have looked at this and made some progress, but it is late and I'm going to
bed now. It is very odd problem indeed.
I'm in the process of building sage-4.5.rc1 using William's 'bb' script.
$SAGE_LOCAL/bin/sage_fortran should be a wrapper script for the fortran
compiler. That must have been right, as it has built many things in William's
build that need Fortran, including ATLAS, lapack, numpy etc.
We can see evidence that it was working in William's install.log
sage_fortran -fPIC -c lsame.f -o lsame.o
sage_fortran -fPIC -c lsametst.f -o lsametst.o
sage_fortran -o testlsame lsame.o lsametst.o
sage_fortran -fPIC -c slamch.f -o slamch.o
sage_fortran -fPIC -c slamchtst.f -o slamchtst.o
sage_fortran -o testslamch slamch.o lsame.o slamchtst.o
Further down we see:
checking whether sage_fortran accepts -g... yes
checking whether sage_fortran accepts -fvisibility... yes
checking whether sage_fortran accepts -g... (cached) yes
checking for sage_fortran option to produce PIC... -fno-common
checking if sage_fortran PIC flag -fno-common works... yes
checking if sage_fortran static flag -static works... no
But now that script seems to have got corrupted, as it now has in it just:
#!/bin/sh
with no compiler. Clearly that will not work, which is why R will not build for
William.
My build, using William's script, is at
/Users/kirkby/build/sage-4.5.rc1
Feel free to poke around to see if R builds for me, and in particular compare
the sage_fortran scripts
/Users/kirkby/build/sage-4.5.rc1/local/bin/sage_fortran
and
/Users/was/build/sage-4.5.rc1/local/bin/sage_fortran
I've no idea what is modifying the contents of sage_fortran. Perhaps it is R. I
can't possibly imagine how unsetting MAKEFLAGS (the only recent change in R),
could change the contents of sage_fortran. But something appears to be modifying
the script.
Dave
Nathann Cohen
Linux rebelote 2.6.32.14-127.fc12.i686.PAE #1 SMP Fri May 28 04:47:04
UTC 2010 i686 i686 i386 GNU/Linux
gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
/home/ncohen/sage$ echo $SAGE_PARALLEL_SPKG_BUILD
yes
/home/ncohen/sage$ echo $MAKE
make -j4
Nathann
Rob Beezer
make ptestlong
passes all tests on 64-bit KUbuntu 9.04 on Intel Core Duo.
Rob
John H Palmieri
> Hello,
>
> http://sage.math.washington.edu/home/release/sage-4.5/sage-4.5.rc1.tar
On a Mac OS X 10.6 box: all tests passed. I built twice, once with
SAGE_FAT_BINARY='yes' and once with this unset, no problems either
time. I haven't tried building on bsd.math in particular, but I
didn't see the problem William mentioned.
On skynet machines flavius, iras, lena, menas, sextus: all test
passed.
On skynet machine cleo: one non-repeatable failure in graphs/graph.py:
failure during ptestlong, but passes every time when run by itself.
On skynet machine cicero: still doctesting.
On skynet machines eno and taurus: gfan fails to build. I think I
reported this for 4.5.alpha1.
On t2.math with SAGE_TIMEOUT_LONG=5000 to avoid timeouts: one failure,
not completely reproducible: from the command line by itself,
sometimes it passes and sometimes it fails. This is the only failure
I've seen with 4.5.rc1 that's anywhere close to being repeatable, so
from what I've seen, it's the only potential obstacle (if it even is
an obstacle):
sage -t -long devel/sage/sage/parallel/decorate.py
**********************************************************************
File "/scratch/palmieri/sage-4.5.rc1/devel/sage-main/sage/parallel/
decorate.py", line 152\
:
sage: v = list(f([1,2,4])); v.sort(); v
Exception raised:
line 1231, in run_on\
e_test
self.run_one_example(test, example, filename, compileflags)
File "/scratch/palmieri/sage-4.5.rc1/local/bin/sagedoctest.py",
line 38, in run_one\
_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/scratch/palmieri/sage-4.5.rc1/local/bin/ncadoctest.py",
line 1172, in run_on\
e_example
compileflags, 1) in test.globs
File "<doctest __main__.example_4[9]>", line 1, in <module>
v = list(f([Integer(1),Integer(2),Integer(4)])); v.sort();
v###line 152:
sage: v = list(f([1,2,4])); v.sort(); v
File "/scratch/palmieri/sage-4.5.rc1/local/lib/python/site-
packages/sage/parallel/m\
ultiprocessing_sage.py", line 64, in parallel_iter
p = Pool(processes)
File "/scratch/palmieri/sage-4.5.rc1/local/lib/python2.6/
multiprocessing/__init__.p\
y", line 227, in Pool
return Pool(processes, initializer, initargs)
File "/scratch/palmieri/sage-4.5.rc1/local/lib/python2.6/
multiprocessing/pool.py", \
line 104, in __init__
w.start()
File "/scratch/palmieri/sage-4.5.rc1/local/lib/python2.6/
multiprocessing/process.py\
", line 104, in start
self._popen = Popen(self)
File "/scratch/palmieri/sage-4.5.rc1/local/lib/python2.6/
multiprocessing/forking.py\
", line 94, in __init__
self.pid = os.fork()
OSError: [Errno 12] Not enough space
**********************************************************************
--
John
Robert Miller
<david....@onetel.net> wrote:
> But now that script seems to have got corrupted, as it now has in it just:
>
> #!/bin/sh
>
> with no compiler.
I disagree.
> /Users/kirkby/build/sage-4.5.rc1/local/bin/sage_fortran
Here I see
{{{
#!/bin/bash
gfortran -m64 "$@"
}}}
> /Users/was/build/sage-4.5.rc1/local/bin/sage_fortran
And here I see
{{{
#!/bin/sh
sage_fortran.bin -fPIC $@
}}}
> I've no idea what is modifying the contents of sage_fortran.
It does seem to be getting modified, but there still seems to be some
compiler. I wonder what happens if we just replace the sage_fortran in
"was" with the one from "dkirkby"...
I am currently trying to reproduce this with sage-4.5.alpha3, on
bsd.math using William's script, in my account. If I can reproduce it
(I really hope so!), I will continue to bisect until I can nail down a
single ticket causing the problem. If not I guess I can try pretending
to be William, and reproducing it that way.
Robert Miller
(This is from William's build log for the R spkg, just before it shits
its pants not finding Fortran)
{{{
checking for Fortran 77 libraries of sage_fortran...
-L/Users/was/build/sage-4.5.rc1/local/lib/
-L/Users/was/build/sage-4.5.rc1/local/bin/../lib/gcc-lib/i386-apple-darwin8.10.3/4.0.3/
-L/Users/was/build/sage-4.5.rc1/local/bin/../lib/gcc-lib/i386-apple-darwin8.10.3/4.0.3
-L/Users/was/build/sage-4.5.rc1/local/lib//
-L/Users/was/build/sage-4.5.rc1/local/lib -L/usr/lib/gcc//
-L/Users/was/build/sage-4.5.rc1/local/bin/../lib/gcc-lib/i386-apple-darwin8.10.3/4.0.3///
-L/usr/lib// -lf95 -lm -lSystemStubs -lmx
}}}
If I sort out the arguments to make them easier to read I have:
-L/Users/was/build/sage-4.5.rc1/local/lib/
-L/Users/was/build/sage-4.5.rc1/local/bin/../lib/gcc-lib/i386-apple-darwin8.10.3/4.0.3/
-L/Users/was/build/sage-4.5.rc1/local/bin/../lib/gcc-lib/i386-apple-darwin8.10.3/4.0.3
-L/Users/was/build/sage-4.5.rc1/local/lib//
-L/Users/was/build/sage-4.5.rc1/local/lib
-L/usr/lib/gcc//
-L/Users/was/build/sage-4.5.rc1/local/bin/../lib/gcc-lib/i386-apple-darwin8.10.3/4.0.3///
-L/usr/lib//
-lf95
-lm
-lSystemStubs
-lmx
This looks very different from a successful build on the same machine
in Dave Kirkby's home (I think SAGE_FAT_BINARY is set in this case,
since he's using ./bb --- Dave, can you post your environment?), where
the following appears twice:
{{{
checking for Fortran 77 libraries of sage_fortran...
-L/Users/kirkby/build/sage-4.5.rc1/local/lib/
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc/i686-apple-darwin8/4.2.3/x86_64
-L/Users/kirkby/build/sage-4.5.rc1/local/lib/x86_64
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc/i686-apple-darwin8/4.2.3/../../../x86_64
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc/i686-apple-darwin8/4.2.3
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc
-L/Users/kirkby/build/sage-4.5.rc1/local/lib
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc/i686-apple-darwin8/4.2.3/../../..
-L/usr/local/lib -lgfortranbegin -lgfortran
}}}
Again sorting out the arguments I get:
{{{
-L/Users/kirkby/build/sage-4.5.rc1/local/lib/
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc/i686-apple-darwin8/4.2.3/x86_64
-L/Users/kirkby/build/sage-4.5.rc1/local/lib/x86_64
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc/i686-apple-darwin8/4.2.3/../../../x86_64
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc/i686-apple-darwin8/4.2.3
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc
-L/Users/kirkby/build/sage-4.5.rc1/local/lib
-L/Users/kirkby/build/sage-4.5.rc1/local/bin/../lib/gcc/i686-apple-darwin8/4.2.3/../../..
-L/usr/local/lib
-lgfortranbegin
-lgfortran
}}}
1. The successful build links against gfortran, while the failure
links against f95.
2. The failed build seems to be looking (outside of SAGE_ROOT) in
/usr/lib/gcc and /usr/lib while the successful one only looks in
/usr/local/lib...
I'm at a bit of a loss here, which is why I'm including Willem in the
"To" field. Any ideas?
Robert Miller
when I test these... I'll keep you all posted...
David Kirkby
> Does the following look suspect at all?
>
> (This is from William's build log for the R spkg, just before it shits
> its pants not finding Fortran)
>
> {{{
> checking for Fortran 77 libraries of sage_fortran...
> -L/Users/was/build/sage-4.5.rc1/local/lib/
> -L/Users/was/build/sage-4.5.rc1/local/bin/../lib/gcc-lib/i386-apple-darwin8.10.3/4.0.3/
> -L/Users/was/build/sage-4.5.rc1/local/bin/../lib/gcc-lib/i386-apple-darwin8.10.3/4.0.3
> -L/Users/was/build/sage-4.5.rc1/local/lib//
> -L/Users/was/build/sage-4.5.rc1/local/lib -L/usr/lib/gcc//
> -L/Users/was/build/sage-4.5.rc1/local/bin/../lib/gcc-lib/i386-apple-darwin8.10.3/4.0.3///
> -L/usr/lib// -lf95 -lm -lSystemStubs -lmx
> }}}
At first glance yes it does. I recall William saying some time back we
could actually remove g95 from the fortran package, though I'm not
aware of anyone doing it. There's a perl script which decides whether
to use gfortran or g95. When I run that I get:
[kirkby@bsd fortran-20100629]$ ./which_fortran
gfortran
It might be sensible to
* Remove g95 from that package
* Remove the perl script, and just assume the compiler is gfortran,
so whatever calls that perl script, no longer does call it, but knows
the compiler will be gfortran.
> This looks very different from a successful build on the same machine
> in Dave Kirkby's home (I think SAGE_FAT_BINARY is set in this case,
> since he's using ./bb --- Dave, can you post your environment?), where
> the following appears twice:
I'll post my environment below, which is what I get when I log in.
[kirkby@bsd ~]$ env
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=86.185.44.238 52689 22
SSH_TTY=/dev/ttys007
USER=kirkby
mount_authenticator=
MAIL=/var/mail/kirkby
PATH=/Users/mvngu/usr:/Users/mvngu/usr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/sw/bin:/usr/local/bin:/usr/texbin
HGEDITOR=vim
PWD=/Users/kirkby
EDITOR=emacs
HISTCONTROL=ignoreboth
SHLVL=1
HOME=/Users/kirkby
LOGNAME=kirkby
SSH_CONNECTION=86.185.44.238 52689 10.95.224.68 22
_=/Users/mvngu/usr/bin/env
OLDPWD=/Users/kirkby
Note my path includes some things of Minh - I forget why I included
that, but I've not changed my setup on bsd.math for ages.
[kirkby@bsd ~]$ ls -la .profile .bashrc
-rw-r--r-- 1 kirkby staff 4430 Sep 4 2009 .bashrc
-rw-r--r-- 1 kirkby staff 4432 Sep 16 2009 .profile
I guess Ming had some useful programs and rather than build them
myself, I used his setup.
I also looked at the modification times of William's .profile and
.bashrc He does not appear to have changed them either.
[kirkby@bsd was]$ ls -la .profile .bashrc
-rw-r--r-- 1 wstein 503 55 Nov 3 2008 .bashrc
-rw-r--r-- 1 wstein 503 77 Mar 1 2007 .profi
I just copied Williams script, and run it as he said. I did not
manually set SAGE_FAT_BINARY, but if his script sets it, then I guess
it was set.
I really don't understand why Sage can't use the environment variable
FC to specify a Fortran compiler, which will be accepted for
everything that uses autoconf/automake, and could be made to work for
everything else. IMHO this sage_fortran is not a great idea. Then to
add further complications, there is SAGE_FORTRAN_LIB. Again, this
should not be necessary. It's a pain in the rear end on Solairis as
one has to mess around setting it to a 32-bit or 64-bit library.
Despite my feelings about this sage_fortran script, it does not
explain why it is working for everyone except William. It's especially
strange that I built Sage on bsd.math *using William's script* and
Sage built ok. (I've not run the doctests but I did run them on an
earlier 4.5 series pre-release).
Dave
Robert Miller
> Despite my feelings about this sage_fortran script, it does not
> explain why it is working for everyone except William. It's especially
> strange that I built Sage on bsd.math *using William's script* and
> Sage built ok. (I've not run the doctests but I did run them on an
> earlier 4.5 series pre-release).
Here is William's PATH, which is different from everyone else's, in
including a Python framework from outside Sage (I remember mabshoff
complaining regularly about Frameworks screwing up builds...), and in
including /Users/was/bin:
PATH=/Library/Frameworks/Python.framework/Versions/2.6/bin:.:/Users/was/bin:/bin:/sbin:/usr/bin:/usr/sbin:/sw/bin:/usr/local/bin:/usr/texbin
Robert Miller
> On skynet machines eno and taurus: gfan fails to build. I think I
> reported this for 4.5.alpha1.
I found this on the alpha4 thread.
Can you open a new thread and (blocker) ticket for this issue and post
everything you have on it there? I think it's the last remaining
issue, because:
> sage -t -long devel/sage/sage/parallel/decorate.py
> **********************************************************************
> File "/scratch/palmieri/sage-4.5.rc1/devel/sage-main/sage/parallel/
> decorate.py", line 152\
> :
> OSError: [Errno 12] Not enough space <----------------------------------
> **********************************************************************
Robert Miller
its dependencies, since we have recently jumbled that file around.
John H Palmieri
> PS --- Let's be sure to check "deps" to make sure that gfan has all
> its dependencies, since we have recently jumbled that file around.
version I have on this computer). I don't know what version of Sage
built successfully on those machines. I'm trying again, building in
serial, not parallel, to see if that's the problem.
I've opened up a ticket: #9510.
--
John
William Stein
> On Jul 15, 6:34 am, Robert Miller <r...@rlmiller.org> wrote:
>> PS --- Let's be sure to check "deps" to make sure that gfan has all
>> its dependencies, since we have recently jumbled that file around.
>
> The "deps" for gfan hasn't changed since 4.3.4.alpha1 (the oldest
> version I have on this computer).
This doesn't prove anything, unfortunately. For example with the
"fortran on OS X" issue we just fixed, the fortran deps line hadn't
changed, but by luck the problem hadn't happened before, since --
purely by luck -- fortran always get built after python.
> I don't know what version of Sage
> built successfully on those machines. I'm trying again, building in
> serial, not parallel, to see if that's the problem.
Thanks!
It might also be interested to make a little list of the build order
of spkg's in 4.4.4 versus 4.5.rc1. This should
be easy to deduce from install.log.
William
>
> I've opened up a ticket: #9510.
>
> --
> John
>
Robert Miller
I too have a serial build going on eno, to see if I can't debug what's going on.
So far installed (it's on ntl now):
http://sage.pastebin.com/gBFwZCdi
John H Palmieri
>
> > On Jul 15, 6:34 am, Robert Miller <r...@rlmiller.org> wrote:
> >> PS --- Let's be sure to check "deps" to make sure that gfan has all
> >> its dependencies, since we have recently jumbled that file around.
>
> > The "deps" for gfan hasn't changed since 4.3.4.alpha1 (the oldest
> > version I have on this computer).
>
> This doesn't prove anything, unfortunately.
jumbling.
> For example with the
> "fortran on OS X" issue we just fixed, the fortran deps line hadn't
> changed, but by luck the problem hadn't happened before, since --
> purely by luck -- fortran always get built after python.
built before zlib and failing, revealing a flaw in deps.
> > I don't know what version of Sage
> > built successfully on those machines. I'm trying again, building in
> > serial, not parallel, to see if that's the problem.
>
> Thanks!
>
> It might also be interested to make a little list of the build order
> of spkg's in 4.4.4 versus 4.5.rc1. This should
> be easy to deduce from install.log.
has changed, or something like that.
Did 4.4.4 definitely build on all of the non-Solaris skynet machines?
I'm going to try that one now.
--
John
William Stein
>> "fortran on OS X" issue we just fixed, the fortran deps line hadn't
>> changed, but by luck the problem hadn't happened before, since --
>> purely by luck -- fortran always get built after python.
>
> Same with libpng and zlib: on one skynet machine, libpng was being
> built before zlib and failing, revealing a flaw in deps.
>
>> > I don't know what version of Sage
>> > built successfully on those machines. I'm trying again, building in
>> > serial, not parallel, to see if that's the problem.
>>
>> Thanks!
>>
>> It might also be interested to make a little list of the build order
>> of spkg's in 4.4.4 versus 4.5.rc1. This should
>> be easy to deduce from install.log.
>
> It's also possible that something in /usr/local/skynet_bash_profile
Nope:
[wstein@eno eno]$ ls -lh /usr/local/skynet_bash_profile
-rwxrwxrwx 1 root root 5.8K 2010-04-28 12:19 /usr/local/skynet_bash_profile
(Note the modification date.)
>
> Did 4.4.4 definitely build on all of the non-Solaris skynet machines?
> I'm going to try that one now.
>
> --
> John
>
John H Palmieri
> John,
>
> I too have a serial build going on eno, to see if I can't debug what's going on.
>
> So far installed (it's on ntl now):
>
> http://sage.pastebin.com/gBFwZCdi
of the problem reported in #8679: when I run using "screen",
LD_LIBRARY_PATH is not set. Trying again...
--
John
John H Palmieri
> On Jul 15, 9:09 am, Robert Miller <r...@rlmiller.org> wrote:
>
> > John,
>
> > I too have a serial build going on eno, to see if I can't debug what's going on.
>
> > So far installed (it's on ntl now):
>
> >http://sage.pastebin.com/gBFwZCdi
>
> My serial builds are getting stuck on linbox. I think this is because
> of the problem reported in #8679
--
John
John H Palmieri
and I've closed the trac ticket. The problem was a bad
LD_LIBRARY_PATH. On eno, if I run "screen", then as I said earlier,
LD_LIBRARY_PATH is not set at all (maybe screen doesn't
run .bash_profile?), and this caused gfan to fail to build. On
taurus, LD_LIBRARY_PATH had an error in it (see my recent post on the
sage/skynet google group), and this caused gfan to fail to build.
In both cases, after setting LD_LIBRARY_PATH to the correct value, all
of Sage built without problems.
--
John
Robert Miller
On Thu, Jul 15, 2010 at 12:28 AM, leif <not.r...@online.de> wrote:
> Python fails to "build" on both Ubuntu 9.04 x86 and x86_64 due to
> testsuite errors (see below).
Thanks for the report. This is tracked on #9294, I have added a
reference to this discussion there.
Dr. David Kirkby
> Leif,
>
> On Thu, Jul 15, 2010 at 12:28 AM, leif<not.r...@online.de> wrote:
>> Python fails to "build" on both Ubuntu 9.04 x86 and x86_64 due to
>> testsuite errors (see below).
>
> Thanks for the report. This is tracked on #9294, I have added a
> reference to this discussion there.
>
>
>
>
I believe you have made a mistake about the trac number - that seems unrelated.
A few failures on python seem almost inevitable - I don't think anyone will ever
get all tests to pass.
Dave
Robert Miller
<david....@onetel.net> wrote:
>>> Python fails to "build" on both Ubuntu 9.04 x86 and x86_64 due to
>>> testsuite errors (see below).
>>
>> Thanks for the report. This is tracked on #9294, I have added a
>> reference to this discussion there.
>
> I believe you have made a mistake about the trac number - that seems
> unrelated.
#9297, my mistake.
leif
> On Thu, Jul 15, 2010 at 12:28 AM, leif <not.r...@online.de> wrote:
>> Python fails to "build" on both Ubuntu 9.04 x86 and x86_64 due to
>> testsuite errors (see below).
[Sage build attempts with SAGE_CHECK="yes"]
> Thanks for the report. This is tracked on #9294, I have added a
> reference to this discussion there.
Thanks, feel free to cc me in such cases.
#9294 (and #9492) seem rather unrelated... ;-)
After a while (I'll add some keywords there), I've found:
"Test failures of Python (2.6.4.p9) on Solaris 10 SPARC (32-bit)"
http://trac.sagemath.org/sage_trac/ticket/9297
and
"Test failures of Python (2.6.4.p9) on OpenSolaris x64 (64-bit)"
http://trac.sagemath.org/sage_trac/ticket/9299
The former is the one Robert Miller meant and is more generic than its
title suggests, and contains a link to this sage-devel thread:
"Test your Python build"
http://groups.google.co.uk/group/sage-devel/browse_thread/thread/b7856076ea5aefbd/8d381b77e4d461cb
I've also seen users worrying about Python modules not built though Sage
had apparently been built successfully (but without SAGE_CHECK=yes) on
#sage-devel, but most users will not even notice that.
$ grep -A5 Failed install.log
should show what's "missing" (even for successful builds).
The issue is not specific to Sage 4.5.*.
Further discussion at #9297, or perhaps a follow-up ticket.
-Leif