Releasing sage-4.8

95 views
Skip to first unread message

Jeroen Demeyer

unread,
Jan 20, 2012, 3:36:18 AM1/20/12
to sage-r...@googlegroups.com
Let's release sage-4.8:
http://boxen.math.washington.edu/home/release/sage-4.8/

Webmaster: please update the download pages, update the documentation.

Also put in place the *optional package*
http://wstein.org/home/ohanar/cremona-database/database_cremona_ellcurve-20120113.spkg

The buildbots are currently building binaries, results will appear at
http://boxen.math.washington.edu/home/buildbot/binaries/sage/

Jeroen Demeyer

unread,
Jan 20, 2012, 6:20:13 AM1/20/12
to sage-r...@googlegroups.com

Also: somebody who can should bump the Trac milestone from sage-4.8 to
sage-5.0 for all open tickets.

Harald Schilly

unread,
Jan 20, 2012, 8:49:02 AM1/20/12
to sage-r...@googlegroups.com


On Friday, January 20, 2012 9:36:18 AM UTC+1, Jeroen Demeyer wrote:

The buildbots are currently building binaries, results will appear at
http://boxen.math.washington.edu/home/buildbot/binaries/sage/


ok! source is on the server, also the additional optional spkg.  i've already seen some binaries and will copy them later  today. i assume, the buildbot is still not configured to make a ubuntu 32bit? i started a manual build right now...

h

Jeroen Demeyer

unread,
Jan 20, 2012, 8:51:12 AM1/20/12
to sage-r...@googlegroups.com
On 2012-01-20 14:49, Harald Schilly wrote:
> ok! source is on the server, also the additional optional spkg. i've
> already seen some binaries and will copy them later today. i assume,
> the buildbot is still not configured to make a ubuntu 32bit?
Yes, we don't have such a machine (yet?) on the buildbot.

Harald Schilly

unread,
Jan 20, 2012, 8:53:09 AM1/20/12
to sage-r...@googlegroups.com
On Fri, Jan 20, 2012 at 14:51, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Yes, we don't have such a machine (yet?) on the buildbot.

there is a "ubuntu32" machine on boxen, where is even a "buildbot"
directory and script in it. i just don't know anything about how to
configure it, but at some point in time it either has worked or
someone already tried to get it working.

h

Jeroen Demeyer

unread,
Jan 20, 2012, 8:57:54 AM1/20/12
to sage-r...@googlegroups.com
On 2012-01-20 14:53, Harald Schilly wrote:
> On Fri, Jan 20, 2012 at 14:51, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>> Yes, we don't have such a machine (yet?) on the buildbot.
>
> there is a "ubuntu32" machine on boxen
I could try setting up the buildbot, but somebody needs to make an
account for the buildbot@ubuntu32 and copy .ssh/id_rsa.pub to
.ssh/authorized_keys.

Minh Nguyen

unread,
Jan 20, 2012, 6:32:42 AM1/20/12
to sage-r...@googlegroups.com, Jeroen Demeyer
On Fri, Jan 20, 2012 at 10:20 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Also: somebody who can should bump the Trac milestone from sage-4.8 to
> sage-5.0 for all open tickets.

Done.

--
Regards,
Minh Van Nguyen
http://sage.math.washington.edu/home/mvngu/

Minh Nguyen

unread,
Jan 21, 2012, 7:01:01 AM1/21/12
to sage-r...@googlegroups.com, Jeroen Demeyer, Harald Schilly
Hi Jeroen,

On Fri, Jan 20, 2012 at 7:36 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Webmaster: please update the download pages, update the documentation.

The documentation has been updated. I took some time figuring out
what went wrong with my update script. The problem was due to the new
format of the result of the command

$ sage --version

Everything is OK now, the update script has been... er... updated.

@Harald
The change log for Sage 4.8 is at

http://sage.math.washington.edu/home/mvngu/apps/rnotes/announce/sage-4.8.txt

The cumulative change log is at

http://sage.math.washington.edu/home/mvngu/apps/rnotes/announce/changelog.txt

