sage-4.7.alpha4 released

53 views
Skip to first unread message

Jeroen Demeyer

unread,
Apr 11, 2011, 9:45:21 AM4/11/11
to sage-r...@googlegroups.com
ear Sage lovers,

We're releasing Sage 4.7.alpha4.

Source archive:

http://sage.math.washington.edu/home/release/sage-4.7.alpha4/sage-4.7.alpha4.tar

Upgrade path:

http://sage.math.washington.edu/home/release/sage-4.7.alpha4/sage-4.7.alpha4/

Please build, test, and report! We'd love to hear about your
experiences with this release.

== Known issues ==

* Some doctests fail on bsd.math (OS X 10.6 i386), when compiling in
64-bit mode due to SAGE64 verbosity. This is #10303.

== Tickets ==

* We closed 151 tickets in this release. For details, see

http://sage.math.washington.edu/home/release/sage-4.7.alpha4/tickets.html

Closed tickets:

#6055: Top level README.txt is wrong reguarding Solaris [Reviewed by
David Kirkby]
#6794: doctest failure on 32-bit Solaris 10 SPARC in
sage/sage/interfaces/rubik.py due to upgrade to Maxima 5.19.1 [Reviewed
by David Kirkby]
#7062: ECL snapshot of 13th Sept 2009 fails with Sun Studio 12.1
[Reviewed by David Kirkby]
#7127: libgcrypt fails to build in 64-bit on Solaris SPARC with gcc
[Reviewed by David Kirkby]
#7128: zlib-1.2.3.p4 always builds 32-bit binaries on Solaris. [Reviewed
by Jaap Spies, David Kirkby]
#7129: libgpg_error-1.6.p2 always builds 32-bit binaries on Solaris.
[Reviewed by David Kirkby]
#7134: ntl 5.4.2.p9 always builds 32-bit libraries on Solaris. [Reviewed
by David Kirkby]
#7866: zn_poly on Open Solaris reports #error Not nails-safe yet
[Reviewed by David Kirkby]
#8575: Sphinx should raise warning in case of ill formated enumerated
lists [Reviewed by Florent Hivert]
#9021: gdmodule not building on OpenSolaris x64. [Reviewed by David Kirkby]
#9099: Maxima fails to build on OpenSolaris x64, though ECL does.
[Reviewed by David Kirkby]
#9840: link-editor thinks ECL library contains non-pic code on *all*
Solaris/OpenSolaris releases - causes problems on 64-bit [Reviewed by
David Kirkby]
#9978: David Kirkby: Add a test for the maths library in the 'prereq'
script. [Reviewed by Nicolas M. Thiéry]
#10008: List / Iter on the element of a MatrixGroup over number field.
[Reviewed by David Loeffler]
#11086: lcalc 20100428-1.23.p5 fails to build on OpenSolaris with gcc
4.6.0 [Reviewed by Volker Braun]

Merged in sage-4.7.alpha4:

