On 2014-12-12, Dima Pasechnik <dimp...@gmail.com> wrote: > 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.
I also noticed that the instructions to build the package in SPKG.txt are outdated. Perhaps this ticket should fix these too... > >> >> 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.
