On 2014-12-12, kcrisman <kcris...@gmail.com> wrote: > ------=_Part_154_1466710874.1418353858850 > Content-Type: multipart/alternative; > boundary="----=_Part_155_44875405.1418353858850" > > ------=_Part_155_44875405.1418353858850 > Content-Type: text/plain; charset=UTF-8 > > > >> Sage (6.4.1) notebook build failed on 32 bit CentOS 5.11. Version of >> sagenb was 0.11.1. To reproduce, build Sage from source (e.g., ./make from >> Sage installation directory). CPU was "CPU1: Intel(R) Core(TM)2 Duo CPU >> E4400 @ 2.00GHz stepping 0d" per dmesg. Sage runs, but ptest or building >> pdf docs replays the error messages, as shown below. The tar file for >> sagenb could be unpacked manually OK (in off-tree location). Checksums on >> Sage source download tarball matched up OK. What is the best course of >> action to get this to build properly? Is there a reason why it failed? >> I previously posted a similar item, but it did not appear in the >> sage-support list of items, so I am trying it again. >> >> > I wonder if it's because of the bsd tar I used to tar it (I built that don't you have 'gtar' on your machine too?
> package, and have a Mac, and this has been known to cause occasional > warning messages, though I don't know about build errors). See > e.g. > http://superuser.com/questions/318809/linux-os-x-tar-incompatibility-tarballs-created-on-os-x-give-errors-when-unt surely enough, I see the same warnings on a 64-bit Linux: $ tar tf upstream/sagenb-0.11.1.tar | less tar: Ignoring unknown extended header keyword `LIBARCHIVE.creationtime' tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' .... Probably my tar is newer and thus the install can live with this. IMHO this tarball should be replaced by something glatt kosher... Please open a ticket and cc me on it. > > What you could do is to retar the directory yourself, and replace the old > tar file with that one; then things should work fine. no, this is not enough, as this will surely change the tarball checksum; you need to follow the instructions in sage developer guide to recreate them. http://sagemath.org/doc/developer/packaging.html#checksums Best, Dima > The old release > scripts repackaged all our spkg files anyway, but I think the new layout > release style does not do that, as it takes tar balls directly from > upstream. In this case, an upstream who uses Mac :( > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