#4983: John Palmieri: replace subdivisions attribute for matrices with a
function [Reviewed by Rob Beezer]
#8288: Nicolas Borie: Depth/Breadth improvement for SearchForest
[Reviewed by Florent Hivert, Minh Van Nguyen, Nicolas M. Thiéry]
#8552: Dan Drake, John Palmieri: replace os.system calls in latex.py
with appropriate replacements [Reviewed by John Palmieri, Dan Drake]
#8931: Flavia Stan: desolve fails when assumptions required [Reviewed by
Karl-Dieter Crisman]
#9053: Moritz Minzlaff: Sage's new generic HNF doesn't quite work right
wrt the free modules code [Reviewed by Keshav Kini]
#9125: John Palmieri: more examples of simplicial complexes: RP^n, CP^2,
etc. [Reviewed by Robert Goss, Marshall Hampton]
#9232: Jonathan Gutow, Volker Braun: jmol on commandline broken
[Reviewed by Jason Grout, Karl-Dieter Crisman, Volker Braun]
#9306: Simon Spicer: round incoherent with ceil/floor on rational
numbers [Reviewed by Keshav Kini]
#9370: John Palmieri, Christian Stump: customize printing of elements in
CombinatorialFreeModules [Reviewed by Franco Saliola, Christian Stump]
#9949: Nicolas Borie: Add major index (polynomial) for the symmetric
group [Reviewed by Mike Hansen, Jason Bandlow]
#10039: Volker Braun: Make Parma Polyhedra Library a standard library
[Reviewed by Marshall Hampton, Jeroen Demeyer]
#10246: Karl-Dieter Crisman: Can't get symbol from callable function x
|--> x [Reviewed by Mike Hansen]
#10280: Chris Wuthrich: error in precision of p-adic L-functions
[Reviewed by William Stein]
#10470: Rob Beezer: Listing an infinite vector space just hangs
[Reviewed by John Palmieri]
#10548: Robert Bradshaw: The coercion model is keeping references to
tracebacks which causes memory leaks. [Reviewed by Maarten Derickx]
#10652: Nicolas M. Thiéry: Add support for uploading static html doc
page as a worksheet in the notebook [Reviewed by Jason Grout]
#10683: Rob Beezer: Hermitian inner product [Reviewed by Karl-Dieter
Crisman]
#10737: Rob Beezer: Extended echelon form of a matrix [Reviewed by John
Palmieri]
#10752: John Palmieri: Matrix pivots are cached, should be immutable
[Reviewed by Rob Beezer]
#10776: Niles Johnson: poset top() function breaks when top element has
boolean value False [Reviewed by Andrey Novoseltsev]
#10836: Karl-Dieter Crisman, William Stein, Jeroen Demeyer: primitive
root is broken [Reviewed by William Stein, Karl-Dieter Crisman, Jeroen
Demeyer]
#10863: Rob Beezer: Add check for orthogonal/unitary matrices [Reviewed
by Martin Raum]
#10876: Rob Beezer: Create elementary matrices [Reviewed by Karl-Dieter
Crisman]
#10885: Nathann Cohen, Yann Laigle-Chapuy: Floyd-Warshall algorithm in
Cython [Reviewed by Nathann Cohen, Yann Laigle-Chapuy]
#10886: Robert Miller: DisjointSet: number of sets function [Reviewed by
Alexandre Blondin Massé, Sébastien Labbé]
#10890: Olivier Mallet: wrong type for the element of
PartitionsInBox(h,0) [Reviewed by Florent Hivert]
#10892: Volker Braun: lcalc fails to build with gcc-4.6 [Reviewed by
David Kirkby]
#10937: William Stein, Jeroen Demeyer: bug in Dokchitser L.init_coeffs
[Reviewed by Robert Bradshaw]
#10958: Ryan Hinton: BipartiteGraph constructor without *args ignores
**kwds [Reviewed by Nathann Cohen]
#10969: Jeroen Demeyer: Mark more doctests # long time [Reviewed by
Florent Hivert]
#10974: Rob Beezer: Overhaul matrix stack, augment [Reviewed by Keshav Kini]
#11000: Ivan Andrus: GAP interface doesn't handle input with multiple
lines correctly [Reviewed by Rob Beezer, Keshav Kini]
#11004: Rob Beezer: Make subdivisions optional on tensor product of
matrices [Reviewed by John Palmieri]
#11027: Rob Beezer: Schur matrix decomposition over RDF/CDF [Reviewed by
Martin Raum]
#11070: David Kirkby: Update prereq so that SAGE_PORT does not need
setting on Solaris x86 [Reviewed by John Palmieri]
#11079: Jeroen Demeyer: SIGSEGV test throws SIGBUS instead on certain
systems [Reviewed by Karl-Dieter Crisman]
#11081: David Kirkby: Update the "Install from Source Code" section of
the Sage Installation Guide [Reviewed by Karl-Dieter Crisman, Florent
Hivert, John Palmieri, Dmitrii Pasechnik, Jeroen Demeyer]
#11083: Alexander Dreyer: PolyBoRi fails to build on OpenSolaris with
gcc-4.6.0 [Reviewed by David Kirkby]
#11100: Jeroen Demeyer: Increase default timeout of test_executable() to
50 seconds [Reviewed by Volker Braun]
#11110: David Kirkby: libpng has unneeded file called .#spkg-install not
committed to the repository. [Reviewed by Mike Hansen]
#11112: Rob Beezer: Algebraic closure of CDF [Reviewed by Mike Hansen]

