We've released Sage 4.5.3.alpha1.
Source archive:
http://sage.math.washington.edu/home/release/sage-4.5.3.alpha1/sage-4.5.3.alpha1.tar
Upgrade path:
http://sage.math.washington.edu/home/release/sage-4.5.3.alpha1/sage-4.5.3.alpha1/
The long doctests pass for me on {bsd,redhawk,sage,t2}.math.washington.edu.
Please build, test, and report! We'd love to hear about your
experiences with this release.
The 4.5.3 series is now in feature freeze and blocker squeeze.
== Known problems ==
The current list of blockers is at
== Tickets ==
Closed tickets:
#9515: Martin Albrecht: make an optional spkg for PyCryptoPlus [Reviewed
by David Joyner]
Merged in sage-4.5.3.alpha1:
#8059: Martin Albrecht: Update Singular spkg to release 3-1-1-4
[Reviewed by David Kirkby, Simon King, William Stein, John Palmieri]
#9358: David Kirkby: zn_poly passes all tests on on Solaris 10 64-bit
SPARC, but fails to install [Reviewed by John Palmieri]
#9475: Martin Albrecht, Leif Leonhardy: update M4RI to newest upstream
release [Reviewed by Leif Leonhardy, David Kirkby, Mariah Lenox]
#9506: Martin Albrecht: include libSingular error messages in exceptions
[Reviewed by William Stein]
#9508: David Kirkby: Fix all ATLAS build problems on Solaris/OpenSolaris
[Reviewed by John Palmieri]
#9567: Ben Edwards, Nathann Cohen: Networkx-1.1 spkg [Reviewed by Ben
Edwards, Nathann Cohen, Robert Miller]
#9643: David Kirkby: Force ECL to disable assembly code on Solaris 10
x86 as it does on OpenSolaris [Reviewed by Fran�ois Bissey]
#9712: Mitesh Patel: Make building PolyBoRi depend on GD [Reviewed by
Leif Leonhardy]
#9717: Alexander Dreyer, Martin Albrecht, Michael Brickenstein: fix
variable substitution in PolyBoRi + finding M4RI [Reviewed by Martin
Albrecht, Alexander Dreyer, Leif Leonhardy]
> Hi!
>
> We've released Sage 4.5.3.alpha1.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.5.3.alpha1/sage-4.5.3.alpha1.tar
Full build on Mac OS X, 10.5.8 (Dual Quad Xeon). Built w/o problems,
all tests passed!
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
Experience is what you get
when you don't get what you want.
--------
Upgraded from sage-4.4.1 without problems, and passed "make ptestlong"
with 10 threads on
[aghitza@cerelia sage-4.4.1]$ uname -a
Linux cerelia.ms.unimelb.edu.au 2.6.18-194.11.1.el5 #1 SMP Tue Jul 27 05:45:06 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Best,
Alex
--
Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia
The same is true of #9689.
It would be nice to clear up two these numerical noise issues.
Dave
Ubuntu 7.10 x86 (Pentium 4, rebuilt gcc 4.2.1, native code, O2):
make build: OK (parallel build with 2 jobs)
make doc: OK (only some warnings because dvipng isn't installed)
make testlong: OK (All tests passed.)
Fedora 13 x86 (Pentium 4 Prescott, gcc 4.4.4, native code, O2):
make build: OK (parallel build with 6 jobs)
make doc: OK
make ptestlong: OK (All tests passed; 2 threads)
Ubuntu 9.04 x86_64 (Core2, gcc 4.3.3, native code, O2):
make build: OK (sequential build)
make doc: OK
make testlong: OK (All tests passed.)
-Leif
> Hi!
>
> We've released Sage 4.5.3.alpha1.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.5.3.alpha1/sage-4.5.3.alpha1.tar
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.5.3.alpha1/sage-4.5.3.alpha1/
Full build on Mac OS X, 10.6.8 (Core i7), completed w/o problems.
All tests passed.
Forgot to mention, I used
MAKE="make -j{3,6}" SAGE_PARALLEL_SPKG_BUILD=yes make ptestlong
on the two systems for testing. That cut the time *way* down (factor
of 4 on the 10.5 system; a factor of 2 on the 10.6 system).
Cool!
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
Men are from Earth.
Women are from Earth.
Deal with it.
--------
Also:
Ubuntu 9.04 x86_64 (Core2, gcc 4.3.3, native code, O3):
make build: OK (parallel build with 24 jobs)
make doc: OK
make ptestlong: OK (All tests passed; 4 threads)
(Same for Sage 4.6.prealpha1, built with 32 jobs; see #9343.)
-Leif
Could the problem be hard-coded absolute paths in
SAGE_LOCAL/lib/pkgconfig/*.pc
?
Currently, when SAGE_LOCAL/bin/sage-location detects a moved
installation, it calls its update_library_files (among other functions),
which
1. Runs 'ranlib SAGE_LOCAL/lib/*.a'. Note: This misses
SAGE_LOCAL/lib/python2.6/config/libpython2.6.a
2. Updates hard-coded absolute "libdir=" paths in SAGE_LOCAL/lib/*.la.
Should we also update other files?
Dear release mixer,
shouldn't 4.5.3 contain a fix for #9644 (spaces in SAGE_ROOT [1]), too?
We have at least one patch that slightly hardens the scripts in order to
print a more accurate error message.
To all: ;-)
Unfortunately, there aren't yet patches for/corrections to README.txt,
the Sage Installation Guide [2] and the "Quick Download and Install
Guide"[sic] Wiki page [3].
Also, we could put a little note on the download pages for binaries
(e.g. [4]), telling that the tarball should not be extracted/installed
into a folder containing spaces. (These pages contain a link to [3].)
Cheers,
-Leif
[1] http://trac.sagemath.org/sage_trac/ticket/9644
[2] http://www.sagemath.org/doc/installation/index.html, especially:
* http://www.sagemath.org/doc/installation/quick-guide.html
* http://www.sagemath.org/doc/installation/binary.html
*
http://www.sagemath.org/doc/installation/source.html#steps-to-install-from-source
[3] http://wiki.sagemath.org/DownloadAndInstallationGuide
[4] http://boxen.math.washington.edu/sage/linux/64bit/index.html
I just noticed that this is already
http://trac.sagemath.org/sage_trac/ticket/9210
>> Currently, when SAGE_LOCAL/bin/sage-location detects a moved
>> installation, it calls its update_library_files (among other functions),
>> which
>>
>> 1. Runs 'ranlib SAGE_LOCAL/lib/*.a'. Note: This misses
>>
>> SAGE_LOCAL/lib/python2.6/config/libpython2.6.a
>>
>> 2. Updates hard-coded absolute "libdir=" paths in SAGE_LOCAL/lib/*.la.
>>
>> Should we also update other files?
>
> Apparently - but why doesn't this cause problems for other people, or
> even myself when I upgrade elsewhere? I always rename SAGE_HOME or
> whatever to the actual release number it is when I upgrade, so the
> sage-location (please wait...) runs each time.
What exact procedure ('mv' commands, etc.) do you follow when you
upgrade Sage?
Ticket #9644 will have to wait for 4.6.alpha1, at the earliest. Of
course, this shouldn't discourage potential contributors!