Franco Saliola

unread,
Jan 22, 2012, 2:05:43 PM1/22/12
to sage-r...@googlegroups.com
On Fri, Jan 20, 2012 at 3:36 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Let's release sage-4.8:
> http://boxen.math.washington.edu/home/release/sage-4.8/

Is there an easy way to determine what changed between sage-4.8.rc0
and sage-4.8? I checked the logs [1] but didn't find anything. I'm
asking because I was able to successfully install rc0, but the build
hangs on the official release (once it hanged with scipy and twice now
while building MASS). I checked the md5 sum....

I'm running Mac OS X 10.6.8:

$ uname -a
Darwin lacim-macpro-02 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7
16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 i386

[1] http://boxen.math.washington.edu/home/release/sage-4.8/logs/sage-4.8.txt

Franco

--

Samuel Lelievre

unread,
Jan 22, 2012, 3:41:29 PM1/22/12
to sage-r...@googlegroups.com
Franco Saliola wrote:
Is there an easy way to determine what changed between sage-4.8.rc0
and sage-4.8? I checked the logs [1] but didn't find anything. I'm
asking because I was able to successfully install rc0, but the build
hangs on the official release (once it hanged with scipy and twice now
while building MASS). I checked the md5 sum....

I'm running Mac OS X 10.6.8:

$ uname -a
Darwin lacim-macpro-02 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7
16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 i386

[1] http://boxen.math.washington.edu/home/release/sage-4.8/logs/sage-4.8.txt

Trouble here too building sage-4.8 on Mac OS X 10.6.8.
Build failed on numpy. Terminal output from the build:

Samuel

François Bissey

unread,
Jan 22, 2012, 3:51:09 PM1/22/12
to sage-r...@googlegroups.com
Your python build is actually where things are going wrong:
2.6.4.p13/src/Modules/_ctypes/libffi_osx/powerpc/ppc64-darwin_closure.o -
L/Applications/sage-4.8/local/lib -L/opt/local/lib -L/usr/local/lib -o
build/lib.macosx-10.6-x86_64-2.6/_ctypes.so
*** WARNING: renaming "_ctypes" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_ctypes.so, 2): Symbol not found:
_PyUnicodeUCS4_AsEncodedString
Referenced from:
/Applications/sage-4.8/spkg/build/python-2.6.4.p13/src/build/lib.macosx-10.6-
x86_64-2.6/_ctypes.so
Expected in: flat namespace
in
/Applications/sage-4.8/spkg/build/python-2.6.4.p13/src/build/lib.macosx-10.6-
x86_64-2.6/_ctypes.so

Failed to find the necessary bits to build these modules:
bsddb185 dl imageop
linuxaudiodev ossaudiodev spwd
sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.


Failed to build these modules:
_ctypes _elementtree _json
_locale _multibytecodec _sqlite3
_ssl _testcapi _tkinter
array cPickle operator
pyexpat unicodedata


_ctypes, sqlite3, cPickle and operator which is directly incriminated in your
numpy error...
We'll have to dig why your python's gone foobar.

Francois

Jeroen Demeyer

unread,
Jan 22, 2012, 4:08:48 PM1/22/12
to sage-r...@googlegroups.com
On 2012-01-22 20:05, Franco Saliola wrote:
> On Fri, Jan 20, 2012 at 3:36 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>> Let's release sage-4.8:
>> http://boxen.math.washington.edu/home/release/sage-4.8/
>
> Is there an easy way to determine what changed between sage-4.8.rc0
> and sage-4.8? I checked the logs [1] but didn't find anything.
There are *no* changes from sage-4.8.rc0 to sage-4.8.

Harald Schilly

unread,
Jan 22, 2012, 4:15:33 PM1/22/12
to sage-r...@googlegroups.com
On Sun, Jan 22, 2012 at 20:05, Franco Saliola <sal...@gmail.com> wrote:
> Is there an easy way to determine what changed between sage-4.8.rc0
> and sage-4.8?