Harald Schilly

unread,
Apr 11, 2011, 10:49:38 AM4/11/11
to sage-r...@googlegroups.com
On Monday, April 11, 2011 3:45:21 PM UTC+2, Jeroen Demeyer wrote:

Please build, test, and report!


Ubuntu 10.04.2 LTS 32bit.  

I still have this "etags" problem when building ecl:

;;; Note:
;;;   Invoking external command:
;;;   gcc -I. -I/scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1/src/build/ -I/scratch/scratch/schilly/sage/sage-4.7.alpha4/local/include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fPIC -Dlinux -I/scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1/src/src/c -w -c eclinitjD3RMI.c -o eclinitjD3RMI.o 
;;; Note:
;;;   Invoking external command:
;;;   gcc -o bin/ecl -L/scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1/src/build/ /scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1/src/build/eclinitjD3RMI.o -L./ -Wl,--rpath,/scratch/scratch/schilly/sage/sage-4.7.alpha4/local/lib/ -L/scratch/scratch/schilly/sage/sage-4.7.alpha4/local/lib libecl.so -ldl -lm sed -e 's,@libdir\\@,/scratch/scratch/schilly/sage/sage-4.7.alpha4/local/lib/,' \
            -e 's,@includedir\\@,/scratch/scratch/schilly/sage/sage-4.7.alpha4/local/include/,' \
            -e 's,~A,/scratch/scratch/schilly/sage/sage-4.7.alpha4/local/lib/,' bin/ecl-config.pre > bin/ecl-config
echo > TAGS
if test "xetags" != "x"; then \
        srcfiles=`find /scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1/src/src/c /scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1/src/src/h -name '*.[chd]'` && \
        etags --language=c    -o TAGS $srcfiles && \
        etags --language=none -o TAGS --append \
              --regex='/@\([-:*a-zA-z]+\)/\1/' \
              --regex='/@(defun \([-:*a-zA-z]+\)/\1/' \
              $srcfiles; \
        fi
etags: relocation error: /usr/lib/libldap_r-2.4.so.2: symbol gnutls_certificate_get_x509_cas, version GNUTLS_1_4 not defined in file libgnutls.so.26 with link time reference
make[3]: *** [TAGS] Error 127
make[3]: Leaving directory `/scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1/src/build'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1/src'
Error - Failed to build ECL ... exiting

real    2m12.532s
user    2m0.660s
sys     0m8.473s
sage: An error occurred while installing ecl-11.1.1
explaining the problem and send the relevant part of
of /scratch/scratch/schilly/sage/sage-4.7.alpha4/install.log.  Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1 and type 'make check' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg/build/ecl-11.1.1' && '/scratch/scratch/schilly/sage/sage-4.7.alpha4/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/ecl-11.1.1] Error 1
make[1]: Leaving directory `/scratch/scratch/schilly/sage/sage-4.7.alpha4/spkg'
 

John H Palmieri

unread,
Apr 11, 2011, 2:35:11 PM4/11/11
to sage-r...@googlegroups.com


On Monday, April 11, 2011 6:45:21 AM UTC-7, Jeroen Demeyer wrote:
ear Sage lovers,

