4 views

Skip to first unread message

Oct 21, 2010, 8:19:56 PM10/21/10

to sage-r...@googlegroups.com

Ave Sage user-developers!

We've released Sage 4.6.rc0.

Source archive:

http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

Upgrade path:

http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

Please build, test, and report! We'd love to hear about your

experiences with this release.

== Notes ==

* The 4.6 cycle is still in feature freeze.

* We've merged #9896 into this release so it gets more widely tested,

but it still needs a review.

* Jeroen Demeyer will manage the 4.6.1 cycle.

== Tickets ==

Closed:

#9926: Doctest error in sage/schemes/generic/toric_divisor.py on OS X

#10081: Another doctest failure in sage/graphs/graphs.py

Merged in sage-4.6.rc0:

#6235: John Palmieri: set MPLCONFIGDIR environment variable when Sage

starts up [Reviewed by Leif Leonhardy]

#8677: Volker Braun, William Stein: Race condition creating dirs during

Sage build [Reviewed by Volker Braun, Mitesh Patel]

#9210: Jason Grout: pkg-config's prefix statements in

SAGE_LOCAL/lib/pkgconfig not changed upon Sage move [Reviewed by David

Kirkby, Karl-Dieter Crisman]

#9422: Nathann Cohen: Slightly improving is_forest [Reviewed by Leonardo

Sampaio]

#9798: Volker Braun: Accelerate Polyhedron constructor and fix cddlib

output ordering [Reviewed by Dmitrii Pasechnik, Marshall Hampton]

#9896: Leif Leonhardy: Upgrading from 4.5.3 to 4.6.alpha* can fail (not

limited to MacOS X) [Reviewed by ???]

#9959: Jeroen Demeyer: Get PARI/GP to stop starting automatically

[Reviewed by John Cremona]

#10041: Joris Vankerschaver: Doctest failure in

sage/tensor/differential_forms.py [Reviewed by Niles Johnson]

#10042: Dima Pasechnik: Doctest failure in

sage/rings/polynomial/polynomial_element.pyx [Reviewed by Leif Leonhardy]

#10053: Joris Vankerschaver: Equality testing instead of comparisons in

differential forms code [Reviewed by Niles Johnson]

#10098: Volker Braun: Flaky doctest in sage/interfaces/expect.py

[Reviewed by Mitesh Patel]

#10104: Mike Hansen: #9920 breaks bdisted binaries [Reviewed by Mitesh

Patel]

Oct 22, 2010, 12:06:46 AM10/22/10

to sage-release

I got three test failures (with "sage -tp 4") on OS X 10.6:

The following tests failed:

sage -t devel/sage/sage/interfaces/sage0.py # 3 doctests failed

sage -t devel/sage/sage/libs/ntl/all.py # 0 doctests failed

sage -t devel/sage/sage/rings/all.py # 0 doctests failed

The second two don't occur when retesting single-threaded. The

sage0.py is reproducible, and gives:

sage -t "devel/sage/sage/interfaces/sage0.py"

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

File "/Volumes/E/sage-4.6.rc0/devel/sage/sage/interfaces/sage0.py",

line 105:

sage: a

Expected:

10

Got:

<BLANKLINE>

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

File "/Volumes/E/sage-4.6.rc0/devel/sage/sage/interfaces/sage0.py",

line 114:

sage: s3('"x"')

Expected:

8

Got:

<BLANKLINE>

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

File "/Volumes/E/sage-4.6.rc0/devel/sage/sage/interfaces/sage0.py",

line 116:

sage: s('x')

Expected:

5

Got:

<BLANKLINE>

-Marshall

The following tests failed:

sage -t devel/sage/sage/interfaces/sage0.py # 3 doctests failed

sage -t devel/sage/sage/libs/ntl/all.py # 0 doctests failed

sage -t devel/sage/sage/rings/all.py # 0 doctests failed

The second two don't occur when retesting single-threaded. The

sage0.py is reproducible, and gives:

sage -t "devel/sage/sage/interfaces/sage0.py"

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

File "/Volumes/E/sage-4.6.rc0/devel/sage/sage/interfaces/sage0.py",

line 105:

sage: a

Expected:

10

Got:

<BLANKLINE>

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

File "/Volumes/E/sage-4.6.rc0/devel/sage/sage/interfaces/sage0.py",

line 114:

sage: s3('"x"')

Expected:

8

Got:

<BLANKLINE>

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

File "/Volumes/E/sage-4.6.rc0/devel/sage/sage/interfaces/sage0.py",

line 116:

sage: s('x')

Expected:

5

Got:

<BLANKLINE>

-Marshall

Oct 22, 2010, 12:31:44 AM10/22/10

to sage-release

All tests passed on an Ubuntu 9.10 (64-bit), intel i7 860 machine.

-Marshall

-Marshall

Oct 22, 2010, 12:58:52 AM10/22/10

to sage-r...@googlegroups.com

FWIW,

Fedora 11, gcc 4.4.1

Fails with the issue already reported for Sage 4.6.alpha3

http://groups.google.com/group/sage-release/browse_thread/thread/a72cd417c5312470

Fedora 12, gcc 4.4.4

Appears to build with no serious problems

Fedora 13, gcc 4.4.4

ATLAS won't build, same issue reported on 'asksage'

http://ask.sagemath.org/question/107/building-atlas

(This is on a very low-powered "netbook" but it was able

to build sage up until I put Fedora 13 on it.)

If any of the logs of these builds are of interest, I'll

make them available.

-Mike

Oct 22, 2010, 1:31:24 AM10/22/10

to sage-r...@googlegroups.com

Does anyone else see this or know why this could happen?

Here are Sage Buildbot reports for bsd.math (OS X 10.6):

32-bit

http://build.sagemath.org/sage/builders/bsd%20full/builds/20

64-bit

http://build.sagemath.org/sage/builders/bsd%2064%20full/builds/4

Running

./sage -t "devel/sage/sage/interfaces/sage0.py"

about 10 times with each of these builds doesn't give any failures.

Oct 22, 2010, 2:27:37 AM10/22/10

to sage-r...@googlegroups.com

On Oct 21, 2010, at 17:19 , Mitesh Patel wrote:

> Ave Sage user-developers!

>

> We've released Sage 4.6.rc0.

>

> Source archive:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':

Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.

Five failures during testing (sage -t -long -force_lib):

devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed

devel/sage/sage/calculus/desolvers.py # 1 doctests failed

devel/sage/sage/misc/trace.py # 1 doctests failed

devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

devel/sage/sage/symbolic/assumptions.py # 2 doctests failed

ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log

Core i7, upgraded from "a3", no problems.

One failure during testing (sage -t -long -force_lib):

devel/sage/sage/misc/trace.py # 1 doctests failed

ptestlong log a sage.math.washington.edu:~justin/logs/4.6.rc0-i7.log

Justin

--

Justin C. Walker, Curmudgeon at Large

Director

Institute for the Enhancement of the Director's income

-----------

Question 43:

What if the hokey pokey

really *is* what it’s all about?

--

Oct 22, 2010, 3:00:51 AM10/22/10

to sage-r...@googlegroups.com

On 10/22/2010 01:27 AM, Justin C. Walker wrote:

> On Oct 21, 2010, at 17:19 , Mitesh Patel wrote:

>> Ave Sage user-developers!

>>

>> We've released Sage 4.6.rc0.

>>

>> Source archive:

>>

>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

>>

>> Upgrade path:

>>

>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>

> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':

>

> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.

> Five failures during testing (sage -t -long -force_lib):

> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed

> devel/sage/sage/calculus/desolvers.py # 1 doctests failed

> devel/sage/sage/misc/trace.py # 1 doctests failed

> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed

> ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log

> On Oct 21, 2010, at 17:19 , Mitesh Patel wrote:

>> Ave Sage user-developers!

>>

>> We've released Sage 4.6.rc0.

>>

>> Source archive:

>>

>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

>>

>> Upgrade path:

>>

>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>

> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':

>

> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.

> Five failures during testing (sage -t -long -force_lib):

> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed

> devel/sage/sage/calculus/desolvers.py # 1 doctests failed

> devel/sage/sage/misc/trace.py # 1 doctests failed

> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed

> ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log

http://sage.math.washington.edu/home/justin/logs/4.6.rc0-DQX.log

> Core i7, upgraded from "a3", no problems.

> One failure during testing (sage -t -long -force_lib):

> devel/sage/sage/misc/trace.py # 1 doctests failed

> ptestlong log a sage.math.washington.edu:~justin/logs/4.6.rc0-i7.log