one easy way (for the sage lib) is, to check the online repository:
http://hg.sagemath.org/sage-main/
at the top (right now when I wrote this) is a tag for the 4.8rc0 and
right above is the 4.8. nothing except the version numbering has
changed.

h

Samuel Lelievre

unread,
Jan 22, 2012, 4:46:09 PM1/22/12
to sage-r...@googlegroups.com
On 2012-01-22, François Bissey wrote:
On Sun, 22 Jan 2012 21:41:29 Samuel Lelievre wrote:
> Franco Saliola wrote:
> > Is there an easy way to determine what changed between sage-4.8.rc0
> > and sage-4.8? I checked the logs [1] but didn't find anything. I'm
> > asking because I was able to successfully install rc0, but the build
> > hangs on the official release (once it hanged with scipy and twice now
> > while building MASS). I checked the md5 sum....
> >
> > I'm running Mac OS X 10.6.8:
> >
> > $ uname -a
> > Darwin lacim-macpro-02 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7
> > 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 i386
> >
> > [1]
> > http://boxen.math.washington.edu/home/release/sage-4.8/logs/sage-4.8.txt
>
> Trouble here too building sage-4.8 on Mac OS X 10.6.8.
> Build failed on numpy. Terminal output from the build:
>   http://carva.org/samuel.lelievre/s/l/s48_osx10.6.8_build_fail.txt
>
Your python build is actually where things are going wrong:
[...]
We'll have to dig why your python's gone foobar.

Could it be because I installed Parallel Python?

Otherwise, how can we dig what went wrong?

Samuel

François Bissey

unread,
Jan 22, 2012, 5:23:17 PM1/22/12
to sage-r...@googlegroups.com
I am not sure about parallel python. I would be looking to your toolchain
first. Did you change anything to xcode between rc0 and final?
I'll take a closer look at your python build log.

Francois

François Bissey

unread,
Jan 22, 2012, 5:46:38 PM1/22/12
to sage-r...@googlegroups.com
About you build logs. Would you happen to still have the logs from rc0?
I would very much like to compare it with your current logs for python.
They should live under spkg/logs.

Francois

Samuel Lelievre

unread,
Jan 22, 2012, 5:47:26 PM1/22/12
to sage-r...@googlegroups.com
I don't know what you mean by my toolchain.
I actually never tried building sage-4.8.rc0.
I never changed a thing to my xcode.
Samuel

François Bissey

unread,
Jan 22, 2012, 5:52:33 PM1/22/12
to sage-r...@googlegroups.com

Sorry I looked at the begining of the thread and didn't notice that it
wasn't the same person. By toolchain I mean gcc and friends.
Could you try ./sage -f python-2.6.4.p13
and post the log if it actually does build something?

Francois

Samuel Lelievre

unread,
Jan 22, 2012, 6:14:34 PM1/22/12
to sage-r...@googlegroups.com

François Bissey

unread,
Jan 22, 2012, 8:00:56 PM1/22/12
to sage-r...@googlegroups.com
It seems too but you don't get a working python. Very much the same
as your original log.
You could see like this. The python you built is usable to some extent but
cannot be used to build anything involving distutils.
There seem to be something wrong about unicode on your machine and
it trickles down and break all these other bits.
Never seen it before.

Francois

François Bissey