(I'm not sure what to make of that salutation :)

We're releasing Sage 4.7.alpha4.

Source archive:

http://sage.math.washington.edu/home/release/sage-4.7.alpha4/sage-4.7.alpha4.tar

Upgrade path:

http://sage.math.washington.edu/home/release/sage-4.7.alpha4/sage-4.7.alpha4/

Please build, test, and report!  We'd love to hear about your
experiences with this release.

On Mac OS X 10.6.7 (Intel), one doctest failure:

sage -t  -long -force_lib devel/sage/sage/matrix/matrix_double_dense.pyx
**********************************************************************
File "/Applications/sage_builds/clean/sage-4.7.alpha4/devel/sage-main/sage/matrix/matrix_double_dense.pyx", line 1538:
    sage: T.round(4)
Expected:
    [-13.5698      0.0      0.0      0.0]
    [     0.0  -0.8508     -0.0     -0.0]
    [     0.0      0.0   7.7664      0.0]
    [     0.0      0.0      0.0  11.6542]
Got:
    [-13.5698      0.0      0.0      0.0]
    [     0.0  -0.8508      0.0      0.0]
    [     0.0      0.0   7.7664      0.0]
    [     0.0      0.0      0.0  11.6542]
**********************************************************************
1 items had failures:
   1 of  59 in __main__.example_31

--
John

 

John H Palmieri

unread,
Apr 11, 2011, 2:42:36 PM4/11/11
to sage-r...@googlegroups.com

I'm getting a very similar (although not identical) failure on t2.math.washington.edu (Solaris on sparc):


Expected:
    [-13.5698      0.0      0.0      0.0]
    [     0.0  -0.8508     -0.0     -0.0]
    [     0.0      0.0   7.7664      0.0]
    [     0.0      0.0      0.0  11.6542]
Got:
    [-13.5698      0.0      0.0      0.0]
    [     0.0  -0.8508      0.0     -0.0]
    [     0.0      0.0   7.7664     -0.0]
    [     0.0      0.0      0.0  11.6542]


--
John

Volker Braun

unread,
Apr 11, 2011, 2:51:27 PM4/11/11
to sage-r...@googlegroups.com
This is Ubuntu's /usr/bin/etags failing on a relocation error. Most likely because we are stuffing something in LD_LIBRARY_PATH that conflicts with Ubuntu shared libraries. The only sane fix is to switch to RPATH/RUNPATH instead of LD_LIBRARY_PATH. This requires the gcc wrapper to set rpaths for all libraries we build.

Jeroen Demeyer

unread,
Apr 11, 2011, 3:14:37 PM4/11/11
to sage-r...@googlegroups.com
On 2011-04-11 20:35, John H Palmieri wrote:
> On Mac OS X 10.6.7 (Intel), one doctest failure:

This is caused by #11027. I will unmerge this patch in the next alpha.

David Kirkby

unread,
Apr 11, 2011, 3:22:53 PM4/11/11
to sage-r...@googlegroups.com
On 11 April 2011 19:42, John H Palmieri <jhpalm...@gmail.com> wrote:

> I'm getting a very similar (although not identical) failure on
> t2.math.washington.edu (Solaris on sparc):
>
> Expected:
>     [-13.5698      0.0      0.0      0.0]
>     [     0.0  -0.8508     -0.0     -0.0]
>     [     0.0      0.0   7.7664      0.0]
>     [     0.0      0.0      0.0  11.6542]
> Got:
>     [-13.5698      0.0      0.0      0.0]
>     [     0.0  -0.8508      0.0     -0.0]
>     [     0.0      0.0   7.7664     -0.0]
>     [     0.0      0.0      0.0  11.6542]
>
>
> --
> John

Similar on OpenSolaris - but not identical to t2.math.

The issue seems to be whether a number close (or equla to) zero is
returned as 0.0 or -0.1

sage -t -long -force_lib "devel/sage/sage/matrix/matrix_double_dense.pyx"
**********************************************************************

File "/export/home/drkirkby/sage-4.7.alpha4/devel/sage/sage/matrix/matrix_double_dense.pyx",


line 1538:
sage: T.round(4)
Expected:
[-13.5698 0.0 0.0 0.0]
[ 0.0 -0.8508 -0.0 -0.0]
[ 0.0 0.0 7.7664 0.0]
[ 0.0 0.0 0.0 11.6542]
Got:
[-13.5698 0.0 0.0 0.0]

[ 0.0 -0.8508 0.0 -0.0]


[ 0.0 0.0 7.7664 0.0]
[ 0.0 0.0 0.0 11.6542]

**********************************************************************

Dave

David Kirkby

unread,
Apr 11, 2011, 3:24:59 PM4/11/11
to sage-r...@googlegroups.com
On 11 April 2011 20:22, David Kirkby <david....@onetel.net> wrote:

> The issue seems to be whether a number close (or equla to) zero is
> returned as 0.0 or -0.1

I mean 0.0 or -0.0.

Jeroen Demeyer

unread,
Apr 11, 2011, 3:27:54 PM4/11/11
to sage-r...@googlegroups.com

Indeed, a very similar issue happens at #10837 (needs_work).

Rob Beezer

unread,
Apr 11, 2011, 3:40:29 PM4/11/11
to sage-release
On Apr 11, 12:27 pm, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> Indeed, a very similar issue happens at #10837 (needs_work).

#10837 has a few other problems, as well.

I'm guessing these -0.0 entries may go away if I apply a
".zero_at()" to the matrix beforehand. I'll experiment this evening.
In the meantime, I guess others will see similar failures. Initial
reports of numerical noise (or worse) on norms or condition numbers
would be welcome.

Rob

Justin C. Walker

unread,
Apr 11, 2011, 4:39:20 PM4/11/11
to sage-r...@googlegroups.com

What is?

--
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.
--------

Francois Bissey

unread,
Apr 11, 2011, 4:50:11 PM4/11/11
to sage-r...@googlegroups.com

I agree, at first I thought it was another problem with etags that had been
spotted on Gentoo prefix but this is likely the problem.

Now your suggestion would make sage build system closer to a gentoo prefix
and make it harder (but not impossible) to relocate.

Francois

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

Volker Braun

unread,
Apr 11, 2011, 5:34:03 PM4/11/11
to sage-r...@googlegroups.com
My gccwrapper sets a relative rpath (using $ORIGIN on linux and the equivalent on OSX), not an absolute rpath. For relocation / binary Sage releases this actually fixes the current security issue where a few of the binaries have dangling rpaths set to the build dir.

Volker Braun

unread,
Apr 11, 2011, 5:37:19 PM4/11/11
to sage-r...@googlegroups.com
On Monday, April 11, 2011 4:39:20 PM UTC-4, Justin C. Walker wrote:
On Apr 11, 2011, at 11:51 , Volker Braun wrote:

> This is Ubuntu's /usr/bin/etags failing on a relocation error.

What is?

This is:

Francois Bissey

unread,
Apr 11, 2011, 5:40:25 PM4/11/11
to sage-r...@googlegroups.com

Neat.

Justin C. Walker

unread,
Apr 11, 2011, 10:19:37 PM4/11/11
to sage-r...@googlegroups.com

On Apr 11, 2011, at 06:45 , Jeroen Demeyer wrote:

> ear Sage lovers,
>
> We're releasing Sage 4.7.alpha4.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.7.alpha4/sage-4.7.alpha4.tar

Built from scratch, Mac OS X (10.6.7; dual 6-core xeon). No problems.
Testing, after applying patches from #9960, showed only one failure, the well-known "-0.0" failure (which, in my case, occurred because the values seen were "0.0" instead of "-0.0").

Justin

--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
--
Democracy is two wolves and a lamb
voting on what to have for lunch.
Liberty is a well-armed lamb contesting
the vote.

Dan Drake

unread,
Apr 12, 2011, 4:01:40 AM4/12/11
to sage-r...@googlegroups.com
On Mon, 11 Apr 2011 at 03:45PM +0200, Jeroen Demeyer wrote:
> ear Sage lovers,
>
> We're releasing Sage 4.7.alpha4.

Hrm. There is a problem with numpy when SAGE_SPKG_INSTALL_DOCS is set.
Here's the relevant part of the log:

make[2]: Entering directory `/home/drake/s/sage-4.7.alpha4/spkg/build/numpy-1.5.1.p0/src/doc'
mkdir -p build
touch build/generate-stamp
mkdir -p build/html build/doctrees
LANG=C sphinx-build -b html -d build/doctrees source build/html
/bin/sh: sphinx-build: not found
make[2]: *** [html] Error 127
make[2]: Leaving directory `/home/drake/s/sage-4.7.alpha4/spkg/build/numpy-1.5.1.p0/src/doc'
Error building numpy docs.

This is a fresh build from source. It looks like we need to alter the
build dependencies to get Sphinx built early. Or perhaps the spkg
installation script could check to see if the INSTALL_DOCS variable is
set, and if so, check that Sphinx is built?

The tricky thing here seems to be that the build deps are different if
SAGE_SPKG_INSTALL_DOCS is set.

I installed the Sphinx spkg and restarted the build, but now I get:

make[2]: Entering directory `/home/drake/s/sage-4.7.alpha4/spkg/build/numpy-1.5.1.p0/src/doc'
mkdir -p build
touch build/generate-stamp
mkdir -p build/html build/doctrees
LANG=C sphinx-build -b html -d build/doctrees source build/html
Traceback (most recent call last):
File "/home/drake/s/sage-4.7.alpha4/local/bin/sphinx-build", line 6, in <module>
import sage.all
ImportError: No module named sage.all
make[2]: *** [html] Error 1
make[2]: Leaving directory `/home/drake/s/sage-4.7.alpha4/spkg/build/numpy-1.5.1.p0/src/doc'
Error building numpy docs.

Yikes. Do we need the Sage library before we can build any Sphinx
documents? Do we need to build documents *after* the usual build process
is done?

Dan

--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------

signature.asc

Samuel Lelievre

unread,
Apr 12, 2011, 7:06:38 AM4/12/11
to sage-r...@googlegroups.com
2011/4/11 Jeroen Demeyer <jdem...@cage.ugent.be>:

> We're releasing Sage 4.7.alpha4.
>
> Please build, test, and report!  We'd love to hear about your
> experiences with this release.

Thanks Jeroen!

Built and tested in 2 setups (log excerpts below):
- Mac OS X 10.5.8 on intel MacBook Pro: make: ok; make ptestlong: 1
doctest failed
- Mac OS X 10.6.7 on intel iMac: make: ok; make ptestlong: 1 doctest
failed, 2 timed out

I like the timing indication when 'make ptestlong' is done:
Total time for all tests: <so-many> seconds.
Could such a timing be given when 'make' is done building?

Samuel

== Mac OS X 10.5.8 on intel MacBook Pro ==

$ uname -a
Darwin U 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT
2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)
$

