do some cleanup of the deps file, as suggested by Carl Hansen

[williamstein]

Here is an excerpt from "deps" , the makefile in spkg/standard

$(INST)/$(FORTRAN):
       $(SAGE_SPKG) $(FORTRAN) 2>&1

$(INST)/$(F2C): $(INST)/$(FORTRAN)
       $(SAGE_SPKG) $(INST)/$(F2C) 2>&1
                    ^^^^^^^ --------------------Notice that this is
wrong.
                                              the INST is not needed
and is wrong.
$(INST)/$(PIL): $(INST)/$(PYTHON)
       $(SAGE_SPKG) $(PIL) 2>&1


The only reason it works is that the script that reads it cleans it up
with
"basename".

But that's imperfect.


There are 3 instances, shown in this diff:


401c400
<       $(SAGE_SPKG) $(F2C) 2>&1
---
>       $(SAGE_SPKG) $(INST)/$(F2C) 2>&1
413c412
<       $(SAGE_SPKG) $(LAPACK) 2>&1
---
>       $(SAGE_SPKG) $(INST)/$(LAPACK) 2>&1
416c415
<       $(SAGE_SPKG) $(BLAS) 2>&1
---
>       $(SAGE_SPKG) $(INST)/$(BLAS) 2>&1




Also in deps there are references to   TWISTEDWEB2  but that doesn't
seem to exist anymore.


I do not write access to the code. I hope someone who does will take
this
and do right thing with it.

************************************************
carlhansen1234

CC: @sagetrac-drkirkby @jhpalmieri

Component: build

Author: Mitesh Patel, John Palmieri

Reviewer: Robert Miller

Merged: sage-4.5.alpha4

Issue created by migration from https://trac.sagemath.org/ticket/9274

[qed777]

comment:1

Please see John Palmieri's comment (or this diff) at #8306 for some other suggestions.

[qed777]

Updated spkg/install/deps based on 4.5.alpha1.

[qed777]

Attachment: deps.gz

Attachment: deps.diff.gz

Diff of spkg/install/deps vs. 4.5.alpha1.

[qed777]

comment:2

The attached deps incorporates suggestions from Carl Hansen, David Kirkby, and John Palmieri.

Main changes:

• Remove unnecessary $(INST)/'s.
• Make all non-$(BASE) packages depend explicitly on $(BASE).
• Make the target all depend explicitly on all standard packages.

With SAGE_PARALLEL_SPKG_BUILD="yes": The long tests pass on bsd.math. They also pass on sage.math, if after building Sage, I reinstall Maxima via sage -f. I don't know why, but I'll keep testing.

[sagetrac-drkirkby]

comment:3

#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.

[rlmill]

Work Issues: needs rebasing on top of not yet existing release

[rlmill]

comment:4

I really want sage-4.5 to be a better release, so I'm adding this to the blockers. Just like the issue that #9431 is exposing, this is too egregous to delay.

The GLPK alpha release is nearly ready, and will include #9412 specifically so that this can be rebased on top and merged into the alpha release following that one.

What work is left for this to be ready, other than waiting for #9412?

[sagetrac-drkirkby]

comment:6

See the comment about Maxima needing to be reinstalled above.

I don't know if that is supposed to be related to what changes are on this ticket or not. At first, I interpreted the reasons this ticket was needing work was because of this Maxima problem. Perhaps it was put to 'needs work' for some other reason.

Dave

[jhpalmieri]

comment:7