unread,
Jan 22, 2012, 9:11:07 PM1/22/12
to sage-r...@googlegroups.com
Just to further my point about unicode in your install:
grep "*** WARNING" s48_build_python-2.6.4.p13_ok.txt
*** WARNING: renaming "array" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/array.so, 2): Symbol not found:
_PyUnicodeUCS4_FromUnicode
*** WARNING: renaming "operator" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/operator.so, 2): Symbol not found:
__PyUnicodeUCS4_AsDefaultEncodedString
*** WARNING: renaming "_json" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_json.so, 2): Symbol not found:
_PyUnicodeUCS4_DecodeUTF8
*** WARNING: renaming "_testcapi" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_testcapi.so, 2): Symbol not found:
_PyUnicodeUCS4_Decode
*** WARNING: renaming "unicodedata" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/unicodedata.so, 2): Symbol not found:
_PyUnicodeUCS4_FromUnicode
*** WARNING: renaming "_locale" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_locale.so, 2): Symbol not found:
_PyUnicodeUCS4_AsWideChar
*** WARNING: renaming "cPickle" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/cPickle.so, 2): Symbol not found:
_PyUnicodeUCS4_AsUTF8String
*** WARNING: renaming "_ssl" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_ssl.so, 2): Symbol not found:
_PyUnicodeUCS4_DecodeUTF8
*** WARNING: renaming "_sqlite3" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_sqlite3.so, 2): Symbol not found:
_PyUnicodeUCS4_AsUTF8String
*** WARNING: renaming "pyexpat" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/pyexpat.so, 2): Symbol not found:
_PyUnicodeUCS4_Decode
*** WARNING: renaming "_elementtree" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_elementtree.so, 2): Symbol not found:
_PyUnicodeUCS4_Decode
*** WARNING: renaming "_multibytecodec" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_multibytecodec.so, 2): Symbol not
found: _PyUnicodeUCS4_FromUnicode
*** WARNING: renaming "_tkinter" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_tkinter.so, 2): Symbol not found:
_PyUnicodeUCS4_AsUTF8String

*** WARNING: renaming "_ctypes" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_ctypes.so, 2): Symbol not found:
_PyUnicodeUCS4_AsEncodedString
*** WARNING: renaming "array" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/array.so, 2): Symbol not found:
_PyUnicodeUCS4_FromUnicode
*** WARNING: renaming "operator" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/operator.so, 2): Symbol not found:
__PyUnicodeUCS4_AsDefaultEncodedString
*** WARNING: renaming "_json" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_json.so, 2): Symbol not found:
_PyUnicodeUCS4_DecodeUTF8
*** WARNING: renaming "_testcapi" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_testcapi.so, 2): Symbol not found:
_PyUnicodeUCS4_Decode
*** WARNING: renaming "unicodedata" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/unicodedata.so, 2): Symbol not found:
_PyUnicodeUCS4_FromUnicode
*** WARNING: renaming "_locale" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_locale.so, 2): Symbol not found:
_PyUnicodeUCS4_AsWideChar
*** WARNING: renaming "cPickle" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/cPickle.so, 2): Symbol not found:
_PyUnicodeUCS4_AsUTF8String
*** WARNING: renaming "_ssl" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_ssl.so, 2): Symbol not found:
_PyUnicodeUCS4_DecodeUTF8
*** WARNING: renaming "_sqlite3" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_sqlite3.so, 2): Symbol not found:
_PyUnicodeUCS4_AsUTF8String
*** WARNING: renaming "pyexpat" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/pyexpat.so, 2): Symbol not found:
_PyUnicodeUCS4_Decode
*** WARNING: renaming "_elementtree" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_elementtree.so, 2): Symbol not found:
_PyUnicodeUCS4_Decode
*** WARNING: renaming "_multibytecodec" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_multibytecodec.so, 2): Symbol not
found: _PyUnicodeUCS4_FromUnicode
*** WARNING: renaming "_tkinter" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_tkinter.so, 2): Symbol not found:
_PyUnicodeUCS4_AsUTF8String