$ cd /Applications/sage-4.7.alpha4
$ export MAKE="make -j2"
$ export SAGE_PARALLEL_SPKG_BUILD="yes"
$ make
<snip>
Build finished. The built documents can be found in
/Applications/sage-4.7.alpha4/devel/sage/doc/output/html/fr/tutorial
$

$ cd /Applications/sage-4.7.alpha4
$ export MAKE="make -j2"
$ export SAGE_PARALLEL_SPKG_BUILD="yes"
$ export SAGE_TIMEOUT=900
$ export SAGE_TIMEOUT_LONG=3600
$ make ptestlong
<snip>
----------------------------------------------------------------------
The following tests failed:
sage -t -long -force_lib
devel/sage/sage/matrix/matrix_double_dense.pyx # 3 doctests failed
----------------------------------------------------------------------
Total time for all tests: 8881.9 seconds
make: *** [ptestlong] Error 128
$

== Mac OS X 10.6.7 on intel MacBook Pro ==

$ uname -a
Darwin U 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST
2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure
--disable-checking --enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin10
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
--target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

$ cd /Applications/sage-4.7.alpha4
$ export MAKE="make -j2"
$ export SAGE_PARALLEL_SPKG_BUILD="yes"
$ make
<snip>
Build finished. The built documents can be found in
/Applications/sage-4.7.alpha4/devel/sage/doc/output/html/fr/tutorial
$

