#9274: do some cleanup of the deps file, as suggested by Carl Hansen
----------------------+-----------------------------------------------------
Reporter: was | Owner: GeorgSWeber
Type: defect | Status: needs_work
Priority: minor | Milestone: sage-5.0
Component: build | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
----------------------+-----------------------------------------------------
Comment(by drkirkby):
#9351, which has positive review, makes Sagetex dependant on both gap and
Sage, since you need a working Sage in order that Sagetex can be tested
with SAGE_CHECK=yes. So the 'deps' file attached to this ticket would need
that dependency updating.
I've printed this on paper and looked though it fairly carefully, and
can't see anything wrong with it. Everything looks logical to me. On a few
occasions where things only depended on 'BASE', but I was slightly
suspicious they might have other dependencies, I checked the packages more
carefully by inspection of their contents. I can't see anything wrong.
I've used this 'deps' file to build Sage on my !OpenSolaris machine, and
found the 'deps' file appears OK, though since neither R or Maxima build
on !OpenSolaris, I'm unable to test this 'deps' file fully on
!OpenSolaris. Since you have a specific issue with Maxima, I can't provide
convincing evidence this is OK. But it looks OK to me.
I would never be totally surprised by any failures of builds on the
*.math.washington.edu network if an NFS-shared directory is used for
building Sage - which includes the home directories. Most of the hard
disks are attached to a server called 'disk.math.washington.edu' which is
running !OpenSolaris. But the ZFS intent Log (ZIL) has been disabled to
increase NFS speed. This means that if you write something to disk, then
try to read it, there is no guarantee it can be read. Hence (on t2), the
system log shows things like
{{{
Jun 30 19:06:03 t2 nfs: [ID 236337 kern.info] NOTICE: [NFS4][Server:
disk][Mntpt: /home]NFS op OP_SETATTR got error NFS4ERR_DELAY causing
recovery action NR_DELAY.
Jun 30 19:06:03 t2 last message repeated 2 times
Jun 30 19:06:03 t2 nfs: [ID 236337 kern.info] NOTICE: [NFS4][Server:
disk][Mntpt: /home]NFS op OP_CLOSE got error NFS4ERR_STALE causing
recovery action NR_STALE.
Jun 30 19:06:03 t2 nfs: [ID 286389 kern.info] NOTICE: [NFS4][Server:
disk][Mntpt: /home]File configure (rnode_pt: 3000cdca018) was closed due
to NFS recovery error on server disk(failed to recover from NFS4ERR_STALE
NFS4ERR_STALE)
Jun 30 19:06:03 t2 nfs: [ID 941083 kern.info] NOTICE: NFS4 FACT SHEET:
Jun 30 19:06:03 t2 Action: NR_STALE
Jun 30 19:06:03 t2 NFS4 error: NFS4ERR_STALE
}}}
So if you get strange behavior, I would try it on a scratch area, with
local storage, since I would not 100% trust the way the ZFS pools are
configured.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9274#comment:3>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