http://sage.math.washington.edu/home/justin/logs/4.6.rc0-i7.log

The base.pyx (#10059) and trace.py (#10138) errors are known. The

plotting.rst error is

OSError: [Errno 17] File exists:

'/Users/justin/.sage//matplotlib-1.0.0/tex.cache'

and may stem from the recent matplotlib upgrade (#9221, #6235). I think

the others relate to Maxima.

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

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

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

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

Oct 22, 2010, 3:15:46 AM10/22/10

to sage-r...@googlegroups.com

On 10/21/2010 11:58 PM, Mike Witt wrote:

> FWIW,

>

> Fedora 11, gcc 4.4.1

> Fails with the issue already reported for Sage 4.6.alpha3

>

> http://groups.google.com/group/sage-release/browse_thread/thread/a72cd417c5312470

> FWIW,

>

> Fedora 11, gcc 4.4.1

> Fails with the issue already reported for Sage 4.6.alpha3

>

> http://groups.google.com/group/sage-release/browse_thread/thread/a72cd417c5312470

This is likely to be a GCC bug.

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

What happens if you build from scratch with

export SAGE_DEBUG=yes

make

? This skips the -O3 GCC optimization flag for at least PARI.

Oct 22, 2010, 4:13:03 AM10/22/10

to sage-r...@googlegroups.com

Mitesh Patel wrote:

> On 10/21/2010 11:58 PM, Mike Witt wrote:

>> FWIW,

>>

>> Fedora 11, gcc 4.4.1

>> Fails with the issue already reported for Sage 4.6.alpha3

>>

>> http://groups.google.com/group/sage-release/browse_thread/thread/a72cd417c5312470

>

> This is likely to be a GCC bug.

>

> http://trac.sagemath.org/sage_trac/ticket/10120

>

> What happens if you build from scratch with

>

> export SAGE_DEBUG=yes

> make

>

> ? This skips the -O3 GCC optimization flag for at least PARI.

> On 10/21/2010 11:58 PM, Mike Witt wrote:

>> FWIW,

>>

>> Fedora 11, gcc 4.4.1

>> Fails with the issue already reported for Sage 4.6.alpha3

>>

>> http://groups.google.com/group/sage-release/browse_thread/thread/a72cd417c5312470

>

> This is likely to be a GCC bug.

>

> http://trac.sagemath.org/sage_trac/ticket/10120

>

> What happens if you build from scratch with

>

> export SAGE_DEBUG=yes

> make

>

> ? This skips the -O3 GCC optimization flag for at least PARI.

It should be sufficient to just continue the build with SAGE_DEBUG (or

CFLAGS appropriately) set, or - if the Sage scripts are already

installed - do

env SAGE_DEBUG=yes ./sage -i pari-2.4.3.svn-12577.p9

make # continue normal build

-Leif

Oct 22, 2010, 5:53:04 AM10/22/10

to sage-r...@googlegroups.com

Mitesh Patel wrote:

> Ave Sage user-developers!

>

> We've released Sage 4.6.rc0.

>

> Source archive:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

> Ave Sage user-developers!

>

> We've released Sage 4.6.rc0.

>

> Source archive:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

Amen.

Note that upgrading (the rebuild process, not the downloads) will

probably now take longer than it used to, because now all packages that

depend on new ones will get rebuilt.

To reduce the number of (unfortunately unnecessarily) rebuilt packages,

one could do the following *before* upgrading on any system other than

SunOS/Solaris, Cygwin and HP-UX:

touch spkg/installed/iconv-1.13.1.p3

(This package is in fact only required/used on the above platforms, but

"installing" it triggers the rebuild of *many* other packages on *every*

platform. There's currently no other way to avoid this, sorry.)

I'm quite glad to report that upgrading from Sage 4.4.4 (!) worked out

of the box on Ubuntu 9.04 x86_64 (Core2, gcc 4.3.3; MAKE="make -j16" and

SAGE_PARALLEL_SPKG_BUILD=yes set before running the upgrade; directory

renamed before upgrading).

make ptestlong also passed without any errors.

Sage 4.6.rc0pre1 (which I assume is almost identical to the "final" rc0)

built without errors and ptestlong also passed on Ubuntu 10.04 x86_64

(Core2, gcc 4.4.3; built from scratch in parallel with 32 jobs).

-Leif

Oct 22, 2010, 6:21:09 AM10/22/10

to sage-r...@googlegroups.com

On 10/22/2010 12:15:46 AM, Mitesh Patel wrote:

> What happens if you build from scratch with

>

> export SAGE_DEBUG=yes

> make

That appears to work.

-Mike

Oct 22, 2010, 6:33:00 AM10/22/10

to sage-r...@googlegroups.com

You could also (re)try

unset SAGE_DEBUG

env CFLAGS="-O2 -fno-strict-aliasing -fomit-frame-pointer" ./sage -f

pari-2.4.3.svn-12577.p9

(which just forces reinstallation of the PARI spkg).

-Leif

Oct 22, 2010, 6:51:41 AM10/22/10

to sage-r...@googlegroups.com

If that will yield any information that might improve the release

(or would be otherwise useful to anyone) I'll be happy to try it.

-Mike

Oct 22, 2010, 6:56:57 AM10/22/10

to sage-r...@googlegroups.com

It would be nice if you could, and report at #10120.

-Leif

P.S.: Building Sage with SAGE_DEBUG=yes isn't very good for "production"

use, since this (completely) disables optimization in a number of packages.

Oct 22, 2010, 7:14:30 AM10/22/10

to sage-r...@googlegroups.com

P.P.S.:

If the above works for you, you can afterwards trigger a rebuild *with*

optimization (of the packages that were built with SAGE_DEBUG set in the

first place) by doing

unset SAGE_DEBUG # if not already done

env SAGE_UPGRADING=yes make # rebuilds all packages that depend on PARI

(assuming you had built Sage in parallel, i.e. all packages that do

*not* depend on PARI were built in the first run of 'make', without

SAGE_DEBUG set).

-Leif

Oct 22, 2010, 8:07:43 AM10/22/10

to sage-r...@googlegroups.com

Built from scratch with no problems on two different 64-bit ubuntu

machines using SAGE_SPKG_PARALLEL_BUILD='yes' and MAKE='make -j <n>'

for suitable n; make ptestlong passes everything.

machines using SAGE_SPKG_PARALLEL_BUILD='yes' and MAKE='make -j <n>'

for suitable n; make ptestlong passes everything.

John

> --

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

>

>

Oct 22, 2010, 11:57:31 AM10/22/10

to sage-r...@googlegroups.com

On 10/22/2010 03:56:57 AM, leif wrote:

> Mike Witt wrote:

> > On 10/22/2010 03:33:00 AM, leif wrote:

> >> Mike Witt wrote:

> >> > On 10/22/2010 12:15:46 AM, Mitesh Patel wrote:

> >> >

> >> >> What happens if you build from scratch with

> >> >>

> >> >> export SAGE_DEBUG=yes

> >> >> make

> >> >

> >> > That appears to work.

> >>

> >>

> >> You could also (re)try

> >>

> >> unset SAGE_DEBUG

> >>

> >> env CFLAGS="-O2 -fno-strict-aliasing -fomit-frame-pointer" ./sage

> -f

> >> pari-2.4.3.svn-12577.p9

> >>

> >> (which just forces reinstallation of the PARI spkg).

> >

> > If that will yield any information that might improve the release

> > (or would be otherwise useful to anyone) I'll be happy to try it.

>

> It would be nice if you could, and report at #10120.

> Mike Witt wrote:

> > On 10/22/2010 03:33:00 AM, leif wrote:

> >> Mike Witt wrote:

> >> > On 10/22/2010 12:15:46 AM, Mitesh Patel wrote:

> >> >

> >> >> What happens if you build from scratch with

> >> >>

> >> >> export SAGE_DEBUG=yes

> >> >> make

> >> >

> >> > That appears to work.

> >>

> >>

> >> You could also (re)try

> >>

> >> unset SAGE_DEBUG

> >>

> >> env CFLAGS="-O2 -fno-strict-aliasing -fomit-frame-pointer" ./sage

> -f

> >> pari-2.4.3.svn-12577.p9

> >>

> >> (which just forces reinstallation of the PARI spkg).

> >

> > If that will yield any information that might improve the release

> > (or would be otherwise useful to anyone) I'll be happy to try it.

>

> It would be nice if you could, and report at #10120.

I'm a little uneasy about getting involved with the bug tracking

system right now, since I don't really have time to learn how it

works. Perhaps down the road a bit.

I realize that makes my reports less useful. Sorry about that.

-Mike

Oct 22, 2010, 12:23:03 PM10/22/10

to sage-r...@googlegroups.com

On Fri, Oct 22, 2010 at 1:07 PM, John Cremona <john.c...@gmail.com> wrote:

> Built from scratch with no problems on two different 64-bit ubuntu

> machines using SAGE_SPKG_PARALLEL_BUILD='yes' and MAKE='make -j <n>'

> for suitable n; make ptestlong passes everything.

> Built from scratch with no problems on two different 64-bit ubuntu

> machines using SAGE_SPKG_PARALLEL_BUILD='yes' and MAKE='make -j <n>'

> for suitable n; make ptestlong passes everything.

Same again for 32-bit SUSE linux: no build problems, ptestlong all passed.

>

> John

Oct 22, 2010, 12:30:35 PM10/22/10

to sage-r...@googlegroups.com

Oh, sorry, I didn't notice you're not (yet) "on trac", Sage's bug

tracking system. (I did not even post a link to the ticket [1], which I

certainly should have done.)

> I realize that makes my reports less useful. Sorry about that.

No, any reports are welcome, on the Sage trac as well as the discussion

groups (sage-release, sage-devel, sage-support).

We usually copy (excerpts from) posts to the tickets, or at least link

to the respective threads. It's just usually more convenient to continue

a discussion at /some/ point on the ticket.

Also, "trac" supports more fancy posts than the Google groups do. ;-)

-Leif

Oct 22, 2010, 3:54:00 PM10/22/10

to sage-release

mysterious "libpari segfault" - specifically the "a = 10" test.

The message where Jan isolated his discovery is

http://groups.google.com/group/sage-devel/browse_thread/thread/f2644af599f49b1c/7ee58c907458e87b

but the whole thread is interesting. I know Marshall was involved,

but can't recall if he was getting the segfault as well, nor on which

platform. I think Jan would pursue this further if he could get a

PARI specialist to lend a hand.

Rob

Oct 22, 2010, 4:02:56 PM10/22/10

to sage-r...@googlegroups.com

Well, that was with the *old* PARI (Sage 4.5.3).

-Leif

Oct 22, 2010, 4:12:19 PM10/22/10

to sage-r...@googlegroups.com

leif wrote:

> Mitesh Patel wrote:

>> Ave Sage user-developers!

>>

>> We've released Sage 4.6.rc0.

>>

>> Source archive:

>>

>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

>>

>> Upgrade path:

>>

>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>

> Amen.

>

> Note that upgrading (the rebuild process, not the downloads) will

> probably now take longer than it used to, because now all packages that

> depend on new ones will get rebuilt.

>

> To reduce the number of (unfortunately unnecessarily) rebuilt packages,

> one could do the following *before* upgrading on any system other than

> SunOS/Solaris, Cygwin and HP-UX:

>

> touch spkg/installed/iconv-1.13.1.p3

>

> (This package is in fact only required/used on the above platforms, but

> "installing" it triggers the rebuild of *many* other packages on *every*

> platform. There's currently no other way to avoid this, sorry.)

> Mitesh Patel wrote:

>> Ave Sage user-developers!

>>

>> We've released Sage 4.6.rc0.

>>

>> Source archive:

>>

>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

>>

>> Upgrade path:

>>

>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>

> Amen.

>

> Note that upgrading (the rebuild process, not the downloads) will

> probably now take longer than it used to, because now all packages that

> depend on new ones will get rebuilt.

>

> To reduce the number of (unfortunately unnecessarily) rebuilt packages,

> one could do the following *before* upgrading on any system other than

> SunOS/Solaris, Cygwin and HP-UX:

>

> touch spkg/installed/iconv-1.13.1.p3

>

> (This package is in fact only required/used on the above platforms, but

> "installing" it triggers the rebuild of *many* other packages on *every*

> platform. There's currently no other way to avoid this, sorry.)

I've also successfully upgraded from a copy of Sage 4.5.3 (i.e., a

"moved" installation) with the above (faking the new iconv spkg was

already installed) on Ubuntu 9.04 x86 (Pentium4 Prescott, gcc 4.3.3;

parallel build with 8 jobs).

ptestlong passed without any errors.

-Leif

Oct 22, 2010, 4:27:00 PM10/22/10

to sage-r...@googlegroups.com

leif wrote:

> leif wrote:

>> Mitesh Patel wrote:

>>> Ave Sage user-developers!

>>>

>>> We've released Sage 4.6.rc0.

>>>

>>> Source archive:

>>>

>>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

>>>

>>> Upgrade path:

>>>

>>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>>

>> Amen.

>>

>> Note that upgrading (the rebuild process, not the downloads) will

>> probably now take longer than it used to, because now all packages that

>> depend on new ones will get rebuilt.

>>

>> To reduce the number of (unfortunately unnecessarily) rebuilt packages,

>> one could do the following *before* upgrading on any system other than

>> SunOS/Solaris, Cygwin and HP-UX:

>>

>> touch spkg/installed/iconv-1.13.1.p3

>>

>> (This package is in fact only required/used on the above platforms, but

>> "installing" it triggers the rebuild of *many* other packages on *every*

>> platform. There's currently no other way to avoid this, sorry.)

> leif wrote:

>> Mitesh Patel wrote:

>>> Ave Sage user-developers!

>>>

>>> We've released Sage 4.6.rc0.

>>>

>>> Source archive:

>>>

>>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar

>>>

>>> Upgrade path:

>>>

>>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>>

>> Amen.

>>

>> Note that upgrading (the rebuild process, not the downloads) will

>> probably now take longer than it used to, because now all packages that

>> depend on new ones will get rebuilt.

>>

>> To reduce the number of (unfortunately unnecessarily) rebuilt packages,

>> one could do the following *before* upgrading on any system other than

>> SunOS/Solaris, Cygwin and HP-UX:

>>

>> touch spkg/installed/iconv-1.13.1.p3

>>

>> (This package is in fact only required/used on the above platforms, but

>> "installing" it triggers the rebuild of *many* other packages on *every*

>> platform. There's currently no other way to avoid this, sorry.)

Oh, I just noticed that one would have to run "make build" *after*

touching spkg/installed/iconv-1.13.1.p3 and *before* running "sage

-upgrade ..." to make this (fully) work... :/

(Running "make build" just touches all packages that depend on iconv,

with the message "... is already installed", i.e. no [re]compilation

takes place.)

Sorry.

-Leif

Oct 22, 2010, 4:46:27 PM10/22/10

to sage-r...@googlegroups.com

OK, thanks for the encouraging comments. I'm a bit ambivalent

about how far a "non-developer" should get into the development

process. But this isn't the place to get into that :-)

In any event, I do want to make any reports that will be useful.

So ... I went into the directory in which I'd previously done

the make with SAGE_DEBUG=yes. Then I did the two commands above.

It was clearly going to run out of memory again, at this point:

ict-aliasing -fomit-frame-pointer -I. -I../src/headers -fPIC -o

base3.o ../src/basemath/base3.c

It just hung there allocating memory. I killed it before I

ran completely out.

-Mike

Oct 22, 2010, 5:31:42 PM10/22/10

to sage-release

On Oct 21, 5:19 pm, Mitesh Patel <qed...@gmail.com> wrote:

> Ave Sage user-developers!

>

> We've released Sage 4.6.rc0.

>

> Source archive:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc...
> Ave Sage user-developers!

>

> We've released Sage 4.6.rc0.

>

> Source archive:

>

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>

> Please build, test, and report! We'd love to hear about your

> experiences with this release.

Built from scratch and upgraded from 4.5.3 on two Mac OS X 10.6
> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>

> Please build, test, and report! We'd love to hear about your

> experiences with this release.

machines; all tests passed in all four cases.

--

John

Oct 22, 2010, 5:38:12 PM10/22/10

to sage-r...@googlegroups.com

Ok, thanks.

So compiling PARI with "-O2" (instead of "-O3") is still too much for

Fedora's broken gcc 4.4.1. (I didn't expect that, but the GCC developers

tend to put more and more sophisticated optimizations into the usual

default "O2" level.)

In case you have nothing else to do, you could retry the above with

"-O1" instead of "-O2" again... ;-)

-Leif

Oct 22, 2010, 6:04:33 PM10/22/10

to sage-r...@googlegroups.com

Justin, are the plotting.rst, desolvers.py, and assumptions.py errors

reproducible?

Oct 22, 2010, 6:05:32 PM10/22/10

to sage-r...@googlegroups.com

No problem. I still have the window open. That one DID work.

-Mike

Oct 22, 2010, 6:10:33 PM10/22/10

to sage-release

On Oct 22, 12:00 am, Mitesh Patel <qed...@gmail.com> wrote:

> On 10/22/2010 01:27 AM, Justin C. Walker wrote:

>

> > Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.

> > Five failures during testing (sage -t -long -force_lib):

> > devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed

> > devel/sage/sage/calculus/desolvers.py # 1 doctests failed

> > devel/sage/sage/misc/trace.py # 1 doctests failed

> > devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

> > devel/sage/sage/symbolic/assumptions.py # 2 doctests failed

> > ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log

>

> http://sage.math.washington.edu/home/justin/logs/4.6.rc0-DQX.log

>

> > Core i7, upgraded from "a3", no problems.

> > One failure during testing (sage -t -long -force_lib):

> > devel/sage/sage/misc/trace.py # 1 doctests failed

> > ptestlong log a sage.math.washington.edu:~justin/logs/4.6.rc0-i7.log

>

> http://sage.math.washington.edu/home/justin/logs/4.6.rc0-i7.log

>

> The base.pyx (#10059) and trace.py (#10138) errors are known. The

> plotting.rst error is

>

> OSError: [Errno 17] File exists:

> '/Users/justin/.sage//matplotlib-1.0.0/tex.cache'

>

> and may stem from the recent matplotlib upgrade (#9221, #6235).

I bet the plotting.rst error is not repeatable.
> On 10/22/2010 01:27 AM, Justin C. Walker wrote:

>

> > Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.

> > Five failures during testing (sage -t -long -force_lib):

> > devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed

> > devel/sage/sage/calculus/desolvers.py # 1 doctests failed

> > devel/sage/sage/misc/trace.py # 1 doctests failed

> > devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

> > devel/sage/sage/symbolic/assumptions.py # 2 doctests failed

> > ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log

>

> http://sage.math.washington.edu/home/justin/logs/4.6.rc0-DQX.log

>

> > Core i7, upgraded from "a3", no problems.

> > One failure during testing (sage -t -long -force_lib):

> > devel/sage/sage/misc/trace.py # 1 doctests failed

> > ptestlong log a sage.math.washington.edu:~justin/logs/4.6.rc0-i7.log

>

> http://sage.math.washington.edu/home/justin/logs/4.6.rc0-i7.log

>

> The base.pyx (#10059) and trace.py (#10138) errors are known. The

> plotting.rst error is

>

> OSError: [Errno 17] File exists:

> '/Users/justin/.sage//matplotlib-1.0.0/tex.cache'

>

> and may stem from the recent matplotlib upgrade (#9221, #6235).

I think the relevant lines in matplotlib/texmanager.py are

if not os.path.exists(texcache):

os.mkdir(texcache)

So my guess is that it's a clash with another doctest trying to create

the same directory at the same time. Should we patch this the way we

did in #8677:

try:

os.mkdir(texcache)

except OSError:

pass

?

(Anyway, I'm not sure, but I don't think this comes from #6235 etc. I

think it could happen anytime you run parallel tests without a

matplotlib config directory, whether it's $HOME/.matplotlib or

$HOME/.sage/matplotlib-1.0.0 or anything else.)

--

John

Oct 22, 2010, 6:32:22 PM10/22/10

to sage-r...@googlegroups.com

On Oct 22, 2010, at 15:04 , Mitesh Patel wrote:

> On 10/22/2010 02:00 AM, Mitesh Patel wrote:

>> On 10/22/2010 01:27 AM, Justin C. Walker wrote:

>>> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':

>>>

>>> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.

>>> Five failures during testing (sage -t -long -force_lib):

>>> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed

>>> devel/sage/sage/calculus/desolvers.py # 1 doctests failed

>>> devel/sage/sage/misc/trace.py # 1 doctests failed

>>> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

>>> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed

>>> ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log

[snip]

> Justin, are the plotting.rst, desolvers.py, and assumptions.py errors

> reproducible?

I am trying this on the system where the failures occurred. If I run them individually, all three pass. I am rerunning the full test exactly as I did before now, and I will let you know what transpires.

Justin

--

Justin C. Walker, Curmudgeon-At-Large

Institute for the Absorption of Federal Funds

--------

If you're not confused,

You're not paying attention

--------

Oct 22, 2010, 7:34:26 PM10/22/10

to sage-r...@googlegroups.com

That's suboptimal; the actual error should be checked, too (everywhere!):

try;

os.mkdir(foo)

except OSError, err:

if err.errno == 17:

pass

else:

raise

(#8677, patch version 4 does similar; I think other instances do not yet?)

2ct,

-Leif

Oct 22, 2010, 8:39:13 PM10/22/10

to sage-r...@googlegroups.com

Please forget that post! ;-)

It works as originally stated, by simply touching iconv-1.13.1.p3, the

'make build' isn't necessary (but doesn't hurt either).

Just lack of sleep I hope.

Sorry for the noise.

-Leif

Oct 22, 2010, 9:37:05 PM10/22/10

to sage-r...@googlegroups.com

On Oct 22, 2010, at 15:32 , Justin C. Walker wrote:

>

> On Oct 22, 2010, at 15:04 , Mitesh Patel wrote:

>

>> On 10/22/2010 02:00 AM, Mitesh Patel wrote:

>>> On 10/22/2010 01:27 AM, Justin C. Walker wrote:

>>>> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':

>>>>

>>>> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.

>>>> Five failures during testing (sage -t -long -force_lib):

>>>> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed

>>>> devel/sage/sage/calculus/desolvers.py # 1 doctests failed

>>>> devel/sage/sage/misc/trace.py # 1 doctests failed

>>>> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

>>>> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed

> [snip]

>> Justin, are the plotting.rst, desolvers.py, and assumptions.py errors

>> reproducible?

>

> I am trying this on the system where the failures occurred. If I run them individually, all three pass. I am rerunning the full test exactly as I did before now, and I will let you know what transpires.

Here is the result of rerunning the full 'ptestlong' suite:

devel/sage/sage/misc/trace.py # 1 doctests failed

devel/sage/sage/modules/free_module_element.pyx # 1 doctests failed

devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

I feel like I'm in a maze of twisty little passages, all subtly different :-}

Let me know if you want the log for this run, or if there is anything else I can provide.

Justin

--

Justin C. Walker, Curmudgeon at Large

Director

Institute for the Enhancement of the Director's income

-----------

Question 43:

What if the hokey pokey

really *is* what it’s all about?

--

Message has been deleted

Oct 23, 2010, 3:20:32 AM10/23/10

to sage-r...@googlegroups.com

On 2010-10-23 01:34, leif wrote:

> try;

> os.mkdir(foo)

> except OSError, err:

> if err.errno == 17:

> pass

> else:

> raise

> try;

> os.mkdir(foo)

> except OSError, err:

> if err.errno == 17:

> pass

> else:

> raise

I doubt that these errno numbers are portable. I'm not sure whether we

have access to the symbolic constants like EEXIST from Python.

Oct 23, 2010, 4:01:29 AM10/23/10

to sage-r...@googlegroups.com

These are available in the errno module:

http://docs.python.org/library/errno.html#errno.EEXIST

Should we instead report the problem to the matplotlib developers?

Oct 23, 2010, 5:33:15 AM10/23/10

to sage-release

Hej All,

I just did a build from scratch on OS X 10.6.4 using gcc 4.2.1

sage -testall gives two errors which fail if they are run again

individually later on.

Here are the failures

maarten-derickxs-macbook-pro:sage-4.6.rc0 maarten$ sage -t devel/sage/

sage/matrix/matrix2.pyx

sage -t "4.6.rc0/devel/sage/sage/matrix/matrix2.pyx"

Traceback (most recent call last):

File "/Users/maarten/.sage//tmp/matrix2.py", line 18, in <module>

cython(open('devel/sage/sage/matrix/matrix2.pyx').read())

File "cython_c.pyx", line 32, in sage.misc.cython_c.cython (sage/

misc/cython_c.c:656)

File "/Applications/sage/local/lib/python/site-packages/sage/server/

support.py", line 469, in cython_import_all

create_local_c_file=create_local_c_file)

File "/Applications/sage/local/lib/python/site-packages/sage/server/

support.py", line 446, in cython_import

create_local_c_file=create_local_c_file)

File "/Applications/sage/local/lib/python/site-packages/sage/misc/

cython.py", line 367, in cython

raise RuntimeError, "Error converting %s to C:\n%s\n%s"%(filename,

log, err)

RuntimeError: Error converting /Users/maarten/.sage//temp/

maarten_derickxs_macbook_pro.local/52312//tmp_0.spyx to C:

Error converting Pyrex file to C:

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

...

import sage.modules.free_module

import matrix_space

import berlekamp_massey

from sage.modules.free_module_element import is_FreeModuleElement

cdef class Matrix(matrix1.Matrix):

^

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

/Users/maarten/.sage/temp/maarten_derickxs_macbook_pro.local/52312/

spyx/

_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx/

_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx_0.pyx:

57:5: 'matrix1.pxd' not found

Error converting Pyrex file to C:

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

...

import sage.modules.free_module

import matrix_space

import berlekamp_massey

from sage.modules.free_module_element import is_FreeModuleElement

cdef class Matrix(matrix1.Matrix):

^

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

/Users/maarten/.sage/temp/maarten_derickxs_macbook_pro.local/52312/

spyx/

_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx/

_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx_0.pyx:

57:5: 'Matrix' is not declared

[5.2 s]

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

The following tests failed:

sage -t "4.6.rc0/devel/sage/sage/matrix/matrix2.pyx"

Total time for all tests: 5.2 seconds

maarten-derickxs-macbook-pro:sage-4.6.rc0 maarten$ sage -t "devel/

sage/sage/interfaces/r.py"sage -t "4.6.rc0/devel/sage/sage/interfaces/

r.py"

Traceback (most recent call last):

File "/Users/maarten/.sage//tmp/r.py", line 18, in <module>

from r import *

File "/Users/maarten/.sage/tmp/r.py", line 210, in <module>

from expect import Expect, ExpectElement, ExpectFunction,

FunctionElement

ImportError: No module named expect

[2.8 s]

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

The following tests failed:

sage -t "4.6.rc0/devel/sage/sage/interfaces/r.py"

Total time for all tests: 2.8 seconds

I just did a build from scratch on OS X 10.6.4 using gcc 4.2.1

sage -testall gives two errors which fail if they are run again

individually later on.

Here are the failures

maarten-derickxs-macbook-pro:sage-4.6.rc0 maarten$ sage -t devel/sage/

sage/matrix/matrix2.pyx

sage -t "4.6.rc0/devel/sage/sage/matrix/matrix2.pyx"

Traceback (most recent call last):

File "/Users/maarten/.sage//tmp/matrix2.py", line 18, in <module>

cython(open('devel/sage/sage/matrix/matrix2.pyx').read())

File "cython_c.pyx", line 32, in sage.misc.cython_c.cython (sage/

misc/cython_c.c:656)

File "/Applications/sage/local/lib/python/site-packages/sage/server/

support.py", line 469, in cython_import_all

create_local_c_file=create_local_c_file)

File "/Applications/sage/local/lib/python/site-packages/sage/server/

support.py", line 446, in cython_import

create_local_c_file=create_local_c_file)

File "/Applications/sage/local/lib/python/site-packages/sage/misc/

cython.py", line 367, in cython

raise RuntimeError, "Error converting %s to C:\n%s\n%s"%(filename,

log, err)

RuntimeError: Error converting /Users/maarten/.sage//temp/

maarten_derickxs_macbook_pro.local/52312//tmp_0.spyx to C:

Error converting Pyrex file to C:

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

...

import sage.modules.free_module

import matrix_space

import berlekamp_massey

from sage.modules.free_module_element import is_FreeModuleElement

cdef class Matrix(matrix1.Matrix):

^

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

/Users/maarten/.sage/temp/maarten_derickxs_macbook_pro.local/52312/

spyx/

_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx/

_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx_0.pyx:

57:5: 'matrix1.pxd' not found

Error converting Pyrex file to C:

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

...

import sage.modules.free_module

import matrix_space

import berlekamp_massey

from sage.modules.free_module_element import is_FreeModuleElement

cdef class Matrix(matrix1.Matrix):

^

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

/Users/maarten/.sage/temp/maarten_derickxs_macbook_pro.local/52312/

spyx/

_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx/

_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx_0.pyx:

57:5: 'Matrix' is not declared

[5.2 s]

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

The following tests failed:

sage -t "4.6.rc0/devel/sage/sage/matrix/matrix2.pyx"

Total time for all tests: 5.2 seconds

maarten-derickxs-macbook-pro:sage-4.6.rc0 maarten$ sage -t "devel/

sage/sage/interfaces/r.py"sage -t "4.6.rc0/devel/sage/sage/interfaces/

r.py"

Traceback (most recent call last):

File "/Users/maarten/.sage//tmp/r.py", line 18, in <module>

from r import *

File "/Users/maarten/.sage/tmp/r.py", line 210, in <module>

from expect import Expect, ExpectElement, ExpectFunction,

FunctionElement

ImportError: No module named expect

[2.8 s]

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

The following tests failed:

sage -t "4.6.rc0/devel/sage/sage/interfaces/r.py"

Total time for all tests: 2.8 seconds

Oct 23, 2010, 6:09:39 AM10/23/10

to sage-r...@googlegroups.com

On 10/22/2010 08:37 PM, Justin C. Walker wrote:

> On Oct 22, 2010, at 15:32 , Justin C. Walker wrote:

>> On Oct 22, 2010, at 15:04 , Mitesh Patel wrote:

>>> On 10/22/2010 02:00 AM, Mitesh Patel wrote:

>>>> On 10/22/2010 01:27 AM, Justin C. Walker wrote:

>>>>> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':

>>>>>

>>>>> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.

>>>>> Five failures during testing (sage -t -long -force_lib):

>>>>> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed

>>>>> devel/sage/sage/calculus/desolvers.py # 1 doctests failed

>>>>> devel/sage/sage/misc/trace.py # 1 doctests failed

>>>>> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

>>>>> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed

>> [snip]

>>> Justin, are the plotting.rst, desolvers.py, and assumptions.py errors

>>> reproducible?

>>

>> I am trying this on the system where the failures occurred. If I run them individually, all three pass. I am rerunning the full test exactly as I did before now, and I will let you know what transpires.

>

> Here is the result of rerunning the full 'ptestlong' suite:

>

> devel/sage/sage/misc/trace.py # 1 doctests failed

> devel/sage/sage/modules/free_module_element.pyx # 1 doctests failed

> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

>

> I feel like I'm in a maze of twisty little passages, all subtly different :-}

>

> Let me know if you want the log for this run, or if there is anything else I can provide.

> On Oct 22, 2010, at 15:32 , Justin C. Walker wrote:

>> On Oct 22, 2010, at 15:04 , Mitesh Patel wrote:

>>> On 10/22/2010 02:00 AM, Mitesh Patel wrote:

>>>> On 10/22/2010 01:27 AM, Justin C. Walker wrote:

>>>>> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':

>>>>>

>>>>> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.

>>>>> Five failures during testing (sage -t -long -force_lib):

>>>>> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed

>>>>> devel/sage/sage/calculus/desolvers.py # 1 doctests failed

>>>>> devel/sage/sage/misc/trace.py # 1 doctests failed

>>>>> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

>>>>> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed

>> [snip]

>>> Justin, are the plotting.rst, desolvers.py, and assumptions.py errors

>>> reproducible?

>>

>> I am trying this on the system where the failures occurred. If I run them individually, all three pass. I am rerunning the full test exactly as I did before now, and I will let you know what transpires.

>

> Here is the result of rerunning the full 'ptestlong' suite:

>

> devel/sage/sage/misc/trace.py # 1 doctests failed

> devel/sage/sage/modules/free_module_element.pyx # 1 doctests failed

> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed

>

> I feel like I'm in a maze of twisty little passages, all subtly different :-}

>

> Let me know if you want the log for this run, or if there is anything else I can provide.

Thanks, Justin. Could you give us a link to the new log or paste the

error from free_module_element.pyx?

Oct 23, 2010, 8:12:05 AM10/23/10

to sage-r...@googlegroups.com

Mitesh Patel wrote:

> On 10/23/2010 02:20 AM, Jeroen Demeyer wrote:

>> On 2010-10-23 01:34, leif wrote:

>>> try;

>>> os.mkdir(foo)

>>> except OSError, err:

>>> if err.errno == 17:

>>> pass

>>> else:

>>> raise

>>

>> I doubt that these errno numbers are portable. I'm not sure whether we

>> have access to the symbolic constants like EEXIST from Python.

> On 10/23/2010 02:20 AM, Jeroen Demeyer wrote:

>> On 2010-10-23 01:34, leif wrote:

>>> try;

>>> os.mkdir(foo)

>>> except OSError, err:

>>> if err.errno == 17:

>>> pass

>>> else:

>>> raise

>>

>> I doubt that these errno numbers are portable. I'm not sure whether we

>> have access to the symbolic constants like EEXIST from Python.

I doubt that the number differs on the supported platforms, but it's of

course better to use symbolic constants.

The code was just meant to illustrate /what/ to check, not /how/ ;-)

(I sometimes remember the numbers better than the names).

> These are available in the errno module:

>

> http://docs.python.org/library/errno.html#errno.EEXIST

Yep. Cf. #8677.

> Should we instead report the problem to the matplotlib developers?

Not instead, but also I think.

-Leif

Oct 23, 2010, 8:45:23 AM10/23/10

to sage-release

> Well, that was with the *old* PARI (Sage 4.5.3).

>

> -Leif

-Marshall

Oct 23, 2010, 10:05:35 AM10/23/10

to sage-r...@googlegroups.com

Yep. My comment referred to Jan Groenewald's post about a "mysterious

libpari segfault" Rob mentioned, which he reported for Sage 4.5.3 / PARI

2.3.5, but I see you could reproduce it with Sage 4.6.alpha3 / PARI

2.4.3.svn-12577, too.

-Leif

Oct 23, 2010, 12:20:41 PM10/23/10

to sage-r...@googlegroups.com

Here's the location of the new log file:

sage.math.washington.edu:~justin/logs/4.6.rc0-DQX-2.log

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.

--------

Oct 23, 2010, 3:01:56 PM10/23/10

to sage-release

ticket. I've also reported it upstream.

--

John

Oct 23, 2010, 5:58:56 PM10/23/10

to sage-r...@googlegroups.com

This is a Maxima error similar to one of the previous, unreproducible

errors:

sage -t -long -force_lib devel/sage/sage/modules/free_module_element.pyx

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

File

"/Users/Sage/sage-4.6.alpha0/devel/sage-main/sage/modules/free_module_element.pyx",

line 2102:

sage: integrate(r,t)

[...]

TypeError: Error executing code in Maxima

CODE:

sage102 : t$

Maxima ERROR:

sage102 : t$

stdin:44907:Incorrect syntax: Too many )'s

