As an experiment, I attempted to build sage-4.0.alpha0 on an EeePC 901 Linux, with the stock Xandros OS. The build failed with:
checking for fdatasync... yes configure: creating ./config.status config.status: creating Makefile config.status: creating sqlite3.pc make[2]: Entering directory `/home/user/apps/sage-4.0.alpha0/spkg/ build/sqlite-3.5.3.p3/src' sed -e s/--VERS--// ./src/sqlite.h.in | \ sed -e s/--VERSION-NUMBER--// >sqlite3.h make[2]: *** No rule to make target `tool/lemon.c', needed by `lemon'. Stop. make[2]: Leaving directory `/home/user/apps/sage-4.0.alpha0/spkg/build/ sqlite-3.5.3.p3/src' Error making sqlite
real 0m24.585s user 0m8.730s sys 0m5.770s sage: An error occurred while installing sqlite-3.5.3.p3 Please email sage-devel http://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/user/apps/sage-4.0.alpha0/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/user/apps/sage-4.0.alpha0/spkg/build/sqlite-3.5.3.p3 and type 'make'. Instead type "/home/user/apps/sage-4.0.alpha0/sage -sh" in order to set all environment variables correctly, then cd to /home/user/apps/sage-4.0.alpha0/spkg/build/sqlite-3.5.3.p3 (When you are done debugging, you can type "exit" to leave the subshell.) make[1]: *** [installed/sqlite-3.5.3.p3] Error 1 make[1]: Leaving directory `/home/user/apps/sage-4.0.alpha0/spkg'
real 227m40.319s user 125m21.420s sys 4m25.560s python: can't open file '/home/user/apps/sage-4.0.alpha0/devel/sage/ doc/common/builder.py': [Errno 2] No such file or directory
======================= I'm not sure what other info is relevant to provide.
Note that the recorded build times are suspect, as I updated the clock after starting the build. It was slow by about an hour.
On May 19, 6:31 am, Kevin Horton <khorto...@rogers.com> wrote:
> As an experiment, I attempted to build sage-4.0.alpha0 on an EeePC 901
> Linux, with the stock Xandros OS. The build failed with:
<SNIP>
> I'm not sure what other info is relevant to provide.
Look for install.log, compress it, upload it somewhere and post a link
here.
> Note that the recorded build times are suspect, as I updated the clock
> after starting the build. It was slow by about an hour.
Well, if you fiddle with the clock all bets are off. So for starters
restart the build with "make" and se if it fails the same time. If it
blows up check that the spkg in question is not corrupted. If it isn't
send a link to the compressed log as suggested above.
> On May 19, 6:31 am, Kevin Horton <khorto...@rogers.com> wrote: >> As an experiment, I attempted to build sage-4.0.alpha0 on an EeePC >> 901 >> Linux, with the stock Xandros OS. The build failed with:
> Well, if you fiddle with the clock all bets are off. So for starters > restart the build with "make" and se if it fails the same time. If it > blows up check that the spkg in question is not corrupted. If it isn't > send a link to the compressed log as suggested above.
The tarball is corrupted. It worked fine for installs on OS X and a Ubuntu VM, but the MD5 changed when I moved it to the EeePC.
I'll report success or failure, after I get a good tarball on the EeePC.
This is the second time I've gotten bitten by tarballs with bad MD5s. There has got to be a better file format to use - something where the archive validity can be checked before launching into a long install. -- Kevin Horton Ottawa, Canada
On May 19, 12:45 pm, Kevin Horton <khorto...@rogers.com> wrote:
> On 19 May 2009, at 11:45, mabshoff wrote:
> > On May 19, 6:31 am, Kevin Horton <khorto...@rogers.com> wrote:
> >> As an experiment, I attempted to build sage-4.0.alpha0 on an EeePC
> >> 901
> >> Linux, with the stock Xandros OS. The build failed with:
> > Well, if you fiddle with the clock all bets are off. So for starters
> > restart the build with "make" and se if it fails the same time. If it
> > blows up check that the spkg in question is not corrupted. If it isn't
> > send a link to the compressed log as suggested above.
> The tarball is corrupted. It worked fine for installs on OS X and a
> Ubuntu VM, but the MD5 changed when I moved it to the EeePC.
Well, that isn't really our fault, is it?
> I'll report success or failure, after I get a good tarball on the EeePC.
> This is the second time I've gotten bitten by tarballs with bad MD5s.
> There has got to be a better file format to use - something where the
> archive validity can be checked before launching into a long install.
But if you look in the log you ought to see that tar did not unpack
the whole tarball. And if you see any failure while building Sage you
ought to check the md5sum first.