*** WARNING: renaming "_ctypes" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_ctypes.so, 2): Symbol not found:
_PyUnicodeUCS4_AsEncodedString
*** WARNING: renaming "array" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/array.so, 2): Symbol not found:
_PyUnicodeUCS4_FromUnicode
*** WARNING: renaming "operator" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/operator.so, 2): Symbol not found:
__PyUnicodeUCS4_AsDefaultEncodedString
*** WARNING: renaming "_json" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_json.so, 2): Symbol not found:
_PyUnicodeUCS4_DecodeUTF8
*** WARNING: renaming "_testcapi" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_testcapi.so, 2): Symbol not found:
_PyUnicodeUCS4_Decode
*** WARNING: renaming "unicodedata" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/unicodedata.so, 2): Symbol not found:
_PyUnicodeUCS4_FromUnicode
*** WARNING: renaming "_locale" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_locale.so, 2): Symbol not found:
_PyUnicodeUCS4_AsWideChar
*** WARNING: renaming "cPickle" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/cPickle.so, 2): Symbol not found:
_PyUnicodeUCS4_AsUTF8String
*** WARNING: renaming "_ssl" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_ssl.so, 2): Symbol not found:
_PyUnicodeUCS4_DecodeUTF8
*** WARNING: renaming "_sqlite3" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_sqlite3.so, 2): Symbol not found:
_PyUnicodeUCS4_AsUTF8String
*** WARNING: renaming "pyexpat" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/pyexpat.so, 2): Symbol not found:
_PyUnicodeUCS4_Decode
*** WARNING: renaming "_elementtree" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_elementtree.so, 2): Symbol not found:
_PyUnicodeUCS4_Decode
*** WARNING: renaming "_multibytecodec" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_multibytecodec.so, 2): Symbol not
found: _PyUnicodeUCS4_FromUnicode
*** WARNING: renaming "_tkinter" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_tkinter.so, 2): Symbol not found:
_PyUnicodeUCS4_AsUTF8String

*** WARNING: renaming "_ctypes" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-2.6/_ctypes.so, 2): Symbol not found:
_PyUnicodeUCS4_AsEncodedString

It is not finding the library or possibly the right library, so you may have a
point with parallel python if it tries to use that.

Francois

Jeroen Demeyer

unread,
Jan 22, 2012, 11:00:17 PM1/22/12
to sage-r...@googlegroups.com
On 2012-01-22 20:05, Franco Saliola wrote:
> Is there an easy way to determine what changed between sage-4.8.rc0
> and sage-4.8?

To be very exact: by comparing the rsync tarballs, apart from .hg*
files, these are the only changed files between sage-4.8.rc0 and sage-4.8:

spkg/standard/VERSION.txt
spkg/standard/sage/PKG-INFO
spkg/standard/sage/c_lib/.sconsign.dblite
spkg/standard/sage/sage/version.py
spkg/standard/sage_scripts/sage-banner

(the last 4 are files in the Sage library)

There are also files which didn't change but whose timestamp changed.

Dima Pasechnik

unread,
Jan 23, 2012, 4:11:55 AM1/23/12
to sage-r...@googlegroups.com
for some reason I can't view this log; it leads to 
and then I see

This webpage is not available

The connection to www.math.u-psud.fr was interrupted.

Here are some suggestions:

....

Samuel Lelievre

unread,
Jan 23, 2012, 7:14:23 AM1/23/12
to sage-r...@googlegroups.com


2012/1/23 Dima Pasechnik <dim...@gmail.com>

for some reason I can't view this log; it leads to 
and then I see

Dima Pasechnik

unread,
Jan 23, 2012, 7:46:26 AM1/23/12
to sage-r...@googlegroups.com
you've got that bizarre
"Symbol not found: _PyUnicodeUCS4_FromUnicode"
there in the middle of the log...
It indicates something like Unicode vs non-Unicode clash.
Do you have anything dodgy in /usr/local/lib, or in /opt/local/lib ?!