$ cd /Applications/sage-4.7.alpha4
$ export MAKE="make -j2"
$ export SAGE_PARALLEL_SPKG_BUILD="yes"
$ export SAGE_TIMEOUT=900
$ export SAGE_TIMEOUT_LONG=3600
$ make ptestlong
<snip>
----------------------------------------------------------------------
The following tests failed:
sage -t -long -force_lib
devel/sage/sage/matrix/matrix_double_dense.pyx # 1 doctests failed
sage -t -long -force_lib
devel/sage/sage/schemes/generic/toric_variety_library.py # Time out
sage -t -long -force_lib
devel/sage/sage/schemes/hyperelliptic_curves/hyperelliptic_padic_field.py
# Time out
----------------------------------------------------------------------
Total time for all tests: 31991.8 seconds
make: *** [ptestlong] Error 192
$

Justin C. Walker

unread,
Apr 13, 2011, 1:56:43 AM4/13/11
to sage-r...@googlegroups.com

On Apr 11, 2011, at 06:45 , Jeroen Demeyer wrote:

Built as an upgrade to sage-4.7.alpha2 (Mac OS X, 10.6.7, Core i7), w/o problems.

Testing (with #9960 patches applied) yielded one failure, the world-famous matrix_double_dense.pyx failure (getting "0.0" where "-0.0" is expected).

Justin

--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds

-----------
Like the ski resort full of girls hunting for husbands
and husbands hunting for girls, the situation is not
as symmetrical as it might seem.
- Alan MacKay
--

Dan Drake

unread,
Apr 13, 2011, 3:47:21 AM4/13/11
to sage-r...@googlegroups.com
On Mon, 11 Apr 2011 at 03:45PM +0200, Jeroen Demeyer wrote:
> ear Sage lovers,
>
> We're releasing Sage 4.7.alpha4.

Building on the Ubuntu 11.04 beta didn't work. The Python crypt module
didn't work properly. The build completed, but I can't start Sage (I get
an ImportError: no module named crypt) and the documentation didn't
build at all.

Logs at:

http://sagenb.kaist.ac.kr/~drake/install.log.txt (about 23 MB)
http://sagenb.kaist.ac.kr/~drake/dochtml.log.txt

Any ideas what's going on? This is a 32-bit virtual machine; it has gcc
4.5.2.

signature.asc

Kiran Kedlaya

unread,
Apr 16, 2011, 9:13:07 PM4/16/11
to sage-release
I just tried the same thing on my 64-bit laptop and likewise got a
whole bunch of "No module named crypt" errors in the logs.

I think Ubuntu 11.04 has gone over fully to Python 2.7. Is there
possibly some confusion between the system Python and the one provided
by Sage (which is still 2.6.x)?

Kiran

On Apr 13, 12:47 am, Dan Drake <dr...@kaist.edu> wrote:
> On Mon, 11 Apr 2011 at 03:45PM +0200, Jeroen Demeyer wrote:
> > ear Sage lovers,
>
> > We're releasing Sage 4.7.alpha4.
>
> Building on the Ubuntu 11.04 beta didn't work. The Python crypt module
> didn't work properly. The build completed, but I can't start Sage (I get
> an ImportError: no module named crypt) and the documentation didn't
> build at all.
>
> Logs at:
>
>    http://sagenb.kaist.ac.kr/~drake/install.log.txt(about 23 MB)
>    http://sagenb.kaist.ac.kr/~drake/dochtml.log.txt
>
> Any ideas what's going on? This is a 32-bit virtual machine; it has gcc
> 4.5.2.
>
> Dan
>
> --
> ---  Dan Drake
> -----  http://mathsci.kaist.ac.kr/~drake
> -------
>
>  signature.asc
> < 1KViewDownload

Dr. David Kirkby

unread,
Apr 17, 2011, 6:26:12 AM4/17/11
to sage-r...@googlegroups.com
On 04/17/11 02:13 AM, Kiran Kedlaya wrote:
> I just tried the same thing on my 64-bit laptop and likewise got a
> whole bunch of "No module named crypt" errors in the logs.
>
> I think Ubuntu 11.04 has gone over fully to Python 2.7. Is there
> possibly some confusion between the system Python and the one provided
> by Sage (which is still 2.6.x)?
>
> Kiran

That would not totally surprise me. It should not happen, but I am aware of at
least one bug where Sage interacted with the system python and not the one in
Sage. Fortunately I was not stupid enough to be logged in as root, but had I
been, this would probably have screwed up my system install.

http://trac.sagemath.org/sage_trac/ticket/9209

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Dave

Dima Pasechnik

unread,
Apr 18, 2011, 12:18:55 PM4/18/11
to sage-release
on MacOSX (x86 64bits) 10.6.7 Sage built with gcc from Xcode 4
segfaults at startup.
(and during the final stages of installation there are lot of related
segfaults)

Running ./sage -gdb gives:

[lots of output edited out ...]

warning: Could not find object file "/usr/local/src/sage/
sage-4.7.alpha4/spkg/build/pynac-0.2.1/src/ginac/.libs/wildcard.o" -
no debug information available for "wildcard.cpp".

. done


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000107a07c54 in PyInt_FromLong (ival=-5) at Objects/intobject.c:
91
91 Objects/intobject.c: No such file or directory.
in Objects/intobject.c
(gdb)

the install.log is at
http://www1.spms.ntu.edu.sg/~dima/tmp/sage47alpha4.log.gz

Dima


On Apr 11, 9:45 pm, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> ear Sage lovers,
>
> We're releasing Sage 4.7.alpha4.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.7.alpha4/sage-4.7...
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.7.alpha4/sage-4.7...
>
> Please build, test, and report!  We'd love to hear about your
> experiences with this release.
>
> == Known issues ==
>
>  * Some doctests fail on bsd.math (OS X 10.6 i386), when compiling in
>    64-bit mode due to SAGE64 verbosity.  This is #10303.
>
> == Tickets ==
>
> * We closed 151 tickets in this release. For details, see
>
>  http://sage.math.washington.edu/home/release/sage-4.7.alpha4/tickets....

Dr. David Kirkby

unread,
Apr 19, 2011, 4:18:44 PM4/19/11
to sage-r...@googlegroups.com
On 04/18/11 05:18 PM, Dima Pasechnik wrote:
> on MacOSX (x86 64bits) 10.6.7 Sage built with gcc from Xcode 4
> segfaults at startup.
> (and during the final stages of installation there are lot of related
> segfaults)
>
> Running ./sage -gdb gives:
>
> [lots of output edited out ...]
>
> warning: Could not find object file "/usr/local/src/sage/
> sage-4.7.alpha4/spkg/build/pynac-0.2.1/src/ginac/.libs/wildcard.o" -
> no debug information available for "wildcard.cpp".
>
> . done
>
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
> 0x0000000107a07c54 in PyInt_FromLong (ival=-5) at Objects/intobject.c:
> 91
> 91 Objects/intobject.c: No such file or directory.
> in Objects/intobject.c
> (gdb)
>
> the install.log is at
> http://www1.spms.ntu.edu.sg/~dima/tmp/sage47alpha4.log.gz
>
> Dima

Pynac is also causing seg faults on startup on 64-bit Solaris, though the error
looks a bit different.

http://trac.sagemath.org/sage_trac/ticket/11116

It would be nice to sort that out, as that crash is basically stopping any
attempt to complete a 64-bit Solaris port. Burcin concedes it is a fault with
Pynac that's causing the problem, but so far its not been fixed.

Dave

Reply all
Reply to author
Forward
0 new messages