(%i719)

stdin:44960:Incorrect syntax: Illegal use of delimiter )

(%i720)

stdin:45027:Incorrect syntax: Premature termination of input at ;.

(%i721)

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

Please see

http://sage.math.washington.edu/home/justin/logs/4.6.rc0-DQX-2.log

for the full traceback.

Oct 24, 2010, 5:17:59 AM10/24/10

to sage-r...@googlegroups.com

On 10/22/2010 11:45 PM, Minh Nguyen wrote:

> For those who don't want to build the full documentation themselves,

> you can find the generated documentation at

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/

>

> Both the HTML and PDF versions are available. You can also download a

> compressed tarball of the full documentation, or view it from the

> above URL.

> For those who don't want to build the full documentation themselves,

> you can find the generated documentation at

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/

>

> Both the HTML and PDF versions are available. You can also download a

> compressed tarball of the full documentation, or view it from the

> above URL.

We've updated alpha.sagenb.org to 4.6.rc0. Let us know if there are

problems.

Oct 24, 2010, 7:06:02 PM10/24/10

to sage-release

Sorry, I did something wrong with the testing, the two docest errors I

reported should be ignored. Everything builds ok.

reported should be ignored. Everything builds ok.

Oct 25, 2010, 3:56:30 AM10/25/10