[....]
building 'array' extension
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/Applications/sage-4.8/spkg/build/python-2.6.4.p13/src/./Include -I. -IInclude -I./Include -I/Applications/sage-4.8/local/include -I/opt/local/include -I/Applications/sage-4.8/spkg/build/python-2.6.4.p13/src/Include -I/Applications/sage-4.8/spkg/build/python-2.6.4.p13/src -c /Applications/sage-4.8/spkg/build/python-2.6.4.p13/src/Modules/arraymodule.c -o build/temp.macosx-10.6-x86_64-2.6/Applications/sage-4.8/spkg/build/python-2.6.4.p13/src/Modules/arraymodule.o
gcc -L/Applications/sage-4.8/local/lib -L/opt/local/lib -bundle -undefined dynamic_lookup -L/Applications/sage-4.8/local/lib -L/opt/local/lib -I. -IInclude -I./Include -I/Applications/sage-4.8/local/include -I/opt/local/include build/temp.macosx-10.6-x86_64-2.6/Applications/sage-4.8/spkg/build/python-2.6.4.p13/src/Modules/arraymodule.o -L/Applications/sage-4.8/local/lib -L/opt/local/lib -L/usr/local/lib -o build/lib.macosx-10.6-x86_64-2.6/array.so
*** WARNING: renaming "array" since importing it failed: dlopen(build/lib.macosx-10.6-x86_64-2.6/array.so, 2): Symbol not found: _PyUnicodeUCS4_FromUnicode
  Referenced from: /Applications/sage-4.8/spkg/build/python-2.6.4.p13/src/build/lib.macosx-10.6-x86_64-2.6/array.so
  Expected in: flat namespace
[...]

Samuel Lelievre

unread,
Jan 23, 2012, 9:32:56 AM1/23/12
to sage-r...@googlegroups.com
On 2012-01-23, Dima Pasechnik wrote:
you've got that bizarre
"Symbol not found: _PyUnicodeUCS4_FromUnicode"
there in the middle of the log...
It indicates something like Unicode vs non-Unicode clash.
Do you have anything dodgy in /usr/local/lib, or in /opt/local/lib ?!

There is not much in /usr/local/bin:

$ ls /usr/local/lib
ImageMagick-6.6.1 ImageMagick-6.6.9

