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/
Also: somebody who can should bump the Trac milestone from sage-4.8 to
sage-5.0 for all open tickets.
The buildbots are currently building binaries, results will appear at
http://boxen.math.washington.edu/home/buildbot/binaries/sage/
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
Done.
--
Regards,
Minh Van Nguyen
http://sage.math.washington.edu/home/mvngu/
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
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
--
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
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
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
Your python build is actually where things are going wrong: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
>
We'll have to dig why your python's gone foobar.
Francois
Francois
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
Francois
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
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.
for some reason I can't view this log; it leads toand then I see
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
[...]
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 ?!
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/libImageMagick-6.6.1 ImageMagick-6.6.9and I remove any /opt/* from my PATH before building Sage:
Upgrades are supported *from* any stable release *to* anything.
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
--
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.
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
--------
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.