to sage-r...@googlegroups.com

On 10/25/10 12:06 AM, koffie wrote:

> Sorry, I did something wrong with the testing, the two docest errors I

> reported should be ignored. Everything builds ok.

>

> Sorry, I did something wrong with the testing, the two docest errors I

> reported should be ignored. Everything builds ok.

>

Why should they be ignored? I suspect its probably the usual problem that

parallel testing is unreliable.

Dave

Oct 25, 2010, 5:55:32 AM10/25/10

to sage-release

Since I accidentally tested the wrong version of sage (4.4.4 with some

patches which are work in progress). I did a "make" and then "sage -

testall" instead of a "make ptestlong" and I forgot that the sage

command for which I created a symlink in /usr/local/bin/sage still

pointed to the old install. I tested the right installation last

night. I got 4 doctest failures, which are all related.

sage -t -force_lib "devel/sage/sage/plot/plot3d/base.pyx"

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

File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/

base.pyx", line 1160:

sage: G.save(f)

Exception raised:

1231, in run_one_test

self.run_one_example(test, example, filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line

38, in run_one_example

OrigDocTestRunner.run_one_example(self, test, example,

filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line

1172, in run_one_example

compileflags, 1) in test.globs

File "<doctest __main__.example_35[4]>", line 1, in <module>

G.save(f)###line 1160:

sage: G.save(f)

File "base.pyx", line 1198, in

sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 1372, in save

self.load()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 155, in load

self.load_prepare()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 223, in load_prepare

self.im = Image.core.new(self.mode, self.size)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 36, in __getattr__

raise ImportError("The _imaging C module is not installed")

ImportError: The _imaging C module is not installed

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

File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/

base.pyx", line 1165:

sage: G.save(f, zoom=2, figsize=[5, 10])

Exception raised:

1231, in run_one_test

self.run_one_example(test, example, filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line

38, in run_one_example

OrigDocTestRunner.run_one_example(self, test, example,

filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line

1172, in run_one_example

compileflags, 1) in test.globs

File "<doctest __main__.example_35[5]>", line 1, in <module>

G.save(f, zoom=Integer(2), figsize=[Integer(5),

Integer(10)])###line 1165:

sage: G.save(f, zoom=2, figsize=[5, 10])

File "base.pyx", line 1198, in

sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 1372, in save

self.load()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 155, in load

self.load_prepare()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 223, in load_prepare

self.im = Image.core.new(self.mode, self.size)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 36, in __getattr__

raise ImportError("The _imaging C module is not installed")

ImportError: The _imaging C module is not installed

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

File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/

base.pyx", line 1170:

sage: G.save(f, viewer='jmol') # Looks the same

Exception raised:

1231, in run_one_test

self.run_one_example(test, example, filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line

38, in run_one_example

OrigDocTestRunner.run_one_example(self, test, example,

filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line

1172, in run_one_example

compileflags, 1) in test.globs

File "<doctest __main__.example_35[6]>", line 1, in <module>

G.save(f, viewer='jmol') # Looks the same###line 1170:

sage: G.save(f, viewer='jmol') # Looks the same

File "base.pyx", line 1198, in

sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 1372, in save

self.load()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 155, in load

self.load_prepare()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 223, in load_prepare

self.im = Image.core.new(self.mode, self.size)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 36, in __getattr__

raise ImportError("The _imaging C module is not installed")

ImportError: The _imaging C module is not installed

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

File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/

base.pyx", line 1175:

sage: cube().save(tmp_filename() + '.gif')

Exception raised:

1231, in run_one_test

self.run_one_example(test, example, filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line

38, in run_one_example

OrigDocTestRunner.run_one_example(self, test, example,

filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line

1172, in run_one_example

compileflags, 1) in test.globs

File "<doctest __main__.example_35[7]>", line 1, in <module>

cube().save(tmp_filename() + '.gif')###line 1175:

sage: cube().save(tmp_filename() + '.gif')

File "base.pyx", line 1198, in

sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 1372, in save

self.load()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 155, in load

self.load_prepare()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 223, in load_prepare

self.im = Image.core.new(self.mode, self.size)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 36, in __getattr__

raise ImportError("The _imaging C module is not installed")

ImportError: The _imaging C module is not installed

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

1 items had failures:

4 of 8 in __main__.example_35

***Test Failed*** 4 failures.

For whitespace errors, see the file /Users/maarten/.sage//

tmp/.doctest_base.py

[26.7 s]

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

The following tests failed:

sage -t -force_lib "devel/sage/sage/plot/plot3d/base.pyx"

Total time for all tests: 26.8 seconds

On Oct 25, 9:56 am, "Dr. David Kirkby" <david.kir...@onetel.net>

wrote:

patches which are work in progress). I did a "make" and then "sage -

testall" instead of a "make ptestlong" and I forgot that the sage

command for which I created a symlink in /usr/local/bin/sage still

pointed to the old install. I tested the right installation last

night. I got 4 doctest failures, which are all related.

sage -t -force_lib "devel/sage/sage/plot/plot3d/base.pyx"

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

File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/

base.pyx", line 1160:

sage: G.save(f)

Exception raised:

Traceback (most recent call last):

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
1231, in run_one_test

self.run_one_example(test, example, filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line

38, in run_one_example

OrigDocTestRunner.run_one_example(self, test, example,

filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line

1172, in run_one_example

compileflags, 1) in test.globs

File "<doctest __main__.example_35[4]>", line 1, in <module>

G.save(f)###line 1160:

sage: G.save(f)

File "base.pyx", line 1198, in

sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 1372, in save

self.load()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 155, in load

self.load_prepare()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 223, in load_prepare

self.im = Image.core.new(self.mode, self.size)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 36, in __getattr__

raise ImportError("The _imaging C module is not installed")

ImportError: The _imaging C module is not installed

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

File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/

base.pyx", line 1165:

sage: G.save(f, zoom=2, figsize=[5, 10])

Exception raised:

Traceback (most recent call last):

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
1231, in run_one_test

self.run_one_example(test, example, filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line

38, in run_one_example

OrigDocTestRunner.run_one_example(self, test, example,

filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line

1172, in run_one_example

compileflags, 1) in test.globs

File "<doctest __main__.example_35[5]>", line 1, in <module>

G.save(f, zoom=Integer(2), figsize=[Integer(5),

Integer(10)])###line 1165:

sage: G.save(f, zoom=2, figsize=[5, 10])

File "base.pyx", line 1198, in

sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 1372, in save

self.load()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 155, in load

self.load_prepare()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 223, in load_prepare

self.im = Image.core.new(self.mode, self.size)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 36, in __getattr__

raise ImportError("The _imaging C module is not installed")

ImportError: The _imaging C module is not installed

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

File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/

base.pyx", line 1170:

sage: G.save(f, viewer='jmol') # Looks the same

Exception raised:

Traceback (most recent call last):

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
1231, in run_one_test

self.run_one_example(test, example, filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line

38, in run_one_example

OrigDocTestRunner.run_one_example(self, test, example,

filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line

1172, in run_one_example

compileflags, 1) in test.globs

File "<doctest __main__.example_35[6]>", line 1, in <module>

G.save(f, viewer='jmol') # Looks the same###line 1170:

sage: G.save(f, viewer='jmol') # Looks the same

File "base.pyx", line 1198, in

sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 1372, in save

self.load()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 155, in load

self.load_prepare()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 223, in load_prepare

self.im = Image.core.new(self.mode, self.size)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 36, in __getattr__

raise ImportError("The _imaging C module is not installed")

ImportError: The _imaging C module is not installed

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

File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/

base.pyx", line 1175:

sage: cube().save(tmp_filename() + '.gif')

Exception raised:

Traceback (most recent call last):

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
1231, in run_one_test

self.run_one_example(test, example, filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line

38, in run_one_example

OrigDocTestRunner.run_one_example(self, test, example,

filename, compileflags)

File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line

1172, in run_one_example

compileflags, 1) in test.globs

File "<doctest __main__.example_35[7]>", line 1, in <module>

cube().save(tmp_filename() + '.gif')###line 1175:

sage: cube().save(tmp_filename() + '.gif')

File "base.pyx", line 1198, in

sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 1372, in save

self.load()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 155, in load

self.load_prepare()

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/ImageFile.py", line 223, in load_prepare

self.im = Image.core.new(self.mode, self.size)

File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/Image.py", line 36, in __getattr__

raise ImportError("The _imaging C module is not installed")

ImportError: The _imaging C module is not installed

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

1 items had failures:

4 of 8 in __main__.example_35

***Test Failed*** 4 failures.

For whitespace errors, see the file /Users/maarten/.sage//

tmp/.doctest_base.py

[26.7 s]

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

The following tests failed:

Total time for all tests: 26.8 seconds

On Oct 25, 9:56 am, "Dr. David Kirkby" <david.kir...@onetel.net>

wrote:

Oct 25, 2010, 6:07:37 AM10/25/10

to sage-release

After reading: "http://www.pythonware.com/products/pil/faq.htm" and

trying to manually import _imaging from sage I got the error:

sage: import _imaging

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

ImportError Traceback (most recent call

last)

/Applications/sage-4.6.rc0/<ipython console> in <module>()

ImportError: dlopen(/Applications/sage-4.6.rc0/local/lib/python2.6/

site-packages/PIL/_imaging.so, 2): Symbol not found:

_jpeg_resync_to_restart

Referenced from: /Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/_imaging.so

Expected in: flat namespace

in /Applications/sage-4.6.rc0/local/lib/python2.6/site-packages/PIL/

_imaging.so

sage:

A google search suggest this is an often experienced problem with

getting pill to work on snow leapard:

http://www.google.nl/search?sourceid=chrome&ie=UTF-8&q=ImportError+Symbol+not+found+_jpeg_resync_to_restart

trying to manually import _imaging from sage I got the error:

sage: import _imaging

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

ImportError Traceback (most recent call

last)

/Applications/sage-4.6.rc0/<ipython console> in <module>()

ImportError: dlopen(/Applications/sage-4.6.rc0/local/lib/python2.6/

site-packages/PIL/_imaging.so, 2): Symbol not found:

_jpeg_resync_to_restart

Referenced from: /Applications/sage-4.6.rc0/local/lib/python2.6/site-

packages/PIL/_imaging.so

Expected in: flat namespace

in /Applications/sage-4.6.rc0/local/lib/python2.6/site-packages/PIL/

_imaging.so

sage:

A google search suggest this is an often experienced problem with

getting pill to work on snow leapard:

http://www.google.nl/search?sourceid=chrome&ie=UTF-8&q=ImportError+Symbol+not+found+_jpeg_resync_to_restart

Oct 25, 2010, 6:23:57 AM10/25/10

to sage-r...@googlegroups.com

This is probably #10059. Ticket #9864 may be related.

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

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

Oct 25, 2010, 6:31:37 AM10/25/10

to sage-release

yeah that is exactly the same problem

On Oct 25, 12:23 pm, Mitesh Patel <qed...@gmail.com> wrote:

> On 10/25/2010 05:07 AM, koffie wrote:

>

>

>

>

>

>

>

>

>

> > After reading: "http://www.pythonware.com/products/pil/faq.htm" and

> > trying to manually import _imaging from sage I got the error:

>

> > sage: import _imaging

> > ---------------------------------------------------------------------------

> > ImportError Traceback (most recent call

> > last)

>

> > /Applications/sage-4.6.rc0/<ipython console> in <module>()

>

> > ImportError: dlopen(/Applications/sage-4.6.rc0/local/lib/python2.6/

> > site-packages/PIL/_imaging.so, 2): Symbol not found:

> > _jpeg_resync_to_restart

> > Referenced from: /Applications/sage-4.6.rc0/local/lib/python2.6/site-

> > packages/PIL/_imaging.so

> > Expected in: flat namespace

> > in /Applications/sage-4.6.rc0/local/lib/python2.6/site-packages/PIL/

> > _imaging.so

> > sage:

>

> > A google search suggest this is an often experienced problem with

> > getting pill to work on snow leapard:

> >http://www.google.nl/search?sourceid=chrome&ie=UTF-8&q=ImportError+Sy...

On Oct 25, 12:23 pm, Mitesh Patel <qed...@gmail.com> wrote:

> On 10/25/2010 05:07 AM, koffie wrote:

>

>

>

>

>

>

>

>

>

> > After reading: "http://www.pythonware.com/products/pil/faq.htm" and

> > trying to manually import _imaging from sage I got the error:

>

> > sage: import _imaging

> > ---------------------------------------------------------------------------

> > ImportError Traceback (most recent call

> > last)

>

> > /Applications/sage-4.6.rc0/<ipython console> in <module>()

>

> > ImportError: dlopen(/Applications/sage-4.6.rc0/local/lib/python2.6/

> > site-packages/PIL/_imaging.so, 2): Symbol not found:

> > _jpeg_resync_to_restart

> > Referenced from: /Applications/sage-4.6.rc0/local/lib/python2.6/site-

> > packages/PIL/_imaging.so

> > Expected in: flat namespace

> > in /Applications/sage-4.6.rc0/local/lib/python2.6/site-packages/PIL/

> > _imaging.so

> > sage:

>

> > A google search suggest this is an often experienced problem with

> > getting pill to work on snow leapard:

Oct 25, 2010, 9:37:40 AM10/25/10

to sage-r...@googlegroups.com

On 22 October 2010 10:53, leif <not.r...@online.de> wrote:

> Amen.

>

> Note that upgrading (the rebuild process, not the downloads) will

> probably now take longer than it used to, because now all packages that

> depend on new ones will get rebuilt.

>

> To reduce the number of (unfortunately unnecessarily) rebuilt packages,

> one could do the following *before* upgrading on any system other than

> SunOS/Solaris, Cygwin and HP-UX:

>

> touch spkg/installed/iconv-1.13.1.p3

>

> (This package is in fact only required/used on the above platforms, but

> "installing" it triggers the rebuild of *many* other packages on *every*

> platform. There's currently no other way to avoid this, sorry.)

> -Leif

That sounds sensible, but it should be relatively easy to integrate

that into the Sage upgrade process, so it is not necessary to manually

do this.

Dave

Oct 25, 2010, 11:20:08 AM10/25/10

to sage-r...@googlegroups.com

If it was, I would have done it. ;-)

Of course one could do the "touch" (depending on the platform we build

on) inside the downloaded / newly installed $SAGE_ROOT/spkg/install, but

since such "unnecessary" packages (and their versions) change with every

release, I didn't want to mess up the script with temporary ad-hoc code.

(We're going to put $SAGE_ROOT/spkg/install under revision control, see

#9433.)

Unfortunately the current build process is not very suited to address

platform-specific packages, i.e. the decision to actually install a

package is made inside its spkg-install, so 'make' will assume dependent

packages need to be rebuilt even if the spkg-install does effectively

nothing but "exit 0" (or the changes in a package only affect /some/

architecture, cf. #9530).

The situation is worse with packages like Fortran (and perhaps ATLAS);

the former makes up more than 11% (33 MB) of the "source" tarball

because it contains various Apple Darwin *binaries*, which of course

aren't used on any other platform, while e.g. the ATLAS package is afaik

not built on MacOS X (it uses different BLAS libraries). The Cephes

package is smaller, but also only used on Cygwin.

Note that the necessity to upgrade a package might also depend on the

version currently installed (not just the platform), so implementing a

"smart" upgrade gets even more complicated, and we currently have no

formal package descriptions which would simplify such.

I think in the long run, the "real" Makefile (spkg/standard/deps) should

be *generated*, and we should have platform-specific spkgs in separate

directories (also to be part of a /different/ tarball or separately

downloaded, which could be automated as well, though we currently don't

want downloads / internet access during the "real" build process). Our

current "configure" e.g. checks for prerequisites like gfortran on Linux

(giving instructions to install it if it isn't), so why not handle other

packages that way, too?

5ct

-Leif

Oct 25, 2010, 1:57:07 PM10/25/10

to sage-release

I did a new "make ptestlong" on my mac (os x 10.6.4 gcc 4.2.1) but

then with SAGE_CHECK=yes, hoping this would give more info. This

caused the check and hence the build to fail as jhpalmieri mentioned

already in the (now closed) ticket where the checking meganism for

python was correctly setup: http://trac.sagemath.org/sage_trac/ticket/9295

There seem to be open tickets for the check failing on Solaris 10:

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

And one for Opensolaris:

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

but not one for OS X.

Should I ad a similar one for OS X?

then with SAGE_CHECK=yes, hoping this would give more info. This

caused the check and hence the build to fail as jhpalmieri mentioned

already in the (now closed) ticket where the checking meganism for

python was correctly setup: http://trac.sagemath.org/sage_trac/ticket/9295

There seem to be open tickets for the check failing on Solaris 10:

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

And one for Opensolaris:

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

but not one for OS X.

Should I ad a similar one for OS X?

Oct 26, 2010, 5:18:02 AM10/26/10

to sage-release

Sage 4.6.rc0 built from scratch, all ptestlong passed,

on AMD X4 Phenom II, Fedora 13,

Georg

on AMD X4 Phenom II, Fedora 13,

Georg

Oct 30, 2010, 1:45:26 PM10/30/10

to sage-release

builds from scratch and passes testlong on Debian Squeeze x64.

On Oct 22, 8:19 am, Mitesh Patel <qed...@gmail.com> wrote:

> Ave Sage user-developers!

>

> We've released Sage 4.6.rc0.

>

> Source archive:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc...

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>

> Please build, test, and report! We'd love to hear about your

> experiences with this release.

>

> == Notes ==

>

> * The 4.6 cycle is still in feature freeze.

>

> * We've merged #9896 into this release so it gets more widely tested,

> but it still needs a review.

>

> * Jeroen Demeyer will manage the 4.6.1 cycle.

>

> == Tickets ==

>

> Closed:

>

> #9926: Doctest error in sage/schemes/generic/toric_divisor.py on OS X

> #10081: Another doctest failure in sage/graphs/graphs.py

>

> Merged in sage-4.6.rc0:

>

> #6235: John Palmieri: set MPLCONFIGDIR environment variable when Sage

> starts up [Reviewed by Leif Leonhardy]

> #8677: Volker Braun, William Stein: Race condition creating dirs during

> Sage build [Reviewed by Volker Braun, Mitesh Patel]

> #9210: Jason Grout: pkg-config's prefix statements in

> SAGE_LOCAL/lib/pkgconfig not changed upon Sage move [Reviewed by David

> Kirkby, Karl-Dieter Crisman]

> #9422: Nathann Cohen: Slightly improving is_forest [Reviewed by Leonardo

> Sampaio]

> #9798: Volker Braun: Accelerate Polyhedron constructor and fix cddlib

> output ordering [Reviewed by Dmitrii Pasechnik, Marshall Hampton]

> #9896: Leif Leonhardy: Upgrading from 4.5.3 to 4.6.alpha* can fail (not

> limited to MacOS X) [Reviewed by ???]

> #9959: Jeroen Demeyer: Get PARI/GP to stop starting automatically

> [Reviewed by John Cremona]

> #10041: Joris Vankerschaver: Doctest failure in

> sage/tensor/differential_forms.py [Reviewed by Niles Johnson]

> #10042: Dima Pasechnik: Doctest failure in

> sage/rings/polynomial/polynomial_element.pyx [Reviewed by Leif Leonhardy]

> #10053: Joris Vankerschaver: Equality testing instead of comparisons in

> differential forms code [Reviewed by Niles Johnson]

> #10098: Volker Braun: Flaky doctest in sage/interfaces/expect.py

> [Reviewed by Mitesh Patel]

> #10104: Mike Hansen: #9920 breaks bdisted binaries [Reviewed by Mitesh

> Patel]

On Oct 22, 8:19 am, Mitesh Patel <qed...@gmail.com> wrote:

> Ave Sage user-developers!

>

> We've released Sage 4.6.rc0.

>

> Source archive:

>

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/

>

> Please build, test, and report! We'd love to hear about your

> experiences with this release.

>

> == Notes ==

>

> * The 4.6 cycle is still in feature freeze.

>

> * We've merged #9896 into this release so it gets more widely tested,

> but it still needs a review.

>

> * Jeroen Demeyer will manage the 4.6.1 cycle.

>

> == Tickets ==

>

> Closed:

>

> #9926: Doctest error in sage/schemes/generic/toric_divisor.py on OS X

> #10081: Another doctest failure in sage/graphs/graphs.py

>

> Merged in sage-4.6.rc0:

>

> #6235: John Palmieri: set MPLCONFIGDIR environment variable when Sage

> starts up [Reviewed by Leif Leonhardy]

> #8677: Volker Braun, William Stein: Race condition creating dirs during

> Sage build [Reviewed by Volker Braun, Mitesh Patel]

> #9210: Jason Grout: pkg-config's prefix statements in

> SAGE_LOCAL/lib/pkgconfig not changed upon Sage move [Reviewed by David

> Kirkby, Karl-Dieter Crisman]

> #9422: Nathann Cohen: Slightly improving is_forest [Reviewed by Leonardo

> Sampaio]

> #9798: Volker Braun: Accelerate Polyhedron constructor and fix cddlib

> output ordering [Reviewed by Dmitrii Pasechnik, Marshall Hampton]

> #9896: Leif Leonhardy: Upgrading from 4.5.3 to 4.6.alpha* can fail (not

> limited to MacOS X) [Reviewed by ???]

> #9959: Jeroen Demeyer: Get PARI/GP to stop starting automatically

> [Reviewed by John Cremona]

> #10041: Joris Vankerschaver: Doctest failure in

> sage/tensor/differential_forms.py [Reviewed by Niles Johnson]

> #10042: Dima Pasechnik: Doctest failure in

> sage/rings/polynomial/polynomial_element.pyx [Reviewed by Leif Leonhardy]

> #10053: Joris Vankerschaver: Equality testing instead of comparisons in

> differential forms code [Reviewed by Niles Johnson]

> #10098: Volker Braun: Flaky doctest in sage/interfaces/expect.py

> [Reviewed by Mitesh Patel]

> #10104: Mike Hansen: #9920 breaks bdisted binaries [Reviewed by Mitesh

> Patel]

Reply all

Reply to author

Forward

0 new messages