and I remove any /opt/* from my PATH before building Sage:

$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/texbin:/usr/X11R6/bin

but in case it still matters what is in /opt/local/bin, see:

Samuel

Dima Pasechnik

unread,
Jan 23, 2012, 10:03:34 AM1/23/12
to sage-r...@googlegroups.com


On Monday, 23 January 2012 22:32:56 UTC+8, Samuel Lelievre wrote:
On 2012-01-23, Dima Pasechnik wrote:
you've got that bizarre
"Symbol not found: _PyUnicodeUCS4_FromUnicode"
there in the middle of the log...
It indicates something like Unicode vs non-Unicode clash.
Do you have anything dodgy in /usr/local/lib, or in /opt/local/lib ?!

There is not much in /usr/local/bin:

$ ls /usr/local/lib
ImageMagick-6.6.1 ImageMagick-6.6.9

and I remove any /opt/* from my PATH before building Sage:

it's not enough; if you look what pops up in -L options to the linker, you see it's still there, no 
matter what your PATH says.

Lately, we often saw an old libiconv lying somewhere (usually comes from a TeX installation)
that nukes a MacOSX install.

What you should  do, before building sage, is to rename your /usr/local to something like /foo/usr/local
and your /opt/local to /foo/usr/local...

kcrisman

unread,
Jan 23, 2012, 8:25:20 PM1/23/12
to sage-release
Upgrading from 4.8.rc0 actually turns out to be annoying on Mac - I
get all these hgmerge things popping up. And then:


Successfully installed sage-4.8
Now cleaning up tmp files.
Making Sage/Python scripts relocatable...
Finished installing sage-4.8.spkg
/Users/.../sage-4.8.rc0/spkg/pipestatus "sage-spkg ${SAGE_SPKG_OPTS}
gap-4.4.12.p6 2>&1" "tee -a /Users/.../Downloads/sage-4.8.rc0/spkg/
logs/gap-4.4.12.p6.log"
gap-4.4.12.p6
Machine:


So now it's merrily recompiling GAP. ??? And now moin.

I thought we were at least supposed to be able to upgrade from alphas/
betas/rcs to the final release, but apparently the *only* upgrade that
now is supported is from a previous final release? (I knew about the
other breakages.)

- kcrisman

Jeroen Demeyer

unread,
Jan 24, 2012, 3:44:04 AM1/24/12
to sage-r...@googlegroups.com
On 2012-01-24 02:25, kcrisman wrote:
> I thought we were at least supposed to be able to upgrade from alphas/
> betas/rcs to the final release
No, this is not supported.

Upgrades are supported *from* any stable release *to* anything.

Franco Saliola

unread,
Jan 24, 2012, 8:53:16 AM1/24/12
to sage-r...@googlegroups.com

This is very bizarre. I still can't seem to compile sage-4.8. I've
tried several times and it seems to hang right here:

begin installing recommended package MASS

I tried re-downloading the tarball from two different mirrors. I tried
re-compiling 4.8.rc0 again, and that worked. So I don't know how to
debug this. Since there are no changes, I have a working copy of
sage-4.8, so I am happy about that.

Franco

--

kcrisman

unread,
Jan 24, 2012, 9:26:33 AM1/24/12
to sage-release


On Jan 24, 8:53 am, Franco Saliola <sali...@gmail.com> wrote:
> On Sun, Jan 22, 2012 at 4:08 PM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> > On 2012-01-22 20:05, Franco Saliola wrote:
> >> On Fri, Jan 20, 2012 at 3:36 AM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> >>> Let's release sage-4.8:
> >>>http://boxen.math.washington.edu/home/release/sage-4.8/
>
> >> Is there an easy way to determine what changed between sage-4.8.rc0
> >> and sage-4.8? I checked the logs [1] but didn't find anything.
> > There are *no* changes from sage-4.8.rc0 to sage-4.8.
>
> This is very bizarre. I still can't seem to compile sage-4.8. I've
> tried several times and it seems to hang right here:
>
>     begin installing recommended package MASS
>
> I tried re-downloading the tarball from two different mirrors. I tried
> re-compiling 4.8.rc0 again, and that worked. So I don't know how to
> debug this. Since there are no changes, I have a working copy of
> sage-4.8, so I am happy about that.

See http://trac.sagemath.org/sage_trac/ticket/12201, which seems to be
exactly the same problem.

This is particularly weird because it doesn't seem to be easy to
predict! These are the only two occurrences of this thus far, though
presumably there will be others. I'm sorry I'm clueless about what
would cause this.

- kcrisman

kcrisman

unread,
Jan 24, 2012, 9:26:57 AM1/24/12
to sage-release
Sorry, I thought it was as long as there existed a stable release in
the chain :)

kcrisman

unread,
Jan 24, 2012, 9:29:18 AM1/24/12
to sage-release
Is someone going to create Sage 4.8 binaries for 32-bit Intel Mac
OSX? I only see 64-bit ones on the mirrors thus far, but many of us
have

$ uname -p
i386

so I don't think those will work for middle-aged Intel Macs. (?)

If someone had a 10.5 machine to do it on, that would be even more
generally useful, presumably. (?)

- kcrisman

Dima Pasechnik

unread,
Jan 24, 2012, 9:42:23 PM1/24/12
to sage-r...@googlegroups.com
perhaps one should investigate cross-compiling options, after all...
These vintage things are dying out...
(I have 2 dead (powerblocks!) 32-bit laptops now, one x86, one Powerbook PPC)

kcrisman

unread,
Jan 24, 2012, 10:20:33 PM1/24/12
to sage-release


On Jan 24, 9:42 pm, Dima Pasechnik <dimp...@gmail.com> wrote:
> perhaps one should investigate cross-compiling options, after all...
> These vintage things are dying out...

Well, my computer is only two years old! I don't know if that counts
as vintage. I think it can run 64-bit and compile 64-bit, but uname
returns i386. Maybe I'm misinforming myself.

Volker Braun

unread,
Jan 25, 2012, 12:29:51 PM1/25/12
to sage-r...@googlegroups.com
On Tuesday, January 24, 2012 7:20:33 PM UTC-8, kcrisman wrote:
Well, my computer is only two years old!  I don't know if that counts
as vintage.  I think it can run 64-bit and compile 64-bit, but uname
returns i386.  Maybe I'm misinforming myself.

Probably true. Apple chose the slightly wonky combination of running a 64-bit userspace on top of a 32-bit kernel during a transition period. Your Mac is probably new enough that you can boot into a 64bit kernel by holding "6"+"4" while booting up. But regardless of the kernel you should be able to run the 64-bit Sage binaries.

Afair all intel Macs return uname -p == i386. 

kcrisman

unread,
Jan 25, 2012, 2:08:20 PM1/25/12
to sage-release
So that uname -m and uname -p are different on some Macs? The name of
the binary is

sage-4.8-OSX-64bit-10.6-x86_64-Darwin.dmg

on the downloads page, and that last bit is added automatically by
sage-bdist. My machine returns i386 for both of these flags.

Justin C. Walker

unread,
Jan 25, 2012, 3:43:38 PM1/25/12
to sage-r...@googlegroups.com

On Jan 25, 2012, at 11:08 , kcrisman wrote:
>
> On Jan 25, 12:29 pm, Volker Braun <vbraun.n...@gmail.com> wrote:
>> On Tuesday, January 24, 2012 7:20:33 PM UTC-8, kcrisman wrote:
>>
>>> Well, my computer is only two years old! I don't know if that counts
>>> as vintage. I think it can run 64-bit and compile 64-bit, but uname
>>> returns i386. Maybe I'm misinforming myself.
>>
>> Probably true. Apple chose the slightly wonky combination of running a
>> 64-bit userspace on top of a 32-bit kernel during a transition period. Your
>> Mac is probably new enough that you can boot into a 64bit kernel by holding
>> "6"+"4" while booting up. But regardless of the kernel you should be able
>> to run the 64-bit Sage binaries.
>>
>> Afair all intel Macs return uname -p == i386.
>
> So that uname -m and uname -p are different on some Macs?

Yup. And maybe some "other" systems as well. "-p" is the processor architecture (i386); "-m" is "hardware name" ("x86_64"). I suspect these values are at the mercy of the OS builders, so YMMV
" The uname utility conforms to IEEE Std 1003.2-1992 (``POSIX.2''). The -p
option is an extension to the standard."
(from the (10.7/10.6) man pages for 'uname').

I think Volker is correct: all Intel Macs use -p:i386.

Justin

--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
When LuteFisk is outlawed,
Only outlaws will have LuteFisk
--------

Bill Hart

unread,
Jan 25, 2012, 4:59:18 PM1/25/12
to sage-r...@googlegroups.com


On Wednesday, 25 January 2012, Volker Braun <vbrau...@gmail.com> wrote:
> On Tuesday, January 24, 2012 7:20:33 PM UTC-8, kcrisman wrote:
>>
>> Well, my computer is only two years old!  I don't know if that counts
>> as vintage.  I think it can run 64-bit and compile 64-bit, but uname
>> returns i386.  Maybe I'm misinforming myself.
>
> Probably true. Apple chose the slightly wonky combination of running a 64-bit userspace on top of a 32-bit kernel during a transition period. Your Mac is probably new enough that you can boot into a 64bit kernel by holding "6"+"4" while booting up.

What happens if you hold down "1"+"2"+"8"?


>But regardless of the kernel you should be able to run the 64-bit Sage binaries.
> Afair all intel Macs return uname -p == i386. 
>
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/sage-release/-/C577SldjcZsJ.
> 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.
>

Dima Pasechnik

unread,
Jan 26, 2012, 12:32:11 AM1/26/12
to sage-r...@googlegroups.com
On Wednesday, 25 January 2012 11:20:33 UTC+8, kcrisman wrote:


On Jan 24, 9:42 pm, Dima Pasechnik <dim...@gmail.com> wrote:
> perhaps one should investigate cross-compiling options, after all...
> These vintage things are dying out...

Well, my computer is only two years old!  I don't know if that counts
as vintage.  I think it can run 64-bit and compile 64-bit, but uname
returns i386.  Maybe I'm misinforming myself.

Well, I mostly meant the PPC arch, and other old 32-bit only processors.
However, new ARM processors, in Android phones and tablets, etc. are (mostly?) 32-bit.
Reply all
Reply to author
Forward
0 new messages