Sage 4.5.3.alpha1 released
Mitesh Patel
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]
Justin C. Walker
On Aug 15, 2010, at 15:53 , Mitesh Patel wrote:
> 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.
--------
Alex Ghitza
> We've released Sage 4.5.3.alpha1.
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
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
Marshall Hampton
is a core-i7 860.
-Marshall
On Aug 15, 5:53 pm, Mitesh Patel <qed...@gmail.com> wrote:
> Hi!
>
> We've released Sage 4.5.3.alpha1.
>
> Source archive:
>
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.5.3.alpha1/sage-4...
> 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
>
John H Palmieri
> Hi!
>
> We've released Sage 4.5.3.alpha1.
>
> Source archive:
>
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.5.3.alpha1/sage-4...
>
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
machines, successfully:
cicero, upgrade, all tests passed
cleo, scratch, all tests passed
eno, upgrade, all tests passed
flavius, upgrade, all tests passed
fulvia 32-bit, scratch, the usual failures (x86 on solaris: numerical
noise & sympow, see below)
iras, upgrade, one failure (genus.pyx, reported before, see below)
lena, scratch, all tests passed
mark, scratch, tests still in progress
mark2, upgrade, tests still in progress
menas, scratch, all tests passed
sextus, upgrade, all tests passed
taurus, scratch, all tests passed
taurus, upgrade, all tests passed
OS X 10.6.4, scratch, all tests passed
OS X 10.6.4, upgrade, all tests passed
For fulvia (Solaris on x86), at least one of the numerical noise
issues (#9735) is patched with a positive review. I would request
that this be included in 4.5.3: it just adds some ellipses to a
doctest, so shouldn't cause any new problems.
On iras (ia64-Linux-suse), I get the following failure, but
inconsistently. This was reported before, but since it doesn't happen
repeatably, it hasn't been fixed.
File "/home/palmieri/iras/sage-4.5.2.rc1/devel/sage-main/sage/graphs/
genus.pyx", line 129:
sage: get_memory_usage(t)
Expected:
0.0
Got:
-0.296875
--
John
Rob Beezer
make ptestlong
64-bit KUbuntu 9.10 on Intel Core Duo
$ echo $MAKE; echo $SAGE_PARALLEL_SPKG_BUILD
make -j4
yes
Rob
Dr. David Kirkby
>
> For fulvia (Solaris on x86), at least one of the numerical noise
> issues (#9735) is patched with a positive review. I would request
> that this be included in 4.5.3: it just adds some ellipses to a
> doctest, so shouldn't cause any new problems.
The same is true of #9689.
It would be nice to clear up two these numerical noise issues.
Dave
leif
> We've released Sage 4.5.3.alpha1.
> 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.
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
Justin C. Walker
On Aug 15, 2010, at 15:53 , Mitesh Patel wrote:
> 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.
--------
leif
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
John H Palmieri
>
> We've released Sage 4.5.3.alpha1.
>
> Source archive:
>
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.5.3.alpha1/sage-4...
>
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
sage -t -long devel/sage/sage/matrix/matrix2.pyx
**********************************************************************
File "/home/palmieri/t2/sage-4.5.3.alpha1/devel/sage-main/sage/matrix/
matrix2.pyx", line 6406:
sage: all(imag(e) < 1e-15 for e in eigs)
Expected:
True
Got:
False
This looks like numerical noise: if I replace 1e-15 by 1e-14, it
passes. Has anyone else seen this? Could it possibly be dependent on
ATLAS (e.g., the load on the system when it's tuning itself)?
--
John
Mitesh Patel
John H Palmieri
troubleshoot, since ATLAS takes 10 hours to build on t2. Since
replacing 1e-15 by 1e-14 seems to fix it, one question is whether
that's a reasonable loss of precision.
--
John
kcrisman
Upgrading on PPC OS X 10.4 from 4.5.2.rc1 (I think) caused a (weird)
problem I've seen before, this time in PolyBoRi (I can't remember
where it was before). The problem is that somehow a previous name of
the folder is being referenced - is there someplace that Sage is
storing this, or at least some of the packages? I don't get how it's
possible that a new spkg would "remember" this. The whole relevant
part is below, but here is the part to notice:
-L/Users/crisman/Desktop/sage-4.5.2.rc1/local/lib -L/Users/crisman/
Desktop/sage-4.5.1/local/lib -L/Users/crisman/Desktop/sage-4.5.1/local/
lib/python2.6/config -Lpolybori -Lgroebner -LCudd -lm -lgd -lgd -
lpng12 -lz -lm4ri -lgd -lgd -lpng12 -lz -lm4ri
sage-4.5.2.rc1 is the current, sage-4.5.1 is what the folder was named
when I first downloaded and compiled it. Small wonder this is not
being found!
I don't know if this is worth a ticket or not - I can reproduce it on
my machine but it may be specific to mine only, I've not seen this
reported elsewhere. But what the heck?
- kcrisman
g++ -o groebner/groebner -bundle Cudd/obj/cuddObj.os Cudd/util/
cpu_stats.os Cudd/util/cpu_time.os Cudd/util/datalimit.os Cudd/util/
getopt.os Cudd/util/pathsearch.os Cudd/util/pipefork.os Cudd/util/
prtime.os Cudd/util/ptime.os Cudd/util/safe_mem.os Cudd/util/state.os
Cudd/util/strsav.os Cudd/util/stub.os Cudd/util/texpand.os Cudd/util/
tmpfile.os Cudd/cudd/cuddAddAbs.os Cudd/cudd/cuddAddApply.os Cudd/cudd/
cuddAddFind.os Cudd/cudd/cuddAddInv.os Cudd/cudd/cuddAddIte.os Cudd/
cudd/cuddAddNeg.os Cudd/cudd/cuddAddWalsh.os Cudd/cudd/cuddAndAbs.os
Cudd/cudd/cuddAnneal.os Cudd/cudd/cuddApa.os Cudd/cudd/cuddAPI.os Cudd/
cudd/cuddApprox.os Cudd/cudd/cuddBddAbs.os Cudd/cudd/cuddBddCorr.os
Cudd/cudd/cuddBddIte.os Cudd/cudd/cuddBridge.os Cudd/cudd/cuddCache.os
Cudd/cudd/cuddCheck.os Cudd/cudd/cuddClip.os Cudd/cudd/cuddCof.os Cudd/
cudd/cuddCompose.os Cudd/cudd/cuddDecomp.os Cudd/cudd/cuddEssent.os
Cudd/cudd/cuddExact.os Cudd/cudd/cuddExport.os Cudd/cudd/cuddGenCof.os
Cudd/cudd/cuddGenetic.os Cudd/cudd/cuddGroup.os Cudd/cudd/
cuddHarwell.os Cudd/cudd/cuddInit.os Cudd/cudd/cuddInteract.os Cudd/
cudd/cuddLCache.os Cudd/cudd/cuddLevelQ.os Cudd/cudd/cuddLinear.os
Cudd/cudd/cuddLiteral.os Cudd/cudd/cuddMatMult.os Cudd/cudd/
cuddPriority.os Cudd/cudd/cuddRead.os Cudd/cudd/cuddRef.os Cudd/cudd/
cuddReorder.os Cudd/cudd/cuddSat.os Cudd/cudd/cuddSign.os Cudd/cudd/
cuddSolve.os Cudd/cudd/cuddSplit.os Cudd/cudd/cuddSubsetHB.os Cudd/
cudd/cuddSubsetSP.os Cudd/cudd/cuddSymmetry.os Cudd/cudd/cuddTable.os
Cudd/cudd/cuddUtil.os Cudd/cudd/cuddWindow.os Cudd/cudd/
cuddZddCount.os Cudd/cudd/cuddZddFuncs.os Cudd/cudd/cuddZddGroup.os
Cudd/cudd/cuddZddIsop.os Cudd/cudd/cuddZddLin.os Cudd/cudd/
cuddZddMisc.os Cudd/cudd/cuddZddPort.os Cudd/cudd/cuddZddReord.os Cudd/
cudd/cuddZddSetop.os Cudd/cudd/cuddZddSymm.os Cudd/cudd/cuddZddUtil.os
Cudd/mtr/mtrBasic.os Cudd/mtr/mtrGroup.os Cudd/st/st.os Cudd/epd/
epd.os polybori/src/BoolePolyRing.os polybori/src/BooleEnv.os polybori/
src/BoolePolynomial.os polybori/src/BooleVariable.os polybori/src/
CErrorInfo.os polybori/src/PBoRiError.os polybori/src/
CCuddFirstIter.os polybori/src/CCuddNavigator.os polybori/src/
BooleMonomial.os polybori/src/BooleSet.os polybori/src/LexOrder.os
polybori/src/CCuddLastIter.os polybori/src/CCuddGetNode.os polybori/
src/BooleExponent.os polybori/src/DegLexOrder.os polybori/src/
DegRevLexAscOrder.os polybori/src/pbori_routines.os polybori/src/
BlockDegLexOrder.os polybori/src/BlockDegRevLexAscOrder.os groebner/
src/groebner.os groebner/src/literal_factorization.os groebner/src/
randomset.os groebner/src/pairs.os groebner/src/groebner_alg.os
groebner/src/fglm.os groebner/src/polynomial_properties.os groebner/
src/lexbuckets.os groebner/src/dlex4data.os groebner/src/
dp_asc4data.os groebner/src/lp4data.os groebner/src/nf.os groebner/src/
interpolate.os -L/Users/crisman/Desktop/sage-4.5.2.rc1/local/lib -L/
Users/crisman/Desktop/sage-4.5.1/local/lib -L/Users/crisman/Desktop/
sage-4.5.1/local/lib/python2.6/config -Lpolybori -Lgroebner -LCudd -lm
-lgd -lgd -lpng12 -lz -lm4ri -lgd -lgd -lpng12 -lz -lm4ri
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning -L: directory
name (/Users/crisman/Desktop/sage-4.5.1/local/lib) does not exist
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning -L: directory
name (/Users/crisman/Desktop/sage-4.5.1/local/lib/python2.6/config)
does not exist
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning can't open
dynamic library: /Users/crisman/Desktop/sage-4.5.1/local/lib/
libfreetype.6.dylib referenced from: /Users/crisman/Desktop/
sage-4.5.2.rc1/local/lib/libgd.dylib (checking for undefined symbols
may be affected) (No such file or directory, errno = 2)
<snip>
python -c "import py_compile; py_compile.compile('/Users/crisman/
Desktop/sage-4.5.2.rc1/local/lib/python2.6/site-packages/polybori/
PyPolyBoRi.py')"
dyld: Library not loaded: /Users/crisman/Desktop/sage-4.5.1/local/lib/
libpython2.6.dylib
Referenced from: /Users/crisman/Desktop/sage-4.5.2.rc1/local/bin/
python
Reason: image not found
scons: *** [/Users/crisman/Desktop/sage-4.5.2.rc1/local/lib/python2.6/
site-packages/polybori/PyPolyBoRi.pyc] Error -5
Rob Beezer
on 64-bit Ubuntu 10.04 on Intel Core-i7
Mitesh Patel
> Upgrading on PPC OS X 10.4 from 4.5.2.rc1 (I think) caused a (weird)
> problem I've seen before, this time in PolyBoRi (I can't remember
> where it was before). The problem is that somehow a previous name of
> the folder is being referenced - is there someplace that Sage is
> storing this, or at least some of the packages? I don't get how it's
> possible that a new spkg would "remember" this. The whole relevant
> part is below, but here is the part to notice:
>
> -L/Users/crisman/Desktop/sage-4.5.2.rc1/local/lib -L/Users/crisman/
> Desktop/sage-4.5.1/local/lib -L/Users/crisman/Desktop/sage-4.5.1/local/
> lib/python2.6/config -Lpolybori -Lgroebner -LCudd -lm -lgd -lgd -
> lpng12 -lz -lm4ri -lgd -lgd -lpng12 -lz -lm4ri
>
> sage-4.5.2.rc1 is the current, sage-4.5.1 is what the folder was named
> when I first downloaded and compiled it. Small wonder this is not
> being found!
>
> I don't know if this is worth a ticket or not - I can reproduce it on
> my machine but it may be specific to mine only, I've not seen this
> reported elsewhere. But what the heck?
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?
kcrisman
>
> > -L/Users/crisman/Desktop/sage-4.5.2.rc1/local/lib -L/Users/crisman/
> > Desktop/sage-4.5.1/local/lib -L/Users/crisman/Desktop/sage-4.5.1/local/
> > lib/python2.6/config -Lpolybori -Lgroebner -LCudd -lm -lgd -lgd -
> > lpng12 -lz -lm4ri -lgd -lgd -lpng12 -lz -lm4ri
>
> > sage-4.5.2.rc1 is the current, sage-4.5.1 is what the folder was named
> > when I first downloaded and compiled it. Small wonder this is not
> > being found!
>
> 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?
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.
- kcrisman
leif
> We've released Sage 4.5.3.alpha1.
> The 4.5.3 series is now in feature freeze and blocker squeeze.
>
>
> == Known problems ==
>
> The current list of blockers is at
>
> http://trac.sagemath.org/sage_trac/query?priority=blocker&group=status&groupdesc=1&milestone=sage-4.5.3
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
Mitesh Patel
>>> -L/Users/crisman/Desktop/sage-4.5.2.rc1/local/lib -L/Users/crisman/
>>> Desktop/sage-4.5.1/local/lib -L/Users/crisman/Desktop/sage-4.5.1/local/
>>> lib/python2.6/config -Lpolybori -Lgroebner -LCudd -lm -lgd -lgd -
>>> lpng12 -lz -lm4ri -lgd -lgd -lpng12 -lz -lm4ri
>>
>>> sage-4.5.2.rc1 is the current, sage-4.5.1 is what the folder was named
>>> when I first downloaded and compiled it. Small wonder this is not
>>> being found!
>
>> Could the problem be hard-coded absolute paths in
>>
>> SAGE_LOCAL/lib/pkgconfig/*.pc
>>
>> ?
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?
kcrisman
On Aug 19, 6:25 pm, Mitesh Patel <qed...@gmail.com> wrote:
> On 08/19/2010 07:12 AM, kcrisman wrote:
>
> >>> -L/Users/crisman/Desktop/sage-4.5.2.rc1/local/lib -L/Users/crisman/
> >>> Desktop/sage-4.5.1/local/lib -L/Users/crisman/Desktop/sage-4.5.1/local/
> >>> lib/python2.6/config -Lpolybori -Lgroebner -LCudd -lm -lgd -lgd -
> >>> lpng12 -lz -lm4ri -lgd -lgd -lpng12 -lz -lm4ri
>
> >>> sage-4.5.2.rc1 is the current, sage-4.5.1 is what the folder was named
> >>> when I first downloaded and compiled it. Small wonder this is not
> >>> being found!
>
> >> Could the problem be hard-coded absolute paths in
>
> >> SAGE_LOCAL/lib/pkgconfig/*.pc
>
> >> ?
>
> I just noticed that this is already
>
> http://trac.sagemath.org/sage_trac/ticket/9210
prefix=/Users/crisman/Desktop/sage-4.5.1/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: FreeType 2
Description: A free, high-quality, and portable font engine.
Version: 9.16.3
Requires:
Libs: -L${libdir} -lfreetype -lz
Cflags: -I${includedir}/freetype2 -I${includedir}
Just like on the ticket. In fact everything in that directory has the
'original' directory from when it was built in them. I can check if
something isn't done right with the local/lib/python2.6/config
directory too, not sure which file to look at.
>> 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?
Then rename (on Mac) the folder from sage-x.y.z to sage-x.y.z+1 or
whatever. I am pretty sure this is the same as mv sage-x.y.z sage-
x.y.z+1, or whatever the recursive version of that is.
Then the next time I upgrade, I do sage-upgrade, and <boom> with
something. (Well, I don't know if it happens the first time... and to
be honest, this machine is far too slow to actually try it from
scratch.) I think after having looked at some other posts of mine
from earlier that this has only happened on this particular computer,
though.
Thanks for helping track this down.
- kcrisman
Mitesh Patel
> Mitesh Patel wrote:
>> We've released Sage 4.5.3.alpha1.
>> [...]
>> The 4.5.3 series is now in feature freeze and blocker squeeze.
>>
>> == Known problems ==
>>
>> The current list of blockers is at
>>
>> http://trac.sagemath.org/sage_trac/query?priority=blocker&group=status&groupdesc=1&milestone=sage-4.5.3
>> [...]
>
> [1] http://trac.sagemath.org/sage_trac/ticket/9644
Ticket #9644 will have to wait for 4.6.alpha1, at the earliest. Of
course, this shouldn't discourage potential contributors!