After many trials and tribulations, I've finished a build of Sage-5.5 for the Raspberry Pi. I'm still running the doctests; I've only seen timeouts so far, which is quite positive. I'm unsure how long the full (long) testsuite will take to run, but will post an update when it finishes. If anyone wants to play around with it, I've posted the binary here: http://garsia.math.yorku.ca/~sdenton/sage-5.5-pi.tar.bz2
The details below are reposted from my blog entry on the topic, which can be found here: http://blogs.africanmathsinitiative.net/tomd/2013/01/17/pisage/ The blog post also includes build time data for every spkg. The winner was lib4mrie, which took about 3 days of real time. The gory details: 1. This was a long, long process. The full build took 6.32 days of 'real' time (plus some extra down time a couple times when things were stopped for a few hours while I slept), but only 2.9 days of processor time. This discrepancy is discussed in point 3, below. 2. The Sage build is broken up into 'spkg' files, essentially many different components of Sage which need to be built. This modularity is actually quite helpful, since if the build is interrupted for any reason, it restarts on the last spkg it was working on instead of starting over from scratch. 3. I ran the build on an 8gb USB stick with 3gb set aside as swap. You have to set aside a large amount of swap in order for the build to succeed. The USB ports on the Pi are known to have much better throughput than the SD reader, so it's better to build on an attached drive. It would be best to use an external mechanical hard drive, both due to good write speed and because utilizing a USB key as swap space is pretty dumb and will greatly shorten the life of the drive. I didn't have easy access to an external mechanical hard drive, so used a USB key. (Actually, I do have an external drive, but the Pi doesn't supply enough power to spin it up; so an external drive should either be wall-powered or running from an attached powered USB hub.) 4. The build really uses the swap quite a bit; the 512mb of memory isn't quite enough. You can make things a bit better by running headless and not starting the X server and setting aside 0mb of memory for the video card, using raspi-config. But still the swap is heavily used. The worst instance is in building libm4rie, which took about 100 minutes of CPU time and almost three days of real time, the great majority of which was spent waiting for read/writes to the swap memory. 5. I also managed to speed things up a bit by using 'nice' to greatly increase the priority of the build. In the Sage directory, start the compilation with: sudo nice -n -20 make 6. Probably the most fiddly part technically was building the Tachyon package. (Everything else you can deal with by just waiting longer!) The 'tachyon' spkg fails to build out of the box because it doesn't recognize the 'armv6l' architecture. To fix this, you need to unpack the tachyon spkg (which lives in sage-X/spkg/standard) and edit the spkg-install file. In this file, find the sole reference to the 'armv7l' and change the 7 to a 6 and you'll be good to go. Repack the spkg, put it back in the original directory where you found it, and all will be ok. (This old Sage trac ticket <http://trac.sagemath.org/sage_trac/ticket/10820> was very helpful in figuring out the problem. And here's the Sage page on building spkgs<http://www.sagemath.org/doc/developer/producing_spkgs.html> .) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