Is this as good a place as any to work out dependencies for glpk? (See [#9312 comment:24].)

[rlmill]

comment:8

Replying to @jhpalmieri:

Is this as good a place as any to work out dependencies for glpk?

As you're probably aware, this made it into sage-4.5.alpha3:

http://sage.math.washington.edu/home/rlmill/release/sage-4.5.alpha3.tar

Can the deps file here and the patch be rebased on top of alpha3? I promise this will be the last time.

[rlmill]

Changed work issues from needs rebasing on top of not yet existing release to needs rebasing on sage-4.5.alpha3

[jhpalmieri]

rebased against 4.5.alpha3

[jhpalmieri]

Attachment: deps-new.gz

Attachment: deps-new.diff.gz

[jhpalmieri]

comment:9

Here are rebased versions, and they also include making cython a prerequisite for glpk.

[rlmill]

Author: Mitesh Patel, John Palmieri

[rlmill]

Reviewer: Robert Miller

[rlmill]

Merged: sage-4.5.alpha4

[jhpalmieri]

comment:13

Make sure to merge "deps-new", not "deps".

[rlmill]

comment:14

Replying to @jhpalmieri:

Make sure to merge "deps-new", not "deps".

Yep, that's what I merged. Thanks for the extra care.

[nathanncohen]

comment:15

Hmmmm :-/

I do not think it can hurt, though why should GLPK depend on Cython ? In the last version (the version embedded in alpha3), there is no setup.py file, no Cython code at all... Actually, there are only bash scripts and GLPK's own sources !!!

Sorry for not having brought this up earlier (I just woke up) :-/

Nathann

[sagetrac-drkirkby]

comment:16

Replying to @nathanncohen:

Hmmmm :-/

I do not think it can hurt, though why should GLPK depend on Cython ? In the last version (the version embedded in alpha3), there is no setup.py file, no Cython code at all... Actually, there are only bash scripts and GLPK's own sources !!!

Sorry for not having brought this up earlier (I just woke up) :-/

Nathann

An interesting point. It can hurt for two reasons

• It will slow parallel builds unnecessarily, as GLPK has to wait until Cython has built. That's not a major issue, as GLPK takes very little time to build.
• The real reason people got a failure might be something else.

That's worth investigating.

[qed777]

comment:17

I apologize for my late reply.

• Off-topic, I admit: Robert, what do you think about making new releases available in /home/release on sage.math?
• I've been running test builds under /scratch on sage.math.
• For what it's worth, I later sometimes experienced the same Maxima reinstallation problem when building an unmodified 4.5.alpha1 on sage.math --- with 4, 6, or 12 parallel jobs.
• For the record, here are two errors representative of those fixed by reinstalling Maxima:

./sage -c 'print QQ[2^(1/3)]'
Traceback (most recent call last):
  File "/mnt/usb1/scratch/mpatel/tmp/sage-4.5.alpha1-j12-par/local/bin/sage-eval", line 15, in <module>
    eval(compile(s,'<cmdline>','exec'))
  File "<cmdline>", line 1, in <module>
  File "ring.pyx", line 205, in sage.rings.ring.Ring.__getitem__ (sage/rings/ring.c:2550)
  File "/mnt/usb1/scratch/mpatel/tmp/sage-4.5.alpha1-j12-par/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_ring_constructor.py", line 343, in PolynomialRing
    R = _single_variate(base_ring, name, sparse, implementation)
  File "/mnt/usb1/scratch/mpatel/tmp/sage-4.5.alpha1-j12-par/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_ring_constructor.py", line 395, in _single_variate
    name = normalize_names(1, name)
  File "parent_gens.pyx", line 204, in sage.structure.parent_gens.normalize_names (sage/structure/parent_gens.c:2093)
  File "parent_gens.pyx", line 145, in sage.structure.parent_gens._certify_names (sage/structure/parent_gens.c:1650)
ValueError: variable names must be alphanumeric, but one is '2^(1/3)' which is not.

and

./sage -c "var('x'); print solve(x, x)"
Traceback (most recent call last):
  File "/mnt/usb1/scratch/mpatel/tmp/sage-4.5.alpha1-j12-par/local/bin/sage-eval", line 15, in <module>
    eval(compile(s,'<cmdline>','exec'))
  File "<cmdline>", line 1, in <module>
  File "/mnt/usb1/scratch/mpatel/tmp/sage-4.5.alpha1-j12-par/local/lib/python2.6/site-packages/sage/symbolic/relation.py", line 619, in solve
    ans = f.solve(*args,**kwds)
  File "expression.pyx", line 6735, in sage.symbolic.expression.Expression.solve (sage/symbolic/expression.cpp:25171)
  File "expression.pyx", line 433, in sage.symbolic.expression.Expression._maxima_ (sage/symbolic/expression.cpp:3382)
  File "sage_object.pyx", line 386, in sage.structure.sage_object.SageObject._interface_ (sage/structure/sage_object.c:3501)
  File "/mnt/usb1/scratch/mpatel/tmp/sage-4.5.alpha1-j12-par/local/lib/python2.6/site-packages/sage/interfaces/expect.py", line 1032, in __call__
    return cls(self, x, name=name)
  File "/mnt/usb1/scratch/mpatel/tmp/sage-4.5.alpha1-j12-par/local/lib/python2.6/site-packages/sage/interfaces/expect.py", line 1451, in __init__
    raise TypeError, x
TypeError: error evaluating "load(to_poly_solver)":
Error executing code in Maxima
CODE:
        load(to_poly_solver);
Maxima ERROR:

Could not find `to_poly_solver' using paths in file_search_maxima,file_search_lisp.
 -- an error. To debug this try: debugmode(true);

• Curiously: Moving the build tree (renaming SAGE_ROOT) also fixes the errors, possibly because this forces sage-location to run.

[qed777]

Changed work issues from needs rebasing on sage-4.5.alpha3 to none